オブジェクト指向のこころ: 第1章 / DESIGN PATTERNS EXPLAINED: chapter-1

会社で「オブジェクト指向のこころ」の読書会をやっています

Transcript

1. 第1章 オブジェクト指向パラダイム 課題図書: オブジェクト指向のこころ: デザインパターンとともに学ぶ
2. ͜ͷষͷॏཁͳΩʔϫʔυ • 機能分解と構造化プログラ ミング • オブジェクト指向パラダイ ム • 要求と変化(変更) • カプセル化とポリモーフィ ズム • 概念と仕様と実装 • 型 • データとメッセージ(メ ソッド) • 責任(責務) • 凝集度と結合度
3. 機能分解と要求 1.2 オブジェクト指向パラダイム以前: 機能分解 1.3 要求における問題
4. ͱ͋ΔγεςϜΛ࡞Γ͔ͨͬͨͱ͠·͢ 「データベースに格納されている図形データを読み込み、画 ⾯に表⽰するプログラム」 => さて、どうやって作り⽅を考えて(設計して)いきます か・・？
5. ػೳ෼ղ • システムに必要な「機能」で分けていこうぜ〜というやり かた データベースに格納されて いる図形データを読み込み、 画⾯に表⽰するプログラム main データベースから図形リストを検索 図形リストを取得 図形リストをソートする 画⾯上に図形Aを表⽰する 画⾯上に図形Bを表⽰する 画⾯上に図形Cを表⽰する
6. ػೳ෼ղͷͭΒʙ͍ͱ͜Ζ • main()がとっても⼤変 • 正確に、全てを、決められた順番に呼び出す役 • どんどん複雑になっていく未来が⾒える・・・ • バリエーションが増えたら？
7. ʮҕৡʯͱ͍͏ߟ͑ํ • もし、main()が「全部適切に良い感じにする」のではなく 「指⽰を出すだけ」で「それぞれの部分(機能)が、main()に都合 の良い応答をする」ことになったら・・？ • 「どこまで(誰が)やる？」「それはどうしてだっけ？」の視点 を変えてみる • この「誰が良い感じに」を「呼び出される側」に移すのを 「(責任・処理の)委譲」という • 委譲により変更が容易になる(みたいな話がこれから出てくる)
8. มߋ͕ා͍ • “多くのバグは、ソースコードの変更によって⽣み出されて いる。(P5)” • 委譲によって「変更の影響を受ける箇所」を減らせれば、 「変更しなければならない量」も減り、 「変更が失敗を招く」というリスクも減る
9. มߋ͕ා͍ͳΒ มߋͷͳ͍΋ͷΛ࡞Ε͹͍͍͡Όͳ͍ • 最初に作ったものがず〜〜っとそのままなら勝ち確です ね！(論破！！！ • いいえ、要求は常に変わると⾔われています(論破！！！！
10. ཁٻʹ͓͚Δ໰୊ • 作る前に完璧な「欲しかったもの」が分かる事はない • 作った時点で完璧でも新たなニーズが出てくる • 作られたもの・動くものを⾒て初めて気付く要求もある • 変化(のニーズ)をもたらすのは・・・ • ユーザー、クライアント、開発者、市場(環境)と多岐に わたるよ！
11. ͡Ό͋Ͳ͏͢Ε͹ • 変化に抗うのではなく、受け⼊れて付き合っていきましょ • 振り回されないようにしたいね・・ • ”どう変わるかはわからなくても、どこが変わるかは予想で きる(P6)” “変化は発⽣する！それに対応することが⼤事(P6)” • 皆さんの⼤好きな◦◦アーキテクチャも、 「寿命が⻑いものに依存しよう」って⾔っていませんでし た？
12. 変更に対応するには・カップリング 1.4 変化に対応する: 機能分解を⽤いた場合
13. ͓͞Β͍: ػೳ෼ղ • main()が悲鳴を上げている未来が⾒えるね データベースに格納されて いる図形データを読み込み、 画⾯に表⽰するプログラム main データベースから図形リストを検索 図形リストを取得 図形リストをソートする 画⾯上に図形Aを表⽰する 画⾯上に図形Bを表⽰する 画⾯上に図形Cを表⽰する
14. ΞϓϩʔνΛม͑ͯΈΔ: ϞδϡʔϧԽ • 「モジュール化」してみました • 図形の追加に対応しやすくなったよ！ • mainからモジュールへは「図形のタイプ、図形の詳細」を 渡します データベース に… main データベースから図形リストを検索 図形リストを取得 図形表⽰プログラム 画⾯上に図形を表⽰する A B C D
15. ͜ͷϞδϡʔϧʹ͸໰୊͕͋Δ • モジュール化してみよう！というのは良さそうだが、 その内容に難がありそう • ⽈く”低い凝集度と⾼い結合度という⽤語で説明できる2つ の重⼤な問題が存在しています”
16. Ͳ͕ͦ͜ͷūƃŪŜͬͯ໰୊Λ ΋ͨΒ͍ͯ͠Δͬͯʁ • 「図形の詳細」ってなんだい、図形によって「必要な情 報」が変わってこないかい？ • => 呼び出し側が「知らなきゃいけない事」が多いよね • 「図形ごと」に「作画」も「表⽰」も持たせるのかい？ • => それぞれがやっている仕事(の種類)が多いし散らばっ てるよね
17. ڽू౓ͱ݁߹౓ これらの話は、全て「責任(責務)区分」の話なんだぜ • 「お前が何をしているかを知っている」の度合いを結合度 • ルーチン間の結びつきの強さ • 「私は◦◦をしています」のシンプルさの度合いを凝集度 • ルーチン内の仕事(の種類)の関連度の⾼さ
18. ݁߹౓ 低結合 >>> ⾼結合 • 「結合度が⾼い」という状態は、 「変更の影響が出やすい」という状態をもたらす • 例えば「博⼠がスイッチを⼊れればトリガーが動いてロボッ トの電源がONになる」は低結合、「博⼠が持ち主トリガーを A,B,Cの順に⽴てればロボットの電源がONになる」は⾼結合 • 「トリガーを増やしたい」 => 誰が影響受ける？
19. ڽू౓ ⾼凝集 >>> 低凝集 • 知っていますか、凝集を極限まで薄めると神が⽣まれます • https://en.wikipedia.org/wiki/God_object • 「凝集度が低い」という状態は、 「変更の必要性が出やすい」という状態をもたらす • 例えば「注⽂をとったら調理はキッチン任せ」は⾼凝集、「注⽂ とってキッチンへ向かって調理をします」は低凝集 • 「お客さんが激昂してる」「フライパンに⽳が空いた」 => 誰が影 響受ける？ たぶん何かの魔法陣です、 セフィロトの樹みたいで神秘的ですね
20. Өڹ(ൣғ)͕๲ΒΉ => มߋ͕೉͘͠ͳΔ • 「思わぬ影響をもたらしてしまう」ような状態を「好ましくな い副作⽤」 • 好ましくない副作⽤が怖くて変更が怖くなる • 好ましくない副作⽤がどこまで⾏ってるか分からなくて、バグ 対応が⼤変になる • こうした問題は「どこで・なにを」の責務の問題で説明できる • 結合度、凝集度はソフトウェア品質を測る価値指標と⾔える
21. ਅ໘໨ˍৄ͍͠આ໌͸ίνϥʹ オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling - Speaker Deck https://speakerdeck.com/sonatard/coheision-coupling 良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ CTO室｜note https://note.com/cyberz_cto/n/n26f535d6c575#E0aBe
22. 変更への向き合い⽅、カップリング 1.5 要求の変更に取り組む
23. ผͷྫΛ࢖͍·͢ こういう話を考えてみてください • あなたは⼤学でセミナーの講師です • 参加した学⽣が、次の講義の教室へ向かえるようにしてく ださい
24. ߏ଄ԽϓϩάϥϛϯάͷΞϓϩʔνͰ ߟ͑Δͱɾɾ 1. 学⽣のリストを取得して 2. 学⽣ごとに 1. 次の講義を調べる 2. 調べた講義の教室を調べる 3. ここから調べた教室への道のりを調べる 4. 調べた道のりを学⽣に伝える
25. ੹೚Λத৺ʹߟ͑Δͱɾɾ 1. 講義ごとの教室⼀覧を壁に張り出す 2. 学⽣に「⼀覧を貼ってあるぞ！」「⾏け！！」と告げる 1. 学⽣は教室⼀覧を⾒る 2. 学⽣は⽬当ての教室を⾒つけ出す 3. 学⽣は⽬当ての教室までの道のりを把握する
26. ͜ͷҧ͍͸ͳΜͩʁ • 責任の移⾏を⾏った • before: 学⽣が次の教室へ⾏くのは講師の責任 • after: 学⽣が次の教室へ⾏くのは学⽣⾃⾝の責任 • 元の問題 • 「講師が学⽣の移動にも責任を持つ」という低凝集 • 「講師が(⾃分の関係ない)講義も知る」という⾼結合
27. ͜ͷ੹຿ͷҠߦΛͯ͠Կ͕خͦ͠͏ʁ • 我々はずっと「変更が云々」の話をしていますね？ • 「教室が変更になった」という変更の影響は？ • 「何かの講義が休講になった」という変更があったら？ • 「移動に使う⾃転⾞が窃盗被害に」？ • 「お腹が空いたから今⽇は帰るですって・・？」 • 影響範囲が少なくとも「講師も学⽣も」が「学⽣が」に封じ 込まれる期待が持てるようになる
28. (ຊʹ͋Δ಺༰ʹ໭͠·͢) • 「セミナーが終わった時に、⼤学院⽣はアンケート結果⽤紙 を集めてください」という要件が⼊った例 • 構造化〜 => 講師が「君は院⽣かな？」と問う必要 • 責任〜 => 学⽣が「私は院⽣だからな…」と判断 • 後者は学⽣が⾃らの振る舞いに責任を持てていると⾔える • 講師が知るべき情報を最⼩化できる(低結合化) • 学⽣が「やるべきこと」を⾃分で達成できる(⾼凝集)
29. ໰୊ͱ؍఺ • 構造化→責任中⼼の変遷において、 講師は「抽象的に語りかける」ようになっている • 1⼈1⼈の状況に応じて細々と指⽰しない • 個⼈というより「学⽣」という存在に話しかけている • 抽象度によって「概念レベル」「仕様レベル」「実装レベル」 と呼ばれる観点が出てくる • が、この節の説明だとまだ捉えづらいので⼤胆に次の節へGo!
30. ࢀߟ 【中級】基礎からのオブジェクト指向 第3部 分析・設計⼿法の基本 は「モデル作成」にあり（中編） | ⽇経クロステック（xTECH) https://xtech.nikkei.com/it/article/COLUMN/20060512/237751/ この3つの括り⾃体が相対的だなぁという所感があります。 本書で「3つの観点」という話が出てくるのは、あくまで「問題領域で考える」「解決領域と思考モー ドを使い分けよう」みたいな事がヒントになり得るからだ、と割り切って良さげです。すなわち、「こ れは仕様なのか？実装なのか？」を厳密に区別できるようになってくれ・・・という話ではないかと。
31. 責任とオブジェクト指向 1.6 オブジェクト指向パラダイム
32. ΍ͬͱग़ͨʂΦϒδΣΫτࢦ޲ • オブジェクト指向？ • 「オブジェクト」という概念からすべてのものごとを組 み⽴てる • 問題は、「機能」ではなく「オブジェクト」に分解される
33. ΦϒδΣΫτͷػೳ • オブジェクトは「責任」を持つことができる • ⾃⾝が1つの「型」として表現される • データと状態を持つ • メソッドを持つ
34. Ͳ͏͍͏ͱ͜Ζ͕خͦ͠͏͔ͬ͢ʁ • 「責任」で語っていくと、「問題領域に存在する実態」をそのまま落とし込みやす くなるね〜という点 • 問題領域 = いわゆる「要求」とか「⾮開発者でも分かる⾔葉で語られる」ような 現実世界(のモデル) • つまり「ソフトウェア的な知識をなくして語った理解(モデリング)と、コードが⼀ 致しやすい」みたいな利点がある ※理想論 • 「ドメイン層」って⾔葉でピンとくる⼈はそれで👍 • DDDできる〜のは「オブジェクト指向の強みの発露」ではあるけど、 そのプリミティブには「責任とコラボレーションの実現をサポートできる」がある よ、的な
35. ʮ3ͭͷ؍఺ʯͱΦϒδΣΫτࢦ޲ 1. 概念レベル = 責任の集合 2. 仕様レベル = 関係と振る舞い • Interface＆呼び出し元・呼び出し先、的な 3. 実装レベル = コード(データ、メソッド) • 具体的なclassとかプロパティとか
36. P15ͷphper޲͚ิ଍ “どうしたら謝った型のオブジェクトが追加されないように保証できるので しょう” について • PHPのarrayが `mixed[]` なコレクションなのでアレですが • いわゆるジェネリクスとかああいう、「コレクション(の要素)が型を持つ (縛られる)」みたいな前提で説明されているので注意してください • と考えると、「⼤学院⽣でも学部⽣でもOKにしたい、そのために は・・」で抽象クラスの定義、というソリューションが導出されるのも違 和感ないはず • 抽象(, 継承)の使い道〜みたいな話はあとの⽅で出てくる(確か)ので、今は あまり気にしなくて良さそう
37. ΧϓηϧԽͱ͍͏֓೦Λ֮͑·͠ΐ͏ • オブジェクトって「責任を持つもの」って⾔いましたよ ね？ • 責任を持っているという事は、責任を果たすということで す • 逆に⾔えば 責任さえ果たしてくれればいいよがオブジェク ト指向の世界観 • 聞かれてねー事は隠しに隠してこーぜ！！！ => カプセル化
38. ͳʹΛӅ͢ͷ͔ • 「データの隠蔽」は矮⼩化した捉え⽅ • 「オブジェクト」が「データと振る舞いを持つ」ことから、 「(振る舞いにおいて)データを呼び出し⼿から不可視にする」み たいな感覚があるのかも？ • カプセル化はあらゆる種類の隠蔽を含むもの • 呼び出し⼿が「意識しなくても普通に使えるね！！」という状態 を提供するもの • 隠せていない = 呼び出し⼿に意識させる(責任を負わせる)
39. ϙϦϞʔϑΟζϜͱ͍͏֓೦Λ ֮͑·͠ΐ͏ • ポリモーフィズム = 多相性(多様性、多態性) • ・・・何が多様なんだ！？ • 呼び出し⼿が「Aしてね」と告げた時に、 (その責任を果たすために)必要に応じた処理を内部的に使い分け るよ • 例えば「講師 -> 学⽣ (移動してね)」といったつもりが、中では 「院⽣ extends 学⽣」「学部⽣ extends 学⽣」が働いてくれて た・・・！みたいな事が成し得る
40. ΧϓηϧԽͱϙϦϞʔϑΟζϜ • ポリモーフィズムによって、プログラマはより「抽象を扱いやす い」という状態を⼿に⼊れることができるのです • 「何をしてくれているのかを知らなくていい(隠蔽されている)」 からこそ「多様な処理が動く」とも⾔えるわけで、カプセル化と ポリモーフィズムは近接概念として捉えておくと良きです • 抽象によればよるほど「変更に強い」というしなやかさを獲得で きます • つまり・・・嬉しい！
41. ※ 1.7,1.8は事前共有を割愛します 1.7は「素直にそのまま読んだ通り」な感じ。 1.8はOOP系のLLやっている⼈なら読み⾶ばしてもOKそう。