依存性反転の原則(DIP)

依存性反転の原則とは

• 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存するべきである。
• 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存するべきである

上位モジュールに依存しない場合のメリットとして、

• ユニットテストがしやすい。
• 別の実装に入れ替えやすい(再利用性が高い)

パターン

• Poor Man's Dependency Injection
  • アプリケーションのエントリポイントに近い場所で、具象クラスをまとめて注入する(合成ルート)
    • コードが読みやすい=依存関係がわかりやすい
    • インターフェースが入れると具象クラス入れる作業が単純作業で多くなる。
  • コンストラクタ注入
    • 多々使用する依存関係の場合はコンストラクタで注入する
  • メソッド注入
    • 一部メソッドでしか使用しない場合は、メソッドで注入する
  • プロパティ注入
    • 実行時にプロパティ変更したい場合はプロパティで注入する
• IoCコンテナ(制御の反転)
  • DIコンテナで依存関係のクラスの認識を自動で行う。
    • Registerでリストに具象クラス追加
    • Resolveでリスト内の具象クラスをインターフェースの継承先として自動で判別させる。
    • Releaseでインスタンス開放
    • Disposeはアプリケーション終了時に呼ばれる
• 宣言型の登録
  • 実体をXMLに記載して、コードでXML読みこむ。そうすることで、実行時に読む実体を切り替えることができる
  • ただし、記載がすごく多くなってしまう。
  • また、タイポなどは実行時までわからない
• Service Locatorアンチパターン
• Illegitimate Injectionアンチパターン
  • コンストラクタの引数で、インターフェースに実体注入できるようになっていても、引数なしのコンストラクタで、デフォルト設定用の実体クラス生成している場合がある。それをしてしまうと、結局依存してしまってることになるので全く意味がない。
• 規約手法
  • DIコンテナを使って、明示的にインスタンス名を記載せずに完全に自動で依存関係を判断させる方法
    • 例
      • binフォルダに格納されているアセンブリに含まれるクラスを全て登録
      • それらのクラスを、クラスの名前とマッチするインターフェースにマッピング

結論

結局は、他の原則で作成したインターフェースの実体をどこで作るかという話。

簡単なソフトウェアなら、「PoorMan'sDI」を使用し、複雑でインスタンスが増大しているソフトウェアなら「規約」

を使用すれば良い。

参照

アジャイルソフトウェア開発の奥義
C#実践開発手法