トーク

貴方は秘密めいた書籍を拾う、
そのとき、辺り一帯は眩い光りに包まれた。

貴方はオブジェクト概念が無い平行世界に転送されました。
全てのコードにオブジェクトの概念が無いのです、何もかもがコピペされている、そのような世界です。
そんな世界でも最初は何とか生きてこれたが、次第にオブジェクト概念が無いことに苦痛を感じ始めます。
何とかしなきゃ！何とかしなきゃ！
貴方は今まで生きてきたエンジニアの知識を駆使して、このオブジェクトが無い世界に、オブジェクトの概念を広めていこう！

補足:オブジェクトが無い言語が、どうやってオブジェクト構造を構築していくか、それをストーリー仕立てで話していきます。

オブジェクト指向に基づく設計において、メンタルモデルを適切にオブジェクトで表現するために、
オブジェクトの関心や責務を日々意識されているかと思います。

現在私の関わるプロジェクトでは、設計の初期からオブジェクトの責務に対する解像度を上げるため、
要件定義の段階でユースケースを記述する開発プロセスを採用しています。

ユースケースを記述することで、システムが満たすべき振る舞いが明らかになり、オブジェクトの責務に対する理解が深まります。
また、ドメインエキスパートと仕様を議論するツールとしても実用性があります。

対象のオブジェクトが複雑である場合はユースケース記述に加えて、CRCという手法を実施してモデリングをしています。

本発表では、ユースケース記述やCRCを使ったモデリングによるオブジェクト指向の開発プロセスと、
それらを実践している現場のプラクティスをご紹介します。

主なトピック

• ユースケース記述から始める要件定義
• ユースケースを使ったドメインエキスパートとのコミュニケーション
• CRC（クラス、責務、コラボレータ）を使ったモデリング
• DDDに取り入れた事例紹介

オブジェクト指向プログラミングの古典的な教科書として、バートランド・メイヤー氏の『オブジェクト指向入門』があります。
この書籍の『原則・コンセプト』編では、OOPを実践する上で重要な考え方である「契約による設計」について詳細に解説されています。
契約による設計は、現代のプログラミング言語においては「アサーション機能」として実装されています。
ではこのアサーション機能、いったいどのような考えの元で利用すれば、本来の用途に即した効果を発揮するのでしょうか？
簡単に導入できて非常に強力なツールであるアサーションを用いて、信頼性の高いソフトウェアを作る方法をご紹介したいと思います。

1990年代以降オブジェクト指向プログラミングの普及により、クラス設計、インターフェース設計、GoFのデザインパターンなどが提唱され、近年ではMVC系、DDD、Clean Architectureなどのアーキテクチャの議論が盛んに行われています。

これらももちろん大切ですが言語やアーキテクチャに依存せず、多くのプログラマが必ず検討をする設計として「関数分割」が存在しています。
関数分割の基準については、上記のデザインパターンやアーキテクチャでは議論されていません。

関数の実装は世のプログラマの全員が毎日行うことであり、欠かせない設計であると言っても過言ではありません。

しかし「テスタビリティが高い関数にする」のような基準に留まり、明確に言語化されていることが少ないです。

そこで本セッションではこの関数分割の良し悪しを測る指標として提唱されている凝集度と結合度を紹介します。
これらは構造化プログラミングをベースとした近代の多くの言語すべてに適用できる概念です。

本セッションにでは、以下を理解することができます。

• 7つの凝集度と7つの結合度について
• 関数分割の基準
• レビュー時のレビュアーとレビュイーの納得感
• 凝集度、結合度を理解することで、気がつくことができる見過ごされがちな問題
• 新しく提案されたアーキテクチャが、凝集度や結合度の観点で改善されているということ(近年ではReact Hooksが該当します)

また現実の世界では、論理的凝集と時間的凝集が現場で見過ごされて採用されてしまうケースが多いです。関数にフラグを渡して処理を分岐していませんか？
実際に発生するケースとその問題点を詳細に紹介することで、理論だけではなくより具体的に日常の開発で役立てていただければと思います。

