勉強まとめ

1. Clean
Architecture
第Ⅲ部
設計の原則

2. 前回まとめ
- パラダイムの概要
- プログラミングの大きな革命とされる歴史
- 構造化プログラミング
- 直接的な移行に規律を課すもの
- オブジェクト指向プログラミング
- 間接的な制御の移行に規律を課すもの
- 関数型プログラミング
- 代入に規律を課すもの

3. 第Ⅲ部：設計の原則
SOLID
- 単一責任の原則
- （SRP：Single Responsibility Principle）
- 変更する理由がたった一つだけになるように
- オープン・クローズドの原則
- （OCP：Open-Closed Principle）
- 拡張に対しては開いていて、修正に対しては閉じていなければならない
- リスコフの置換原則
- （LSP：Liskov Substitution Principle）
- 個々のパーツが交換可能となるような契約に従わなければいけない
- インターフェイス分離の原則
- （ISP：Interface Segregation Principle）
- 使っていないものへの依存を避けるべき
- 依存関係逆転の原則
- （DIP：Dependency Inversion Principle）
- 上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存すべきではなく、逆に詳
細側が方針に依存すべきである

4. 第1章：単一責任の原則（SRP）
- 原則自体は関数やクラスに関する原則
- コンポーネントレベルでは「閉鎖性共通の原則 (CCP)」と呼ばれる
- アーキテクチャレベルでは「アーキテクチャの境界」を作るための「変更の軸」と呼ばれる
- ここではモジュール単位
- モジュールはたった一つのアクターに対して責務を全うすべきである

5. 第1章：単一責任の原則（SRP）
給与システムにおけるEmployee クラス：事例

6. 第1章：単一責任の原則（SRP）
給与システムにおけるEmployee クラス：想定外の重複

7. 第1章：単一責任の原則（SRP）
給与システムにおけるEmployee クラス：マージ症状
- 1つのソースファイルで変更理由が複数あるとコンフリクトが多発する

8. 第1章：単一責任の原則（SRP）
給与システムにおけるEmployee クラス：解決策
- アクターの異なる関数を別のクラスへ移動させる
- データを関数から切り離す
- Facadeパターン

9. 第1章：単一責任の原則（SRP）
給与システムにおけるEmployee クラス：解決策
- アクターの異なる関数を別のクラスへ移動させる
- データを関数から切り離す
- Facadeパターン

10. 第1章：単一責任の原則（SRP）
給与システムにおけるEmployee クラス：Facade

13. 第2章：オープン・クローズドの原則（OCP）
- 1988年にBertrand Meyerが提唱した
- 拡張に対しては開いていて、修正に対しては閉じていなければならない
（アジャイルソフトウェア開発の奥義第二版）(SBクリエイティブ)より引用

14. 第2章：オープン・クローズドの原則（OCP）
財務情報を表示するWeb app
- 新しい要求
- 画面と同じものを白黒のプリンターで印刷したい
- 実現させるには
- 積雪なページ処理
- 各ページのヘッダー /フッター
- 列の見出し
- 負の数値は括弧で囲む

15. 第2章：オープン・クローズドの原則（OCP）
財務情報を表示するWeb app：解決策、SRP
- 変更する理由が異なるものは、単一責任の原則で分割する
- 単一責任の原則を適用するには、データフロー図を使う
- 今回はレポート作成の責務が 2つになるため分割する (図参照)

16. 第2章：オープン・クローズドの原則（OCP）
財務情報を表示するWeb app：解決策、方向の制御
- それらの依存関係を依存関係逆転の原則で適切にまとめる
- 一方に影響を与えることなく変更できるように
- 処理をクラスに分割する
- それぞれのクラスをコンポーネントにまとめる
- 二重線(コンポーネント)を超える線は全て一方通行になっていること
- オープン・クローズドの原則に最も適しているのは、 Interactorである
- Interactorは最上位レベルのビジネスルールを含んでいるため何の影響も及ぼさない

19. 第2章：オープン・クローズドの原則（OCP）
クラスレベル

22. 第3章：リスコフの置換原則（LSP）
- 1988年に Barbara Liskov が派生型について定義した
- ざっくりまとめると「派生クラスはその元となったベースクラスと置換が可能でなければならない」
- 派生クラスでオーバーライドされたメソッドはベースクラスのメソッドと同じ数・型の引数ととらなけれ
ばならない
- 派生クラスでオーバーライドされたメソッドの返り値の型はベースクラスのメソッドの返り値の型と同じ
でなければならない
- 派生クラスでオーバーライドされたメソッドの例外はベースクラスのメソッドの例外と同じ型でなけれ
ばならない

23. 第3章：リスコフの置換原則（LSP）
違反例
画像1
画像2
画像3

24. 第3章：リスコフの置換原則（LSP）
満たしている例

25. 第4章：インターフェイス分離の原則（ISP）
- 使用していないものに意図せず依存すべきではない

27. 第5章：依存関係逆転の原則（DIP）
- 依存関係が具象ではなく抽象だけを参照しているものが、最も柔軟なシステムである
- JSだとimportの参照先がinterface/abstractなどの抽象宣言だけに限定する
- 現実的にはOSヤプラットフォームは変化しないとみなす
- 開発中のモジュールや頻繁に変更されているモジュールが対象になる

28. 第5章：依存関係逆転の原則（DIP）
安定した抽象
- 変化しやすい具象クラスを参照しない
- 型ありでも動的でも interface/abstractを参照する
- 一般的にはAbstract Factoryパターンを使うしかない
- 変化しやすい具象クラスを継承しない
- 上記と同じ
- extendsの参照先は抽象クラスであるべき
- 具象関数をオーバーライドしない
- 具象関数はソースコードの依存を要求することが多い
- 関数を抽象関数にして、それに対する複数の実装を用意する
- リスコフの置換原則に違反しないことも求めています
- 変化しやすい具象を名指しで参照しない
- 上記の原則を言い換えただけ

29. 第5章：依存関係逆転の原則（DIP）
Factory

30. 第Ⅲ部：まとめ
- 単一責任の原則
- （SRP：Single Responsibility Principle）
- 変更する理由がたった一つだけになるように
- オープン・クローズドの原則
- （OCP：Open-Closed Principle）
- 拡張に対しては開いていて、修正に対しては閉じていなければならない
- リスコフの置換原則
- （LSP：Liskov Substitution Principle）
- 個々のパーツが交換可能となるような契約に従わなければいけない
- インターフェイス分離の原則
- （ISP：Interface Segregation Principle）
- 使っていないものへの依存を避けるべき
- 依存関係逆転の原則
- （DIP：Dependency Inversion Principle）
- 上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存すべきではなく、逆に詳細側が
方針に依存すべきである