依存関係の逆転の原則：「高レベルのポリシー」と「低レベルの詳細」を他の人に定義する方法は？

私は、依存関係の逆転の原則を（ほとんどは後輩の）同僚に説明しようとしています。ソフトウェアの「高レベルポリシー」と「低レベル詳細」を定義するにはどうすればよいですか？たとえば、ソフトウェアが複数のビジネスアプリケーションのワークフローを自動化する場合、ワークフローの自動化が高レベルのポリシーであり、ビジネスアプリケーションが詳細であると言うのはなぜですか？

注：これは以前の例から完全に書き直されました

電源ソケットについて考えてください。どの国でも、高レベルのポリシーは、電源ソケットは常に同じであるということです。（石炭、ガス、原子力）からどこに電気を供給するかは問題ではありません。壁のソケットは、同じコネクタセットを介して常に同じ量の電力を出力する必要があります。

すべてのデバイスに共通のインターフェース「プラグ」があるため、任意のデバイスをそのソケットに接続できます。高レベルのポリシーは、その実装の詳細のどの部分も指示する必要はありません。何かを差し込むだけです。

これで、AC電源を必要としないデバイス（おそらく7V DC回路で動作するデバイス）があれば、その高レベルのポリシーを引き続き使用でき、電源とデバイスの間に何らかのアダプターが必要になります。また、誰もが同じ高レベルのポリシーを持っているため、メーカーは高レベルのポリシーを変更することなく、それを実装に組み込むことができます。実装をポリシーに接続する人（ラップトップを接続する）も、実際に理解する必要はありません。

さらに、メーカーが同じデバイスを別の国で販売したい場合、彼らがしなければならないことは、異なるアダプターを開発することだけです。したがって、同じ実装で複数のポリシーを使用でき、同じポリシーで複数の実装を実行できます。

これは、依存関係の反転の完璧な例です。

しかし、興味深い点があります。最初に言ったことに戻ります。「どこから電気を得るかは関係ありません。」これも実装の詳細です。高レベルのポリシーでは、すべての電源ソケットは同じ形状であり、同じタイプの電力を放出します。低レベルの実装の詳細は、電力の供給元と実行内容の両方です。

プログラミング用語では、高レベルポリシーは、APIが提供し、アプリケーションが消費するインターフェイス（言語がサポートする場所。DIのもう1つの形式です）を意味し、低レベル実装の詳細は両方ともそれを消費するアプリケーションとAPI自体。どちらもお互いを理解する必要はありません。

アダプタを使用して、同じ実装を異なるポリシーに適合させることができます。

ソフトウェアの再利用における古典的なアプローチは、他に何も依存しないコンポーネントを構築することであり（これが低レベルになります）、次に低レベルのコンポーネントに依存する高レベルのコンポーネントを構築します。「高レベル」と「低レベル」は、コンポーネントの機能に固有ではなく、多くの場合単にアーキテクチャ上の決定に依存する依存関係の方向によって具体的に決定されます。

したがって、単一のビジネスアプリケーションがワークフロー自動化に依存せずに構築されているが、ワークフローコントローラーがビジネスアプリケーションに直接依存している場合、ワークフロー自動化は「高レベルポリシー」であり、ビジネスアプリケーションは「低レベル」コンポーネント。この構造は必須ではないことに注意してください-ワークフロー自動化コンポーネントが一般的なフレームワークであり、特定のビジネスアプリケーションとも結合されていないが、異なるアプリケーションを提供するように構成できる場合は、すでにDIPの適用を開始しています。この状況では、「高レベル」/「低レベル」の分離は、これら2つのものの間でもはや意味をなさない場合があります。

そのため、「依存関係の反転」という名前はやや誤解を招きます-依存関係は「反転」せず、完全に削除されているためです（正確には、コンパイル時の依存関係を実行時の依存関係に変更します）。

簡単な画像を使用してDIPを説明します。ソフトウェア開発の古典的な見方は、各層がそれをサポートする下位層の上にある構築プロセスとしてのものです。依存関係反転の原理を使用することは、モバイルを構築することに似ています。

上位層が下位層に座っているのではなく、モバイルインターフェースの上位層は、それらを接続する文字列を介して下位層と接続しています。ある意味では、下位層はサポートのためにそのインターフェースに依存します（落下する文字列なし）。それは一言で言えばDIPです。