CSSはその管理のしにくさからいろいろなアプローチが試されてきました。その中でオブジェクト指向を取り入れたOOCSSが生まれ、それを参考にした命名規則が様々登場しました。

本セッションではOOCSSとそこから続くいくつかのオブジェクト指向とCSSの命名規則の考え方をプログラマの視点から追っていきます。

【このセッションで持ち帰れるもの】
・CSSが抱える問題点とそれに対してのオブジェクト指向的なOOCSSというアプローチの考え方
・OOCSSとそれらに影響を受けたCSSの命名規則と考え方

オブジェクト指向を操るとき、私たちは当然のように新しい世界を構築しています。

「鳥（オブジェクト）」が「飛ぶ（メソッド）」

この簡単な例からも色々考えることができます。
・鳥オブジェクトを継承したツバメ・スズメも飛べるのか
・それだと同じく継承したペンギン・ダチョウも飛べてしまうのか
・ペンギンは飛ぶではなく水中では泳ぐなのか
・宇宙空間でも飛ぶといえるのか

しかし、
「鳥が飛ぶ」が成り立つと世界では余計な考えが不要となります。
ペンギン・ダチョウは存在せず、水中・宇宙空間でも無いのです。

つまり、オブジェクト指向は“現実の単語”を足掛りに、現実とは異なる世界を構築していると言えます。
私たちはこの行為を「モデリング」と呼んでいます。

「鳥が飛ぶ」とひとつ語るだけでモデリングされた世界の多数の一面を示すことができます。
では普段モデリングされた世界を私たちはどうやって、語ることによって示しているのでしょうか。
そして、どこまでが語りうることの限界なのか、示せれる限界はどこにあるのか。
時間が許す限り「語る」と「示す」の気づきを発表したいと思います。

「神クラス」とは、一つのクラスに余りにも多くの機能性を装備してしまい、コードが肥大化した様子を示すアンチパターンである。幾重にもSRP違反になってしまっている状態である。「神クラス」は、幅広いユースケースへ懸命に対応しようとする中で生み出されてしまう。

「神クラス」は、いわゆる業務系システムにて生じがちで、対して、技術的な装置、例えばHTTP Server、複合機の制御システム、などでは生じにくい。

業務システムではなぜ神クラスが出現しやすいか？業務システムのクラスの外部仕様は業務担当者の脳内にある。素朴に客観的に存在するとみなせない。対して、技術的な対象は、素朴に客観的に存在すると見なせる。業務システムでは、系の本質はむしろ利用者（＝クライアント）の脳内イメージそのものなので、系に対する要求発生源を単一に収斂させることができない。

ここに、系のクライアントの脳内イメージを「サブジェクト」と称し、複数のクライアントの「サブジェクト」を調停・統合・合意したモデルを「オブジェクト」と称したとき、いわゆる「エンティティ」は、本質的にサブジェクト－オブジェクトの二重構造を取るというモデルを提示する。

オブジェクト指向言語のSmallTalk向けに考え出されたMVC。そのMVCの概念ができてから、その派生で様々なGUIアーキテクチャの考え方が登場してきました。またWebブラウザ、スマートフォンアプリなど、表示の機構も様々に変化し、その時の時流や技術のトレンドを取り込み枝葉が分かれるように進化を遂げています。

本セッションではそんなGUIのアーキテクチャに関して2020年時点でどんな経過をたどってきたのか15分で紹介します。

【このセッションで持ち帰れるもの】
・通常のアーキテクチャとGUIアーキテクチャの違い
・MVCから派生した様々なGUIアーキテクチャパターンの概要
・MVCから別れたFlux,Reduxなどのパターン

