問題タブ [dependency-inversion]

コンストラクターで 2 つの ArrayList 依存関係を削除するために、このクラスを DIP (依存関係反転原則) に従うように変更するにはどうすればよいですか? インターフェイスはどうあるべきですか？

私を混乱させることの 1 つは、新しい参照ArrayList<type>がクラスのコンストラクターだけを指していないことです。そして、私はその状況に対処する方法がわかりません...

}

}

}

}

}

}

これは VTC デザイン パターンのビデオ チュートリアルからのものです。

factory.createConnection() は抽象化ではなく具体的​​な実装を返すため、TestConnection クラスは具体的な実装に依存するためです。

代わりにこれを行うことでこれを修正できますか?

}

Headfirst Design Patterns のこの例は、「抽象化に依存する。具体的なクラスに依存しない」という「依存関係逆転の原則」に違反しています。

上記の例は、DependentPizzaStore (高レベル コンポーネント) がピザ (低レベル コンポーネント) の具体的な実装に依存しているため、規則に違反しています。

これを修正するために、Factory Method パターンを使用します。

現在、PizzaStore (上位コンポーネント) は、Pizza 具象クラスの Pizza 抽象化のみに依存しており、具象 Pizza もピザの抽象化を拡張しているため、Pizza 抽象化に依存しています。

私の質問は: NYPizzaStore クラスは、Pizza の具体的な実装である CheesePizza() と VeggiePizza() に依存しているため、「依存性反転原則」にも違反していますか。

コマンドパターンには、Invoker、Command、Receiverの3つの主要コンポーネントがあります。クライアントは、 Receiverで特定のメソッドを呼び出すために必要な情報をInvokerに提供しますが、実際にを呼び出すのはCommandオブジェクト（Receiverによって格納されます）です。MM

a）CPを実装するには、コマンドの数を増やしてもInvokerクラスを変更する必要がないように、 Invokerのロジックをコマンドの数から切り離す必要があります。これを行うには、CommandオブジェクトとInvokerを抽象化（つまりインターフェイス）に依存させます。

そのため、CPはDIPの特定の実現だけではありませんか？

b）CPが実際にDIPの実装である場合、 CPが他のタイプのDIP実装と正確に異なる点は何ですか？つまり、 DIPの他のすべての実装にもInvokerオブジェクト（つまり、より高いレベルのモジュール）、Commandオブジェクト（つまり、より高いレベルのモジュールに動作を提供する依存関係）があり、Receiverは依存関係オブジェクト（つまり、下位レベルのモジュール）呼び出し？

ありがとうございました

編集：

a）

依存オブジェクトは依存関係をフィールドとして保持し、それを後続のすべてのメソッド呼び出しに使用します。

そして、依存オブジェクトがこの依存関係をフィールドとして保持しない場合、したがって、すべてのsubsequnt呼び出しにそれを使用するのではなく、常に新しい依存関係オブジェクトを受け取ります。次に、DIではなくCPがあると主張できますか？

逆もまた同様です。Invokerが常に同じコマンドオブジェクトを呼び出す場合、実際に実行する作業コマンドオブジェクトに関係なく、CPではなくDIがあると主張できますか？

b）あなたが言いたいことは理解していますが、何が何かを振る舞うのか、何がコマンドなのかを区別するのに、まだいくつかの大きな問題があります。私の見解では、コマンドをInvokerに渡すことは、依存オブジェクトがそのジョブを実行するために必要な動作を注入することとして解釈することもできます。それは本当にとても明確ですか、それともより主観的ですか？したがって、オブジェクトによって実行される作業がコマンドであるか動作であるかをどのように判断するのでしょうか。

依存性逆転の原則は次のように述べています。高レベルのモジュールは低レベルのモジュールに依存すべきではありません。

それを念頭に置いて、私の古い：

なりました

別のUI実装を簡単にアタッチできるように、ビジネスロジックレイヤーに応じてUIを維持しました。私のビジネスロジック層は頭脳です。

