Clean Architecture Part III ch8 OCP: The Open-Closed Principle
- OCP: The Open-Closed Principle
- A Thought Experiment
- Directional Control
- Information Hiding
- Conclusion
- 英語
OCP: The Open-Closed Principle
- 1988, Bertrand Meyer提唱
A software artifact should be open for extension but closed for modification.
- 「拡張に対して開いていて、変更に対して閉じていること」
- 既存のコードをいっぱい触らないといけないのは設計が壮大にしくじっている
- クラスやモジュールについてのOCPは多くの学生が知っているところ
- 【補】こういうやつ
- クライアントコードはShapeインタフェースに依存
area()メソッドで面積計算できる
- 新しい図形の面積計算を実装したくなったら、Shape実装クラスを追加するだけでいい
- 既存クラスに変更を加えない
- SOLID原則で掲げるのは、より高水準なアーキテクチャレベルの話
- 中水準の場合とは考えることが変わってくる
A Thought Experiment
- 帳票出力の例
- まずSRPを適用して、データフロー図を得る
- 会計データを入力し、レポート可能データを出力する手続き
- レポート可能データを入力し、Web用形式で出力する手続き
- レポート可能データを入力し、印刷用形式で出力する手続き
- クラス図
- コンポーネント単位で見るとこう
- component B --> component A
- BはAに依存
- Bの変更からAを守りたいときはこうする
- Interactorは一番大事
- ビジネスルールをもつため
- なので、他すべての変更から守るために他すべてから(推移的に)依存されている
- 保護のヒエラルキーができあがる
- Interactorは最上位
- ControllerはPresenterよりは上位
- PresenterはViewよりは上位
- これが「アーキテクチャレベルでのOCP」
Directional Control
Information Hiding
- FinancialReportRequesterインタフェースの役割
- ないとどうなるの
- FincancialReportControllerが推移的にFinancialEntityに依存してしまう
Conclusion
- OCPはアーキテクチャの背景にある原動力
- 目標は、システムを...
- 大きな影響を被る変更を加えることなく
- 容易に拡張できること
- 実現するには
英語
- spectacular
- 壮大な