(ロングセッション向けのセッションをショート向けに要所だけ抜き出したものとなります)
Active Recordは書籍「Patterns of Enterprise Application Architecture(PofEAA)」で「DBのテーブル等の列をラップし、DBアクセスをカプセル化し、ドメインロジックを追加するオブジェクト」としてオブジェクト指向を使ったデザインパターンの一つとして世に知れ渡りました。
ですが現在ではRuby on Railsの普及に伴い、デザインパターンとしてではなく、Railsの機能名としてのActive Recordのことを指す場面が多く見受けられます。また、そんな中ででRailsを使って様々な設計技法にチャレンジしようとすると、Active Recordが阻害要因となり、断念されるケースが多く見かけます。

そこで本セッションではもともとPofEAAで語られたActive Record、そしてRailsで実装されているActive Recordを通して、本来パターンとしてのActiveRecordはどういう場面で一番真価を発揮し、またRailsのActiveRecordがどんな形でブロッキング要因になっているのかを紐解いていければと思います。

Railsを利用している人にはパターンとしてのActive Recordのパターンとしての特徴を、利用していない人には何故ここまでRailsの中心と言われるようなものになっているのかを、設計手法を考えながら業務でのRailsと向き合ってきた私から色々と伝えることができればと思っています。

オブジェクト指向言語にある程度慣れてくると、次にオブジェクト指向らしく設計・実装するにはどうすれば良いのかという壁にぶつかりませんか？動物が、人が、車がとかの例では、なかなかオブジェクト指向らしく設計・実装するイメージが沸かないと思います。
また、オブジェクト指向に長けた人のソースコードを読むと、理路整然に記述されており感動したことがありませんか？

壁に悩む人やオブジェクト指向に長けた人を見ていて、オブジェクト指向らしくするにはその前に習得しておく考え方があると考えるようになりました。
それは抽象・構造・関連です。
おそらく皆さんが過去に何らかの形で習得していたり、普段活用している考え方だと思います。

本セッションでは、オブジェクト指向以前に習得しておくべき抽象・構造・関連の考え方と活用の仕方について時間の許す限りお話します。

DDD、という単語を昨日まで知らなかった自分がいきなりBounded Contextを探すことになった。

超展開でDDDの世界に引き込まれ、社内に有識者がいるのかも分からない状況から戦略的DDDをやった話をします。
大まかなアジェンダは以下を考えています。
・そもそもDDDって？
・実際にドメインを分割する活動の中でやったアプローチの紹介
・私なりに戦略的DDDをやった結果わかったこと

DDDの本はとんでもなく分かりにくいし、戦略的DDDの部分は特に抽象的すぎてもはや何が書いてあるのか全く分かりませんでした。
もちろん、どう実践すればいいのかなんて全く分からず、途方に暮れていました。
このトークを通じて、戦略的DDDがやりたい、知っているけど最初何したらいいか分からない。という方の悩みが解決できればと思っています。

したがって、実際にやったこととその振り返りをメインで話します。
具体的には、以下の内容と分かったことを詳細に話します。
・本を読む。ネットサーフィンする。
・twitterでDDDで有名な人にいきなり質問をして得られたリプライのご紹介。
・自作のワークショップを企画してやってみる。
・休日に人を集めてEventstormingとやらをやってみる。

戦略的DDDの理論についてはなるべくシンプルに説明し、実際にとったアプローチを中心にお話しようと思います。
イメージがしやすく、最初の一歩が踏み出しやすいよう、なるべく具体的に話します。よろしくお願いします！

「オブジェクト指向をやってみたいけど、どこから始めればいいか、具体的にどう書けばいいかわからない」
という方に向けて、
構造化プログラミングで書かれたコードをオブジェクト指向で書き替える方法を示します。
15分の中で「この書き換え指針に基づき、こう書き換えた」とどんどん紹介していきます。
コード例はPythonで、 https://github.com/ftnext/python-image-processor にて開発中です。
以下に構成を示します。