しかし、それは依存性逆転の原則を破っていますか？UIはビジネスロジックよりも高いレベルですよね？

助けてくれてありがとう。

進化する基本アプリケーションがあります。現在、UIにはBLLが含まれています。DALは、その目的を果たす別個のライブラリです。

今はすべてを行う時間がないので、デカップリングに役立つパターンをバイパスしたいと思います（IoC、DI、ここで提案されています）。

BLLを作成し、DALのリファレンスを直接取得したいと思います。これにより、今必要な個別のUIの作成を開始する機会が得られます。

私の質問は私がそれをすることができますか？今すぐ3つのレイヤーの作成に集中し、コードを改善するためにデザインパターンを徐々に適用できますか？

追加情報：

最初のアプリは2番目のアプリの開発中に使用されないため、時間の余裕があります。だから私は私のコーディング構造を最適化する時間があります。UIをできるだけ効果的にUI+BLLに分割するために私が知ることができる質問。私の考えでは、BLLでDAL initを移動し、UIにBLLinitを配置します。後でIoC/DIを適用するときに、もっと役立つことができる他の何かがありますか？

asp.netで単純なMVCアプリケーションを構築しています。依存性逆転の原則に従いたいのですが、正しく行っているかどうかわかりません。

私は現在、認証システムに取り組んでいます。内部でAuthenticatorサービスを使用するAccountControllerがあります。オーセンティケーターサービスは、コンストラクターインジェクションによってコントローラーにインジェクトされます。

ファイルの構造は次のとおりです。

しかし、コントローラーとその依存関係の間の良識を完全に逆転させたい場合は、認証サービスのインターフェースをコントローラーの隣に移動する必要があると考えていました。このようなもの：

このようにして、クライアント（コントローラー）とサービスの抽象化は同じ名前空間に存在します。したがって、サービスのインターフェースの変更はクライアントから行われ、サービスの実装に伝達されます。以前の方法の代わりに、サービスで発生する変更がクライアントに伝播されました。依存関係は反転しています-サービスはクライアントに依存しています。

クライアントとサービスが異なるアセンブリにある場合にこれの利点を確認できますが、同じアセンブリに関してこれを行う必要があるかどうかはわかりません。

私がこれを正しく行っているかどうか、そして最初のファイル構造を使用するか、2番目のファイル構造を使用するかを教えてください。

ありがとう、Asier

私はWCFサービスを持っており、依存関係の反転原則に従っていました。私はいくつかの質問と以下のリストを持っています. 依存関係の原則の前と依存関係の原則の後のコードを以下に示します。

依存関係の原則の前のコード:-

依存関係の原則の後のコード:-

1）しかし、「提供されたサービスタイプは、デフォルト（パラメーターなし）のコンストラクターがないため、サービスとしてロードできませんでした。問題を解決するには、デフォルトのコンストラクターをタイプに追加するか、インスタンスを渡します」というエラーが表示されますホストへのタイプの」。

しかし、デフォルトのパラメーターを指定しても問題は解決しません。問題を解決するための解決策を教えてください。

2) ノード node= new Nodes(); // この依存関係を削除するにはどうすればよいですか? 【コードをご覧ください】

3)依存性逆転の原則とwcfは良いアプローチですか?

ありがとう。

「Castle Windsor」という名前の Dependency Injection Container を使用して、Dependency Inversion Principle を実装することができました。しかし、私の場合、 Nodes クラスのオブジェクトを作成することは「依存関係」とは呼ばれていないようです。

私はこのように読みました。

「データのみのオブジェクトは、必要な機能を実行しないため、通常、「依存関係」とは呼ばれません。」何かご意見は？

ありがとう。

依存性逆転の原則は次のように述べています。

• 高レベル モジュールは低レベル モジュールに依存すべきではありません。どちらも抽象化に依存する必要があります。
• 抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。

アプリケーションで高レベル モジュールと低レベルモジュールを実際に見つけるにはどうすればよいですか? それらの明確な定義はありますか?