日常と照らし合わせて理解するSOLID原則

SOLID原則について

Transcript

1. 日常と照らし合わせて理解する SOLID原則 だーら（twitter: @3tdara) Iwaken Lab / Flamers
2. 自己紹介 - だーら / 設楽広太 - Flamers CPO - VRマッチングアプリ Memoria - VRChatter / 作曲なども - zenn
3. これが神資料です。いったんこれ見れば最強。 - Unity開発で使える設計の話＋Zenjectの紹介 by とりすーぷさん こちらもよき - リスコフの置換原則（LSP）をしっかり理解する
4. SOLID原則とは - オブジェクト指向で開発するときに、守った方がよい基本原則 - 5つの原則の頭文字 - S … Single Responsibility Principle: 単一責任の原則 - O … Open-Closed Principle: オープン・クローズドの原則 - L … Liskov Substitution Principle: リスコフの置換原則 - I … Interface Segregation Principle: インターフェイス分離の原則 - D … Dependency Inversion Principle: 依存性逆転の原則
5. 単一責任の原則とインターフェイス分離の原則は、原則 自体の理解は割と簡単なので軽く。
6. 単一責任の原則と、インターフェイス分離の原則 - 単一責任の原則 - クラスが担当する責任は 1つだけ - Why?: クラスの中でたくさん機能を持つと、変更がクラス内の他の箇所や、そのクラスに依存して いるクラスに及びやすい - How?: 命名に気を付ける（〇〇Manager => 〇〇Mover, 〇〇Animator） - インターフェイス分離の原則 - 使ってないメソッドに依存しない - Why?: 意図しない動作が出来てしまうので、バグが起きやすい。 - How?: インターフェイスを適切に分離
7. 残り3原則は、 「抽象」をうまく使おうという点で通じる部分がある。
8. 「抽象」をうまく使う3原則 - オープン・クローズドの原則 - クラスは、拡張にはオープンで、変更にはクローズドであるべきだ。 - リスコフの置換原則 - 派生型（サブクラス）は、その基底型（スーパークラス）と置換可能でなければならない。 - 依存性逆転の原則 - 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存 すべきである。 - 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。
9. これらは、原則の内容や目的が、いまいち掴みにくい。 日常に照らし合わせて考えてみる。
10. 会社に新しいメンバーが入社し、Slackに入れる - ストーリー - 新入社員が入社した。 - Slack係は、その人がビズかエンジニアかを考慮し、チャンネルに招待する。 - ビズは、#general・#bussiness - エンジニアは、#general・#develop 君はビズだね。 では、 #general・#businessに 入ってください。 君はエンジニアだね。 では、 #general・#developに 入ってください。
11. コード ここが闇 追加の度に変更
12. 新しい職種が追加された - 新職種 - 会計係 - 人事 - お手伝いのお母さん - Slack係は混乱し始めた - 会計係、#general・#finance - 人事は、#general・#recruit - …あれ、お手伝いのお母さんって Slack入れるんだっけ？言われてないけど？ 新しい職種が追加されるたびに、Slack係のやることが変更されている。 これは、オープン・クローズドの原則に違反している。
13. Slack係が混乱する原因 - 新しいメンバーの職種を見極め、入るチャンネルを指示する分岐処理を、Slack係 が担当している。 - 職種が増えるたびに、Slack係には新しい分岐処理を追加しなければならない。 ↓ - 各職種ごとにクラスを作り、親クラスを継承させる、または、インターフェイスを実装 させることで解決する。
14. 抽象を継承/実装する - 各職種クラスに、Memberクラスを継承させる。 または、ISlackJoinableインターフェイスを実装させる。 - 自分自身で、自分が入る必要のあるチャンネルを調べ、自分で入る。 - （談義テーマ: このインターフェイスの命名って何が良い？） - Slack係は、新メンバーの職種を知らない。入れと命令だけする。 Slackに入れ！ Slackに入れ！
15. 基底クラス継承の場合 ただ命令するだけ 条件分岐しない 自分で判断 基底クラスで受けとる 継承 継承
16. インターフェイス実装の場合 インターフェイス ただ命令するだけ 条件分岐しない 実装 実装
17. （職種クラスがMemberクラスを継承する設計としたとき） この設計が機能するのは、 Slack係がMember（基底クラス）に対して、 「Slack入れ！」と言えば、 （派生クラスが）必ず入ってくれる からである。
18. 例えばもしエンジニアが、 「自分で調べるのめんどいので、Notionリンクだけくれ」 とか言い出したら破綻する。 また、if文で判断する設計に巻き戻り。 Slackに入れ！ まじか、エンジニアは面倒くさがりだか ら、職種ごとに対応変えないと ... あー、チャンネル一覧の Notionのリンクも らえます？
19. 派生型（サブクラス）が、その基底型（スーパークラス）と 置換可能ではなくなっている。 ↓ リスコフの置換原則違反 オープン・クローズドの原則違反に繋がる。
20. （Interfaceを実装する場合）依存性も逆転している 抽象（Slackに入れ！という、変わらないやりたいこと）が安定する 詳細（それぞれの職種が、どう Slackに入るか）は変わりやすいので、抽象から依存させたくない。
21. 残したトピック - 継承の方で書いた場合、依存性って逆転してないですよね？ - Memberクラスは、Slack係の都合で設計されてるわけではない。 - Interface実装でやる方が良い？（ can-do関係） - デメテルの法則（尋ねるな、命じろ）とも関連しそう？ - 使う側が、使われる側の中身について考えない。命じて、あとは自分自身で考えさせる - 依存性注入の話 余談 - リアルの職場でも依存性逆転させたい場面ありそう（マネージャーが楽になる）