この上位モジュールと下位モジュールの双方が抽象に依存しなければならないという内容は、それまでの人々のオブジェクト指向の常識を覆しているものだった。この二点の背景にある考えとは、上位モジュールと下位モジュールの相互作用を設計する際は、その相互作用自体も抽象的に考える必要があるということである。上位モジュールの抽象化だけではなく、それを詳細化する下位モジュールへの見方も変えて、インターフェースの使い方も変えることを求めている。多くの場合、相互作用を抽象的に捉えることは、追加のコーディングパターンを増やすことなくコンポーネント間の結合を減らせることに繋がる。これはより軽量で小規模な実装依存性相互作用スキーマを実現する。モジュール間で見出された抽象的相互作用スキーマが汎用的な意味をなしているならば、この設計原則は依存性逆転のコーディングパターンを適切な方向に導く。歴史.従来のレイヤーパターン.依存性逆転パターン.依存性逆転パターンの一般化.もし、インターフェースのみに依存するモック作成ツールを使用している場合、一般化された依存性逆転パターンが必要になることがあるが、これには大きな欠点がある。一般化における制約.依存性逆転のパターン(DIP)を達成するためにインターフェースが存在することは、オブジェクト指向プログラムにおいて他の設計上の制約をもたらす:インターフェース・モック化の制約.継承ベースのモック化ツールを使用した場合でも以下の制約が生じる。将来的な方向性.原則は考えるための方法であり、パターンは問題解決のための共通手段である。コーディングパターンはプログラミング言語に欠如している機能であるとみなされるかもしれない。実装.上位レベルコンポーネントのインターフェースは下位レベルコンポーネントによって実装されるため、コンパイル時に下位レベルコンポーネントが上位レベルコンポーネントに依存する事が必要になる。よって従来の依存関係は逆転する。抽象コンポーネントをライブラリやパッケージから独立させて置くと、より柔軟性が増す。全てのレイヤーを分離して個別のパッケージに置くことでどのレイヤーの再利用性も向上し、ロバストネス性とモビリティーを得ることができる。例.家系モジュール.