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

Slide 1

Slide 1 text

第1章オブジェクト指向パラダイム課題図書: オブジェクト指向のこころ: デザインパターンとともに学ぶ

Slide 2

Slide 2 text

͜ͷষͷॏཁͳΩʔϫʔυ • 機能分解と構造化プログラミング • オブジェクト指向パラダイム • 要求と変化(変更) • カプセル化とポリモーフィズム • 概念と仕様と実装 • 型 • データとメッセージ(メソッド) • 責任(責務) • 凝集度と結合度

Slide 3

Slide 3 text

機能分解と要求 1.2 オブジェクト指向パラダイム以前: 機能分解 1.3 要求における問題

Slide 4

Slide 4 text

ͱ͋ΔγεςϜΛ࡞Γ͔ͨͬͨͱ͠·͢ 「データベースに格納されている図形データを読み込み、画⾯に表⽰するプログラム」 => さて、どうやって作り⽅を考えて(設計して)いきますか・・？

Slide 5

Slide 5 text

ػೳ෼ղ • システムに必要な「機能」で分けていこうぜ〜というやりかたデータベースに格納されている図形データを読み込み、画⾯に表⽰するプログラム main データベースから図形リストを検索図形リストを取得図形リストをソートする画⾯上に図形Aを表⽰する画⾯上に図形Bを表⽰する画⾯上に図形Cを表⽰する

Slide 6

Slide 6 text

ػೳ෼ղͷͭΒʙ͍ͱ͜Ζ • main()がとっても⼤変 • 正確に、全てを、決められた順番に呼び出す役 • どんどん複雑になっていく未来が⾒える・・・ • バリエーションが増えたら？

Slide 7

Slide 7 text

ʮҕৡʯͱ͍͏ߟ͑ํ • もし、main()が「全部適切に良い感じにする」のではなく「指⽰を出すだけ」で「それぞれの部分(機能)が、main()に都合の良い応答をする」ことになったら・・？ • 「どこまで(誰が)やる？」「それはどうしてだっけ？」の視点を変えてみる • この「誰が良い感じに」を「呼び出される側」に移すのを「(責任・処理の)委譲」という • 委譲により変更が容易になる(みたいな話がこれから出てくる)

Slide 8

Slide 8 text

มߋ͕ා͍ • “多くのバグは、ソースコードの変更によって⽣み出されている。(P5)” • 委譲によって「変更の影響を受ける箇所」を減らせれば、「変更しなければならない量」も減り、「変更が失敗を招く」というリスクも減る

Slide 9

Slide 9 text

