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に依存してしまう

  • 直接使用しないものに依存してはならない

  • 【補】デメテルの法則 (Law of Demeter, LoD)

    • または最小知識の原則 (Principle of Least Knowledge)
  • ISPやCommon Reuse Principleで再度論ずる

Conclusion

• OCPはアーキテクチャの背景にある原動力

• 目標は、システムを…

  • 大きな影響を被る変更を加えることなく
  • 容易に拡張できること

• 実現するには

  1. システムをコンポーネントに分割する

     • 【補】SRPに則って

  2. 依存のヒエラルキーを構築する

     • 下位のコンポーネントの変更から上位のコンポーネントを守る
     • 直接使用しないクラスに推移的に依存しない
     • そのために適宜インタフェースを設けたりする

英語

• spectacular

  • 壮大な