• 自己紹介 (1min)
• 背景：入門書は構造化プログラミング (1min)
• 課題：入門書のように書けるようになったが保守しにくい (1min)
• 解決策：オブジェクト指向 (1min)
• アプローチ：『現場で役立つシステム設計の原則』『ThoughtWorksアンソロジー』の「オブジェクト指向エクササイズ」を参考に入門書のコードを書き直す (1min)
• 対象のスクリプト紹介 (2min)
  • パスで指定した画像を縮小する
  • 画像の入ったディレクトリも指定可能
  • 概要：対象の画像を洗い出し、縮小する処理を呼び出す
• 以下書き換え方
  1.対象と保存先を扱うクラスと縮小処理を表すクラスに分けて設計(1min)
  2.ディレクトリ指定のために、対象と保存先のファーストクラスコレクションを作成：マジックメソッドの上書きとUserListの使用の2通り(2min)
  3.保存先の指定を追加→ファーストクラスコレクション作成を修正(1min)
• 変更しやすさ：サブコマンドでグレースケールにもできるように→共通インターフェースを持つグレースケール処理クラスを作る（抽象クラス使用）(2min)
• まとめ(1min)
• 質疑(1min)

ドメイン駆動設計はオブジェクト指向設計原則のうえに成り立つ設計プラクティスです。

つまり、ドメイン駆動でシステムを設計することは「オブジェクト指向設計をちゃんとやる」ということにほかなりません。検討の対象はクラスだけではありません。もう少し大きな単位、パッケージ／モジュール／レイヤー、まで視野を広げます。

依存関係が注意深く設計され、単一の責任を持ったモジュールやパッケージが、境界付けられたコンテキストをかたちづくります。レイヤーやパッケージの依存関係の逆転により、ドメインは自身の関心の範囲内でビジネスロジックの実現に集中できます。

この発表では依存関係という切り口から、ドメイン駆動なアーキテクチャ設計を継続的に維持・改善していくための手法を、Java とアーキテクチャテストツールの ArchUnit を用いて紹介します。

ActiveRecordパターン + MVCのような設計パターンにおいて、たとえばFormとDBテーブルの1レコードを1:1の密結合とすることを是としている場合、「その後の変更をクラス内で閉じたい」という私達の欲求は叶えられなくなっていきます。
さらに、多くの開発者に使われるWebアプリケーションフレームワークであればあるほど、各々の開発者がキャリアの中でそれまで積み上げたサービスオブジェクトの定義があり、それが形式知化されないまま開発が進んでいったりします。
そうなると、本来同じところにいるはずのクラスの役割が、どうしても異なるレイヤーに散らばりがちで、コードの見通しが悪くなる。さらにそれをルールで縛ることによる軋轢が生まれてしまうこともあります。

そもそもクラス設計をルールで縛ったところで、それが守られる保証もありません。「スピード優先」というお題目により蔑ろにされることもしばしば目にしてきました。

これは私たちが常に頭を抱えがちな問題ですが、そこでgRPCを利用することによって、強制的にAPIの出力（protocol buffer）をドメインオブジェクトと一致させ、「技術的にコードが複雑さを持ちにくくすること」と、「開発者間の齟齬をなくす」という両方の問題を解消できる可能性を提示してみます。

【メインとなる対象層】

• 開発現場で、オブジェクト指向設計に対する考え方のミスマッチで困っている
• チーム内のエンジニアの経験年数の差や設計スキルの差が大きくて標準化のコストが高い
• マイクロサービスアーキテクチャに興味あるけどどこから手をつけるかわからない

複雑なシステムの設計を行う際には、そのシステムを様々な観点（ビュー）を通して観ることで、そのシステムを構成するコンポーネントを把握することが重要です。それらの各コンポーネントがどのような責務を担い、周囲のコンポーネントとの間でどのような相互作用を期待するかを整理することが堅牢なシステムの実現に繋がります。コンポーネントが責務を持ちそれらの相互作用で大きな価値を提供する構造は、まさにオブジェクト指向の世界観と重なります。