มߋ͕ා͍ͳΒ มߋͷͳ͍΋ͷΛ࡞Ε͹͍͍͡Όͳ͍ • 最初に作ったものがず〜〜っとそのままなら勝ち確ですね！(論破！！！ • いいえ、要求は常に変わると⾔われています(論破！！！！

Slide 10

Slide 10 text

ཁٻʹ͓͚Δ໰୊ • 作る前に完璧な「欲しかったもの」が分かる事はない • 作った時点で完璧でも新たなニーズが出てくる • 作られたもの・動くものを⾒て初めて気付く要求もある • 変化(のニーズ)をもたらすのは・・・ • ユーザー、クライアント、開発者、市場(環境)と多岐にわたるよ！

Slide 11

Slide 11 text

͡Ό͋Ͳ͏͢Ε͹ • 変化に抗うのではなく、受け⼊れて付き合っていきましょ • 振り回されないようにしたいね・・ • ”どう変わるかはわからなくても、どこが変わるかは予想できる(P6)” “変化は発⽣する！それに対応することが⼤事(P6)” • 皆さんの⼤好きな○○アーキテクチャも、「寿命が⻑いものに依存しよう」って⾔っていませんでした？

Slide 12

Slide 12 text

変更に対応するには・カップリング 1.4 変化に対応する: 機能分解を⽤いた場合

Slide 13

Slide 13 text

͓͞Β͍: ػೳ෼ղ • main()が悲鳴を上げている未来が⾒えるねデータベースに格納されている図形データを読み込み、画⾯に表⽰するプログラム main データベースから図形リストを検索図形リストを取得図形リストをソートする画⾯上に図形Aを表⽰する画⾯上に図形Bを表⽰する画⾯上に図形Cを表⽰する

Slide 14

Slide 14 text

ΞϓϩʔνΛม͑ͯΈΔ: ϞδϡʔϧԽ • 「モジュール化」してみました • 図形の追加に対応しやすくなったよ！ • mainからモジュールへは「図形のタイプ、図形の詳細」を渡しますデータベースに… main データベースから図形リストを検索図形リストを取得図形表⽰プログラム画⾯上に図形を表⽰する A B C D

Slide 15

Slide 15 text

͜ͷϞδϡʔϧʹ͸໰୊͕͋Δ • モジュール化してみよう！というのは良さそうだが、その内容に難がありそう • ⽈く”低い凝集度と⾼い結合度という⽤語で説明できる2つの重⼤な問題が存在しています”

Slide 16

Slide 16 text

Ͳ͕ͦ͜ͷūƃŪŜͬͯ໰୊Λ ΋ͨΒ͍ͯ͠Δͬͯʁ • 「図形の詳細」ってなんだい、図形によって「必要な情報」が変わってこないかい？ • => 呼び出し側が「知らなきゃいけない事」が多いよね • 「図形ごと」に「作画」も「表⽰」も持たせるのかい？ • => それぞれがやっている仕事(の種類)が多いし散らばってるよね

Slide 17

Slide 17 text

ڽू౓ͱ݁߹౓ これらの話は、全て「責任(責務)区分」の話なんだぜ • 「お前が何をしているかを知っている」の度合いを結合度 • ルーチン間の結びつきの強さ • 「私は○○をしています」のシンプルさの度合いを凝集度 • ルーチン内の仕事(の種類)の関連度の⾼さ

Slide 18

Slide 18 text

݁߹౓ 低結合 >>> ⾼結合 • 「結合度が⾼い」という状態は、「変更の影響が出やすい」という状態をもたらす • 例えば「博⼠がスイッチを⼊れればトリガーが動いてロボットの電源がONになる」は低結合、「博⼠が持ち主トリガーを A,B,Cの順に⽴てればロボットの電源がONになる」は⾼結合 • 「トリガーを増やしたい」 => 誰が影響受ける？

Slide 19

Slide 19 text

ڽू౓ ⾼凝集 >>> 低凝集 • 知っていますか、凝集を極限まで薄めると神が⽣まれます • https://en.wikipedia.org/wiki/God_object • 「凝集度が低い」という状態は、「変更の必要性が出やすい」という状態をもたらす • 例えば「注⽂をとったら調理はキッチン任せ」は⾼凝集、「注⽂とってキッチンへ向かって調理をします」は低凝集 • 「お客さんが激昂してる」「フライパンに⽳が空いた」 => 誰が影響受ける？たぶん何かの魔法陣です、セフィロトの樹みたいで神秘的ですね

Slide 20

Slide 20 text

Өڹ(ൣғ)͕๲ΒΉ => มߋ͕೉͘͠ͳΔ • 「思わぬ影響をもたらしてしまう」ような状態を「好ましくない副作⽤」 • 好ましくない副作⽤が怖くて変更が怖くなる • 好ましくない副作⽤がどこまで⾏ってるか分からなくて、バグ対応が⼤変になる • こうした問題は「どこで・なにを」の責務の問題で説明できる • 結合度、凝集度はソフトウェア品質を測る価値指標と⾔える

Slide 21

Slide 21 text

ਅ໘໨ˍৄ͍͠આ໌͸ίνϥʹ オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling - Speaker Deck https://speakerdeck.com/sonatard/coheision-coupling 良いコードとは何か - エンジニア新卒研修スライド公開｜CyberZ CTO室｜note https://note.com/cyberz_cto/n/n26f535d6c575#E0aBe

Slide 22

Slide 22 text

変更への向き合い⽅、カップリング 1.5 要求の変更に取り組む

Slide 23

Slide 23 text

ผͷྫΛ࢖͍·͢ こういう話を考えてみてください • あなたは⼤学でセミナーの講師です • 参加した学⽣が、次の講義の教室へ向かえるようにしてください

Slide 24

Slide 24 text

ߏ଄ԽϓϩάϥϛϯάͷΞϓϩʔνͰ ߟ͑Δͱɾɾ 1. 学⽣のリストを取得して 2. 学⽣ごとに 1. 次の講義を調べる 2. 調べた講義の教室を調べる 3. ここから調べた教室への道のりを調べる 4. 調べた道のりを学⽣に伝える

Slide 25

Slide 25 text

੹೚Λத৺ʹߟ͑Δͱɾɾ 1. 講義ごとの教室⼀覧を壁に張り出す 2. 学⽣に「⼀覧を貼ってあるぞ！」「⾏け！！」と告げる 1. 学⽣は教室⼀覧を⾒る 2. 学⽣は⽬当ての教室を⾒つけ出す 3. 学⽣は⽬当ての教室までの道のりを把握する

Slide 26

Slide 26 text

͜ͷҧ͍͸ͳΜͩʁ • 責任の移⾏を⾏った • before: 学⽣が次の教室へ⾏くのは講師の責任 • after: 学⽣が次の教室へ⾏くのは学⽣⾃⾝の責任 • 元の問題 • 「講師が学⽣の移動にも責任を持つ」という低凝集 • 「講師が(⾃分の関係ない)講義も知る」という⾼結合

Slide 27

Slide 27 text

͜ͷ੹຿ͷҠߦΛͯ͠Կ͕خͦ͠͏ʁ • 我々はずっと「変更が云々」の話をしていますね？ • 「教室が変更になった」という変更の影響は？ • 「何かの講義が休講になった」という変更があったら？ • 「移動に使う⾃転⾞が窃盗被害に」？ • 「お腹が空いたから今⽇は帰るですって・・？」 • 影響範囲が少なくとも「講師も学⽣も」が「学⽣が」に封じ込まれる期待が持てるようになる

Slide 28

Slide 28 text

(ຊʹ͋Δ಺༰ʹ໭͠·͢) • 「セミナーが終わった時に、⼤学院⽣はアンケート結果⽤紙を集めてください」という要件が⼊った例 • 構造化〜 => 講師が「君は院⽣かな？」と問う必要 • 責任〜 => 学⽣が「私は院⽣だからな…」と判断 • 後者は学⽣が⾃らの振る舞いに責任を持てていると⾔える • 講師が知るべき情報を最⼩化できる(低結合化) • 学⽣が「やるべきこと」を⾃分で達成できる(⾼凝集)

Slide 29

Slide 29 text

໰୊ͱ؍఺ • 構造化→責任中⼼の変遷において、講師は「抽象的に語りかける」ようになっている • 1⼈1⼈の状況に応じて細々と指⽰しない • 個⼈というより「学⽣」という存在に話しかけている • 抽象度によって「概念レベル」「仕様レベル」「実装レベル」と呼ばれる観点が出てくる • が、この節の説明だとまだ捉えづらいので⼤胆に次の節へGo!

Slide 30

Slide 30 text

ࢀߟ 【中級】基礎からのオブジェクト指向第3部分析・設計⼿法の基本は「モデル作成」にあり（中編） | ⽇経クロステック（xTECH) https://xtech.nikkei.com/it/article/COLUMN/20060512/237751/ この3つの括り⾃体が相対的だなぁという所感があります。本書で「3つの観点」という話が出てくるのは、あくまで「問題領域で考える」「解決領域と思考モードを使い分けよう」みたいな事がヒントになり得るからだ、と割り切って良さげです。すなわち、「これは仕様なのか？実装なのか？」を厳密に区別できるようになってくれ・・・という話ではないかと。

Slide 31

Slide 31 text

責任とオブジェクト指向 1.6 オブジェクト指向パラダイム

Slide 32

Slide 32 text

΍ͬͱग़ͨʂΦϒδΣΫτࢦ޲ • オブジェクト指向？ • 「オブジェクト」という概念からすべてのものごとを組み⽴てる • 問題は、「機能」ではなく「オブジェクト」に分解される

Slide 33

Slide 33 text

ΦϒδΣΫτͷػೳ • オブジェクトは「責任」を持つことができる • ⾃⾝が1つの「型」として表現される • データと状態を持つ • メソッドを持つ

Slide 34

Slide 34 text

Ͳ͏͍͏ͱ͜Ζ͕خͦ͠͏͔ͬ͢ʁ • 「責任」で語っていくと、「問題領域に存在する実態」をそのまま落とし込みやすくなるね〜という点 • 問題領域 = いわゆる「要求」とか「⾮開発者でも分かる⾔葉で語られる」ような現実世界(のモデル) • つまり「ソフトウェア的な知識をなくして語った理解(モデリング)と、コードが⼀致しやすい」みたいな利点がある ※理想論 • 「ドメイン層」って⾔葉でピンとくる⼈はそれで👍 • DDDできる〜のは「オブジェクト指向の強みの発露」ではあるけど、そのプリミティブには「責任とコラボレーションの実現をサポートできる」があるよ、的な

Slide 35

Slide 35 text

ʮ3ͭͷ؍఺ʯͱΦϒδΣΫτࢦ޲ 1. 概念レベル = 責任の集合 2. 仕様レベル = 関係と振る舞い • Interface＆呼び出し元・呼び出し先、的な 3. 実装レベル = コード(データ、メソッド) • 具体的なclassとかプロパティとか

Slide 36

Slide 36 text

P15ͷphper޲͚ิ଍ “どうしたら謝った型のオブジェクトが追加されないように保証できるのでしょう” について • PHPのarrayが `mixed[]` なコレクションなのでアレですが • いわゆるジェネリクスとかああいう、「コレクション(の要素)が型を持つ (縛られる)」みたいな前提で説明されているので注意してください • と考えると、「⼤学院⽣でも学部⽣でもOKにしたい、そのためには・・」で抽象クラスの定義、というソリューションが導出されるのも違和感ないはず • 抽象(, 継承)の使い道〜みたいな話はあとの⽅で出てくる(確か)ので、今はあまり気にしなくて良さそう

Slide 37

Slide 37 text

ΧϓηϧԽͱ͍͏֓೦Λ֮͑·͠ΐ͏ • オブジェクトって「責任を持つもの」って⾔いましたよね？ • 責任を持っているという事は、責任を果たすということです • 逆に⾔えば責任さえ果たしてくれればいいよがオブジェクト指向の世界観 • 聞かれてねー事は隠しに隠してこーぜ！！！ => カプセル化

Slide 38

Slide 38 text

ͳʹΛӅ͢ͷ͔ • 「データの隠蔽」は矮⼩化した捉え⽅ • 「オブジェクト」が「データと振る舞いを持つ」ことから、「(振る舞いにおいて)データを呼び出し⼿から不可視にする」みたいな感覚があるのかも？ • カプセル化はあらゆる種類の隠蔽を含むもの • 呼び出し⼿が「意識しなくても普通に使えるね！！」という状態を提供するもの • 隠せていない = 呼び出し⼿に意識させる(責任を負わせる)

Slide 39

Slide 39 text

ϙϦϞʔϑΟζϜͱ͍͏֓೦Λ ֮͑·͠ΐ͏ • ポリモーフィズム = 多相性(多様性、多態性) • ・・・何が多様なんだ！？ • 呼び出し⼿が「Aしてね」と告げた時に、 (その責任を果たすために)必要に応じた処理を内部的に使い分けるよ • 例えば「講師 -> 学⽣ (移動してね)」といったつもりが、中では「院⽣ extends 学⽣」「学部⽣ extends 学⽣」が働いてくれてた・・・！みたいな事が成し得る

Slide 40

Slide 40 text

ΧϓηϧԽͱϙϦϞʔϑΟζϜ • ポリモーフィズムによって、プログラマはより「抽象を扱いやすい」という状態を⼿に⼊れることができるのです • 「何をしてくれているのかを知らなくていい(隠蔽されている)」からこそ「多様な処理が動く」とも⾔えるわけで、カプセル化とポリモーフィズムは近接概念として捉えておくと良きです • 抽象によればよるほど「変更に強い」というしなやかさを獲得できます • つまり・・・嬉しい！

Slide 41

Slide 41 text

※ 1.7,1.8は事前共有を割愛します 1.7は「素直にそのまま読んだ通り」な感じ。 1.8はOOP系のLLやっている⼈なら読み⾶ばしてもOKそう。