現実世界の事象から学ぶSOLID原則

# Object-Oriented Conference 2024
https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62

概要
オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。
コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。
これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。

しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。
「clean architecture 達人に学ぶソフトウェアの構造と設計」においても、建築家の建築設計とソフトウェアの設計は同じようなものだと示されています。

そこで、本セッションでは、現実世界に潜むSOLID原則を紹介し、SOLID原則を具象と抽象の両側面から解説します。
具象と抽象の行き来によりOOP初学者の理解を促進することを目的としています。
（人間の脳は具体的で具象的な情報を処理しやすい特性があります。そのため、具象的な例や視覚的な要素が組み込まれた話は、抽象的な概念をより身近で理解しやすいものに変換され、学習効果を高めることができます。この人間の脳の特性を逆手に取ったセッションです！）

私自身、OOPに魅了されてからまだ日が浅いですが、その浅さからくる理解の難しさは未だに鮮明に記憶に残っています。
最新の実体験をもとに、SOLID原則への理解に苦しむ初学者に寄り添い、初学者がより理解しやすいセッションを提供したいと考えています。

想定する聞き手
SOLID原則をいつどこで何のために使うのかわからないという方
OOPに興味のある学生・新卒・若手エンジニア
話さないこと
SOLID原則の厳密な定義や誕生背景
GoFのデザインパターンやClean Architecture等のOOPの実践的な技法

Transcript

