Dependency Inversion Principle

• 具象に依存するな

• 具象のモジュールって何

  • 実際にコールされる関数が実装されているモジュール

• もちろん避けられない依存もある

  • String型とか
  • 抽象化するのは困難だし、するべきでもない

• 具象でも、安定していて変化しないことがわかっていれば依存してよい

  • OS
  • プラットフォーム

• 変更されやすい具象に依存するな

  • 活発に開発され、頻繁に変更されている

Stable Abstrations

• 実装が変更されても、インタフェースは必ずしも変更されない
• 【補】インタフェースが変更をうけるとすべてが影響を受ける
• 良い設計とは、インタフェースを変更することなく機能を追加できるもの

• 下記の慣行に還元される

  • 変更されやすい具象クラスを参照するな

    • 代わりに抽象インタフェースを参照せよ
    • オブジェクトの生成ならAbstract Factory (Gang of Four)とか

  • 変更されやすい具象クラスから派生するな

    • 静的型付け言語において、継承は最も密結合
    • 【補】変更されやすいものに密結合するな、ということ

  • 具象関数をオーバライドするな

    • オーバライドされる具象関数じたいが依存を持っている
    • オーバライドするということは、上記の依存を引き継いでしまうということ
    • 代わりに抽象関数をオーバライドせよ
  • 具体的で変更されやすい名前はNG

Factories

• 具象クラスを直接newすると依存してしまう
• Abstract Factory使え

• システムは2つのコンポーネントに分かれる

  • Abstract

    • 高水準のビジネスルール

  • Concrete

    • ビジネスルールが操作する低水準の実装詳細

• 制御フローは依存の向きと逆になることに注目

  • だから「Dependency Inversion」

Concrete Components

• 具象ServiceImpl —> 具象ConcreteImplがあるので、ここはDIP違反

• DIP違反は完全には取り去れない

  • 少数の具象コンポーネントにまとめて隔離することが寛容

    • 【補】関数型パラダイムで、完全に取り去れない副作用を隔離するのと似てますね

  • エントリポイントは具象

    • main関数とか

Conclusion

• 高水準のアーキテクチャの原理原則について読み進めていくと、DIPは何度も繰り返し出てくる

  • 依存の矢印という形で目に見えて現れる
  • アーキテクチャのバウンダリをまたいだ依存を単方向にするために使用

英語

• capricious

  • 気まぐれな