本セッションでは、Webアプリケーションを１つのシステムとみなして、それを構成する複数のコンポーネントをどのように分割し、どのような関係性に整理するのがよいか考える過程をお話する予定です。具体的にはアプリケーションを支える基盤的な横断的関心事を題材に、モデリングを通じて責務を整理していく予定です。

本セッションを通じて、オブジェクト指向をプログラミング以外の場面でも活用できるイメージを持ち帰って頂けると嬉しいです。

※ショートセッションで採択の場合には、実践例を中心にご紹介したいと思います。

【概要】
人とのコミュニケーションをクラスの視点から考え、より伝わるコミュニケーションを取る方法を学ぶ

【対象者】
・オブジェクト指向　初心者〜
・人とのコミュニケーションに悩みを感じているエンジニア
・伝え上手、聞き上手になりたいエンジニア
・専門知識を素人に伝える事に難しさを感じているエンジニア

【内容】
仕事を振られたとき、初めての人と話すとき、やりとりで困った事にある人を対象に
クラスの視点からどのようにコミュニケーションを取ると良いか、なぜコミュニケーションが取れないかを解説し、
どのように人とコミュニケーションを取ると良いかをお話します。
また専門知識を相手にいかに短時間で理解してもらうかを「例え話」を元にお話します

【リスナーのゴール】
・社内外でのコミュニケーションを円滑に取れるようになってもらう
・話して伝わる楽しさを感じてもらう
・コミュニケーションに対する苦手意識を少しでも減らす

【なぜ私が話すのか】
・高齢者、小学生向けプログラミングスクールのメンターを通じて「素人にIT知識を伝える」のが上手
・周りの様々なレベルのエンジニアに合わせて「彼らの理解しやすいコミュニケーション」を取るのが上手
・エンジニアに「伝わる楽しさ」を知ってもらうためにコミュニティ運営をしているから

綺麗なコードを書きたいという一心でオブジェクト指向を学び始めた僕が、最初に手に取った本である「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を基に、オブジェクト指向について学んだことをお話していきます。(クリーンアーキテクチャ自体についてはそれほど触れない予定です)

私がゼロからどのようにオブジェクト指向思考を学び、思春期になっていったのか。オブジェクト指向を学んでみて良いなと思っていること、楽しいなと思っていることなどをお話します。私自身の経験をお話しすることで、これからオブジェクト指向を学びたい人に役立てていただけるセッションになればと考えています。

「あー、オブジェクト指向ね。わかるわかる」本当にそうでしょうか。

なんとなくわかったふうに思っている事が、説明すると実際はうまく伝えれなかったりすることがあると思います。

オブジェクト指向プログラミングを正しく言語化を行い、共通認識を共有することを本セッションの目的とします。

実コードも添えたPHPを例に、正しいオブジェクト指向プログラミングを学びましょう。

■本セッション想定聴講者

• プログラム初学者
• オブジェクト指向プログラミングがよくわからない人
• 「あー、オブジェクト指向ね。わかるわかる。説明は出来ないけど」な人

■本セッションに向かない聴講者

• オブジェクト指向を掌握してる方
• オブジェクト指向を利用して正しくプログラムが書ける方

本トークでは、普段よく利用しているデザインパターンの中でいくつか概要を説明します。

各デザインパターンの解説とオブジェクト指向の考え方、そしてその実例としてAndroid OSのアプリケーションフレームワークへの適用例をご紹介します。

教科書で学んだだけでは、デザインパターンの実際の適用シーンがイメージし辛いかと思いますので、Android OSだとこのように利用されていますよという具体例を示すことで、オブジェクト指向とデザインパターンについての理解が進むための参考になれば頂ければ幸いです。

■ 紹介予定のデザインパターン（規定時間に納める目的で、当日までに増減する可能性あり）

• Builder
• Singleton
• Adaptor
• Proxy
• Mediator
• Observer