1. ほりしょー 現実世界の事象から学ぶ SOLID原則
2. 自己紹介 ほりしょー エンジニア@ハコベル株式会社 DDD / Clean Architecture GraphQL / Golang / Ruby 個人開発でカクテルアプリ作成中 🍹 来週リリース予定 @H0R15H0
3. SOLID原則とは？ 変更に強く・理解しやすく・再利用できるソフトウェア構造を作るための基本原則 単一責任の原則 (The Single Responsibility Principle / SRP) 開放閉鎖の原則（The Open-Closed Principle / OCP） リスコフの置換原則（The Liskov Substitution Principle / LSP） インターフェース分離の原則（The Interface Segregation Principle / ISP） 依存性逆転の原則 (The Dependency Inversion Principle / DIP)
4. しかし、SOLID原則は難しい 原則が抽象的で理解が困難 （原則＝）当たり前過ぎるため、適用するメリットが掴みづらい コード例が現実味を帯びていない OOP初学者の前に立ちはだかる 最初の壁がSOLID原則
5. 焼き肉を例にします！ 現実世界の事象で具体的に学ぶ 本日のテーマ
6. 本スライドの流れ 各原則の概要 1. 原則に違反した例の紹介 2. 原則に従った改善例 3. 各原則のまとめ 4. ※コード例はJavaをベースにしていますが 　理解しやすさのために一部文法を書き換えています。ご了承ください。 ※時間の都合上、インターフェース分離の原則は省略します。他4原則が理解すれば容易 梱包 配送 加工 調理
7. 単一責任の原則（SRP）
8. 単一責任の原則（SRP）とは？ “モジュールを変更する理由はたったひとつだけであるべきである” “モジュールはたったひとつのアクターに対して責務を負うべきである” （表現のゆれがあるが意図しているものは変わらない） モジュール ... いくつかのデータや関数をまとめた凝集性のあるもの アクター　 ... 変更を望む人（グループ）
9. お肉担当Aさん 主役モジュール ナイフ 単一責任の原則に違反した例：仕込み作業 同じナイフを使用 同じナイフを使用 サラダ担当 新人Bさん
10. お肉担当Aさん 主役モジュール ナイフ 単一責任の原則に違反した例：仕込み作業 同じナイフを使用 同じナイフを使用 複数のアクター（Aさん・Bさん）に 対して責務を負っている状況 →SRP違反 サラダ担当 新人Bさん
11. お肉担当Aさん Aさんが使っていることを知らず ペティナイフに買い替えてしまった 単一責任の原則に違反した例：仕込み作業 サラダ担当 新人Bさん SRPに違反した状態で変更を加えると
12. お肉担当Aさん Aさんが使っていることを知らず ペティナイフに買い替えてしまった 単一責任の原則に違反した例：仕込み作業 お肉の仕込みができない 予期せぬバグ サラダ担当 新人Bさん SRPに違反した状態で変更を加えると
13. お肉担当Aさん Aさんが使っていることを知らず ペティナイフに買い替えてしまった 単一責任の原則に違反した例：仕込み作業 お肉の仕込みができない 予期せぬバグ 意図しないバグを 埋め込む可能性が高まる サラダ担当 新人Bさん SRPに違反した状態で変更を加えると
14. お肉担当Aさん サラダ担当Bさん どうすべきだったのか？ SRPに従い、アクターの異なるコードは分割する 各々独立して買い替え可能に
15. お肉担当Aさん サラダ担当Bさん 単一責任の原則違反まとめ 単一責任の原則＝“モジュールはたった一つのアクターに対して責務を負うべきである” 違反していると変更により予期せぬバグが発生しうる（＝もろい設計） 防止策：アクターの異なるコードは分割する
16. 開放閉鎖の原則（OCP）
17. 開放閉鎖の原則（OCP）とは？ “ソフトウェアの構成要素（クラス、関数、モジュール等）は拡張に対しては開いていて 修正に対して閉じていなければならない” 言い換えると... “ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべき” OCPはオブジェクト指向設計の核 『アジャイルソフトウェア開発の奥義 第2版』（SB クリエイティブ）より
18. Aさん 開放閉鎖の原則に違反した例：仕込み作業 Aさんは全ての仕込み作業が頭に入っている状態
19. Aさん 開放閉鎖の原則に違反した例：仕込み作業 今回の主役 Type()による条件分岐に注目 Aさんは全ての仕込み作業が頭に入っている状態
20. Aさん 開放閉鎖の原則に違反した例：仕込み作業 脳内 分岐追加 エビ追加 Aさんは全ての仕込み作業が頭に入っている状態 拡張（エビの追加）に伴って 既存の成果物（Aさん）の脳内も修正 →OCP違反
21. OCP違反 →既存成果物（Aさん）に修正が必要だったこと Aさん以外にも従業員がいる場合、 全従業員にエビの仕込み方法を覚えてもらう（全従業員に対して修正が）必要があり これがOCP違反の問題点 修正に時間がかかる（硬い設計） 修正漏れがあった場合にバグが残る（変更に弱い） 開放閉鎖の原則に違反した場合の問題点 「抽象」を使うことで修正が不要に
22. 食材 開放閉鎖の原則違反を改善：抽象化 Aさん
23. 肉 Aさん 野菜 エビ 食材 継承 抽象化 Cut() Cut()を実装 Cut()を実装 Cut()を実装 開放閉鎖の原則違反を改善：抽象化 食材の抽象型を用意 食材毎に具象化
24. 抽象化によりAの修正は不要に 食材をどれだけ増やそうと“Aクラス”には修正不要 （Aクラスは）修正に閉じて、（具象の食材クラスは）拡張に開いている
25. 条件分岐を一つのメソッドに共通化 Aさん （補足）よくある間違った改善 この改善の問題点 共通メソッドがSRPに違反 仕込みを分担したい場合に変更困難 仕込み処理以外に手続きが増えた場合、 条件分岐が乱立する状態は変わらない 食材 Bさん Cさん 共通 条件分岐 仕込み処理 アクターが変わっただけで 本質的には何も改善していない
26. 開放閉鎖の原則まとめ 開放閉鎖の原則＝“拡張に対しては開いていて修正に対して閉じていなければならない” 違反していると振る舞いの追加に時間がかかる（＝硬い設計） OCPによりオブジェクト指向技術から得られる 最大の利益（柔軟性、再利用性、保守性）を享受できる ポイント 抽象をうまく使うことで修正に閉じる 具象クラスの追加により拡張する 種類による条件分岐は疑え 肉 Aさん 野菜 エビ 食材 継承 抽象化 Cut() Cut()を実装 Cut()を実装 Cut()を実装
27. リスコフの置換原則（LSP）
28. リスコフの置換原則（LSP）とは？ “派生型はその基本型と置換可能でなければならない。” 言い換えると... “置換可能でないなら派生してはいけない。”
29. 餌やり 成長したら出荷 リスコフの置換原則に違反した例：牛舎 とある牛舎のルーティーン
30. リスコフの置換原則に違反した例：牛舎 コードに落とす 餌やり 成長したら出荷 餌やりを繰り返し 体重が一定超えたら 出荷
31. リスコフの置換原則に違反した例：牛舎 新たに乳牛を飼育する 餌やり 乳搾り 乳牛と肉牛は置換可能ではない（LSP違反）が 派生クラスを作成すると・・・ 出荷
32. リスコフの置換原則に違反した例：牛舎 すでに存在していたCowを継承し乳牛クラス(MilkCow)を作成
33. リスコフの置換原則に違反した例：牛舎 Farmクラスのルーティーン作業は、
34. リスコフの置換原則に違反した例：牛舎 Farmクラスのルーティーン作業は、 LSPに違反すると必然的にOCPに違反する 具象クラスを参照せざるを得ない OCP違反
35. 餌やり 成長したら出荷 肉牛農場 リスコフの置換原則に違反しないためには SRPに従ってそもそも農場を分ける 乳牛農場 餌やり 乳搾り 派生するのではなく共通部分を括り出す
36. リスコフの置換原則まとめ リスコフの置換原則＝“派生型はその基本型と置換可能でなければならない” 違反していると自動的にOCPに違反し硬い設計に IS NOT A 肉牛の品種・個体レベルにおいては置換可能かも 立場（ドメイン）によって何が置換可能なのか変わりうる リスコフの置換原則違反の見つけ方： 基本クラスから何らかの機能を省いてしまっているような派生クラスは怪しい
37. （補足）置換可能な条件 置換可能な条件＝派生して良い条件 1〜4を満たしていること 事前条件（preconditions）を、派生型で強めることはできない。派生型では同じか 弱められる。 1. 事後条件（postconditions）を、派生型で弱めることはできない。派生型では同じ か強められる。 2. 不変条件（invaritants）は、派生型でも保護されねばならない。派生型でそのまま 維持される。 3. 基底型の例外（exception）から派生した例外を除いては、派生型で独自の例外を投 げてはならない。 4. wikipedia: リスコフの置換原則より
38. 依存性逆転の原則（DIP）
39. 依存性逆転の原則（DIP） 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュール も「抽象」に依存すべきである。 1. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべき である。 2. アジャイルソフトウェア開発の奥義 第2版より 言い換えると、 “モジュールの依存関係が具象（下位）ではなく抽象（上位）だけを参照すべき”
40. 荷物を積む 車両A 荷主 運送会社A 上位 下位 依存性逆転の原則に違反した例：配送 下位モジュールに依存 （DIP違反）
41. 荷物を積む 荷主 運送会社A 車両B 車両Aが 故障 修正 車両B に変えて 車両が故障すると 依存性逆転の原則に違反した例：配送 上位 下位
42. 荷物を積む 荷主 運送会社A 車両B 車両B に変えて 車両が故障すると 依存性逆転の原則に違反した例：配送 上位 下位 車両Aが 故障 下位における変更の影響が上位伝達しやすい 修正
43. 下位モジュールへの依存による問題点 変更にもろい もし車両Aへの依存箇所が数百もあったらどうだろうか？ 車両Bへの変更完了に時間が必要 変更漏れがあった場合、バグが残る 運送会社がそもそも倒産してしまった場合どうするのか？ 車両と同様 荷主の業務（上位）が車両故障等の外部環境（下位）の変更に強くなるためには？ 荷主が振る舞いを定義して、それを満たす車両を各社で定義してもらう。 →依存性逆転の原則
44. 車両A 荷主 運送会社A 荷物を積む 抽象車両 車両B どれでも良い 依存性逆転の考え方 上位モジュールのあるべき姿 期待してくれる振る舞いをしてくれれば 下位の詳細はなんでも良い
45. 運送会社A 車両A 荷主 依存 step1)車両故障への対応：抽象に依存
46. 運送会社A 車両 荷主 依存 車両A 車両B 依存 step1)車両故障への対応：抽象に依存 具象車両への依存は解消
47. 運送会社A 車両 荷主 依存 車両A 車両B 依存 step2)運送会社への依存を断ち切る：逆転 未だ特定の運送会社に依存
48. step2)運送会社への依存を断ち切る：逆転 あるべき関係性 運送会社A 車両 荷主 依存 車両A 車両B 依存 荷主パッケージ 特定の運送会社への依存も解消
49. 処理の流れに注目 運送会社A 車両 荷主 依存 車両A 車両B 依存 荷主パッケージ 処理の流れ 依存の向きと 処理の流れが逆転 依存性逆転
50. 依存性逆転の原則まとめ 依存性逆転の原則 ＝“モジュールの依存関係が具象（下位）ではなく抽象（上位）だけを参照すべき” 違反していると変更にもろい設計に ポイント 抽象化 1. 抽象を上位モジュールに移動 2. 車両A 荷主 運送会社A 荷物を積む 抽象車両 車両B どれでも良い
51. 全体まとめ
52. 単一責任の原則 (The Single Responsibility Principle / SRP) アクターごとにモジュールを用意する（高凝集）ことで変更しやすく 開放閉鎖の原則（The Open-Closed Principle / OCP） （OOPの本質）抽象化により変更に強く リスコフの置換原則（The Liskov Substitution Principle / LSP） 無理な派生（継承）を行わずOCPに準拠する 依存性逆転の原則 (The Dependency Inversion Principle / DIP) 下位モジュールへの依存を断ち切り変更に強く
53. 参考文献 アジャイルソフトウェア開発の奥義 第2版 著：ロバート・C・マーチン / 訳：瀬谷　啓介 Clean Architecture 達人に学ぶソフトウェアの構造と設計 著：ロバート・C・マーチン / 訳：角　征典・高木　正弘
54. ご清聴ありがとうございました！ ほりしょー OOC引き続き楽しみましょう！！！