依存性逆転の原則
多くのプロジェクトにおいて依存性逆転の原則とパターンは一般化されるべき概念であると考えられる。これには少なくとも以下の2つの理由がある。
優れた考えの原則をコーディングパターンとみなすほうがよりシンプルである。ひとたび抽象クラスやインターフェースが実装されるとプログラマーは「自分は抽象化のための仕事をした」と言うかもしれない。
多くのユニットテストツールがモックを作成するためにインターフェースに依存しているため、クラス間のジェネリックなインターフェースを利用することは(モジュール間に限った話ではなく一般的にも)ルールになっている。
もし、インターフェースのみに依存するモック作成ツールを使用している場合、一般化された依存性逆転パターンが必要になることがあるが、これには大きな欠点がある。
クラスに対して単純にインターフェースを実装するだけでは不十分であり、一般的に結合を減らすことにはならない。相互作用に対しての潜在的な抽象化を考える事が唯一結合を減らす設計につながり得る。
ジェネリックなインターフェースをプロジェクト内の全ての箇所で実装してしまうと、理解してメンテナンスをするのが非常に難しくなる。ソースコードを読む人は全てのステップにおいて「このインターフェースの他の実装はなんだろうか」と自問することになり、そしてその答えはほとんど「モックだけ」ということになりかねない。
インタフェースの一般化はより "plumbing code" である事が要求され、一般的に依存性注入フレームワークに依存するファクトリーなどが特にそれにあたる。
インターフェースの一般化はプログラミング言語の利用も制限する。
リモートファイルサーバー(FTP, cloud strage ...)に対するクライアントを実装しなければならないケースを想像せよ。あなたはそのクライアントに抽象インターフェースを持たせる事を考えるだろう。
Connection/Disconnection (a connection persistence layer may be needed)
Folder/tags creation/rename/delete/list interface
File creation/replacement/rename/delete/read interface
File searching
Concurrent replacement or delete resolution
File history management ...
ローカルファイル、リモートファイルの両方が同じ抽象インターフェースを提供する場合、ローカルファイルと完全に実装された依存性逆転パターンを使用するどんな上位レベルモジュールもローカルとリモートの区別なくファイルにアクセスすることが可能になる。
ローカルディスクは一般的にフォルダーを使用し、リモートストレージもフォルダーを使用するかもしれない(もしくはタグのみ、フォルダーとタグの両方など)。 もし可能であればそれらを統一する方法を決めておく必要がある。