問題タブ [dependency-injection]

ZIP ファイルが与えられた場合、次のことを行う必要があるコンポーネントを作成しています。

1. ファイルを解凍します。
2. 解凍されたファイルの中から特定の dll を見つけます。
3. リフレクションを介してその dll をロードし、メソッドを呼び出します。

このコンポーネントを単体テストしたいと思います。

ファイルシステムを直接扱うコードを書きたくなります:

しかし、「ファイル システム、データベース、ネットワークなどに依存する単体テストを作成しないでください」とよく言われます。

これを単体テストに適した方法で記述するとしたら、次のようになると思います。

わーい！これでテスト可能になりました。テスト ダブル (モック) を DoIt メソッドにフィードできます。しかし、どのくらいの費用がかかりますか？これをテスト可能にするためだけに、3 つの新しいインターフェースを定義する必要がありました。そして、正確には、何をテストしていますか？DoIt 関数がその依存関係と適切に相互作用することをテストしています。zip ファイルが正しく解凍されたかどうかなどのテストは行いません。

もう機能をテストしているようには感じません。クラスの相互作用をテストしているだけのように感じます。

私の質問はこれです:ファイルシステムに依存するものを単体テストする適切な方法は何ですか?

編集私は.NETを使用していますが、この概念はJavaまたはネイティブコードにも適用できます。

いつ使用するか、どのようなフレームワークがあるかなど、依存性注入に関する特定の質問とともに、すでにいくつかの質問が投稿されています。でも、

依存性注入とは何ですか? また、いつ/なぜ使用すべきか、または使用すべきでないのですか?

PHP 4 サーバーで行き詰まっています。古いレガシー プロジェクトを、依存性注入を含む最新のデザイン パターンに移行したいと考えています。PHP 4 で動作する依存性注入フレームワークはありますか?

依存性注入自体の利点を理解しています。スプリングを例にとってみましょう。また、AOP、さまざまな種類のヘルパーなど、他の Spring 機能の利点も理解しています。次のような XML 構成の利点は何ですか?

次のような単純な古い Java コードと比較して:

これは、デバッグやコンパイル時間のチェックが容易で、Java しか知らない人なら誰でも理解できます。依存性注入フレームワークの主な目的は何でしょうか? （またはその利点を示すコードの一部。）

更新：
の場合

IC フレームワークは、複数ある場合に注入したい myService の実装をどのように推測できますか? 特定のインターフェイスの実装が 1 つしかない場合、IoC コンテナーに自動的にそれを使用するように決定させると、2 番目の実装が表示された後に壊れます。また、インターフェイスの可能な実装が意図的に 1 つしかない場合は、それを注入する必要はありません。

その利点を示す IoC の構成の小さな部分を見ることは本当に興味深いでしょう。私はしばらくSpringを使用してきましたが、そのような例を提供することはできません. また、休止状態、dwr、および私が使用するその他のフレームワークの利点を示す 1 行を示すことができます。

更新 2:
再コンパイルせずに IoC 構成を変更できることを認識しています。それは本当に良い考えですか？誰かが再コンパイルせずに DB 資格情報を変更したいときは理解できます - 彼は開発者ではないかもしれません。実際に、開発者以外の誰かが IC 構成を変更する頻度はどれくらいですか? 開発者にとって、構成を変更する代わりにその特定のクラスを再コンパイルする努力はないと思います。また、開発者以外の場合は、おそらく彼の生活を楽にして、より単純な構成ファイルを提供したいと思うでしょう。

更新 3:

インターフェイスとその具体的な実装の間のマッピングの外部構成

それを外部化することの何がそんなに良いのですか？すべてのコードを外部にするわけではありませんが、ClassName.java.txt ファイルに配置し、その場で手動で読み取り、コンパイルすることはできますが、再コンパイルを回避できます。なぜコンパイルを避けるべきなのですか?!

手続き型コードではなく宣言的にマッピングを提供するため、コーディング時間を節約できます

宣言型アプローチが時間を節約する場合があることを理解しています。たとえば、Bean プロパティと DB 列の間のマッピングを 1 回だけ宣言すると、Hibernate はこのマッピングをロード、保存、HSQL に基づく SQL の構築などに使用します。ここで宣言的アプローチが機能します。Springの場合（私の例では）、宣言はより多くの行を持ち、対応するコードと同じ表現力を持っていました。そのような宣言がコードよりも短い例があれば、それを見てみたいです。

制御原理の反転により、実際の実装を偽の実装に置き換えることができるため (SQL データベースをインメモリのものに置き換えるなど)、単体テストが容易になります。

制御の反転の利点は理解しています (ここで説明する設計パターンを依存性注入と呼びたいと思います。なぜなら、IoC はより一般的だからです。多くの種類の制御があり、そのうちの 1 つ (初期化の制御) だけを反転しています)。なぜ誰かがプログラミング言語以外の何かを必要とするのかと尋ねていました。コードを使用して、実際の実装を偽の実装に置き換えることは間違いなくできます。そして、このコードは構成と同じことを表現します-フィールドを偽の値で初期化するだけです。

DIの利点は理解しています。同じことを行うコードを構成する場合と比較して、外部 XML 構成によって追加される利点がわかりません。私はコンパイルを避けるべきだとは思いません - 私は毎日コンパイルし、今も生きています。DI の構成は、宣言型アプローチの悪い例だと思います。宣言は、一度宣言され、さまざまな方法で何度も使用される場合に役立ちます。たとえば、hibernate cfg のように、Bean プロパティと DB 列の間のマッピングが保存、ロード、検索クエリの作成などに使用されます。Spring DI 構成は、次のように簡単に変換できます。この質問の冒頭のように、コードを構成することはできませんか? そして、それは Bean の初期化にのみ使用されますよね? つまり、宣言型アプローチでは何も追加されないということですよね?

休止状態のマッピングを宣言するとき、休止状態にいくつかの情報を与えるだけで、それに基づいて機能します-何をすべきかは教えません。春の場合、私の宣言は春に何をすべきかを正確に伝えます-では、なぜそれを宣言し、なぜそれをしないのですか?

最終更新:
みんな、多くの回答が依存性注入について教えてくれています。私はそれが良いことを知っています。質問は、コードを初期化するのではなく、DI 構成の目的に関するものです。コードを初期化する方が短くてわかりやすいと思う傾向があります。私の質問に対するこれまでの唯一の答えは、構成が変更されたときに再コンパイルを回避することです。別の質問を投稿する必要があると思います。これは私にとって大きな秘密であるためです。この場合、コンパイルを避ける必要があるのはなぜですか。

税サービスのインターフェイスを ITaxService として定義し、TaxService の複数の実装を (地域ごとに) 取得したとしますが、特定の地域の特定の顧客に特定の税の実装をアタッチしたいと考えました。

このシナリオで DI は役に立ちますか? どのように？「コード スニペットをいただければ幸いです」

jsp taglib を使用して依存関係を注入する良い方法はありますか?

ejb 3.0、Spring、または Guice のいずれかを使用...

taglibs で使用したいサービス/pojo がたくさんあります

私は次のクラスを持っています：

これはプレゼンター コードです。

新しいオブジェクトをインスタンス化する代わりに、現在のインスタンスViewPageをTPresenterviaに渡したいと思います。Windsorどうすればこれを達成できますか? ありがとう。

ユーザー インターフェイスの依存性注入ツールに Microsoft Unity を使用することを考えています。

私たちの中間層はすでにキャッスル ウィンザーを使用していますが、Microsoft を使い続ける必要があると考えています。

最高の依存性注入ツールとは何かについて考えている人はいますか?

• オートファク
• Castle MicroKernel/ウィンザー
• PicoContainer.NET
• Puzzle.NFactory
• Spring.NET
• ストラクチャーマップ
• ニンジェクト
• 団結
• シンプルインジェクター
• NauckIT.MicroKernel
• WINTER4NET
• ObjectBuilder

Python のGuice ( http://code.google.com/p/google-guice ) に相当するフレームワークはありますか?

私は DI の初心者なので、これが間違ったアプローチやばかげた質問である場合はご容赦ください。

注文を作成/更新するフォームがあり、表示する製品と顧客のリストを取得する必要があることがわかっているとします。編集中の Order オブジェクトを渡したいのですが、依存関係として ProductsService と CustomersService も注入したいと考えています。

そのため、IoC コンテナー (どちらを使用する場合でも) でサービスを提供する必要がありますが、編集する Order オブジェクトを提供するのは呼び出し元のコード次第です。

Order オブジェクトを最初のパラメーターとして受け取り、その後に ProductsService と CustomersService を受け取るようにコンストラクターを宣言する必要があります。

...または、依存関係が最初に来て、 Order オブジェクトが最後に来る必要があります。例:

それは問題ですか？使用する IoC コンテナーに依存しますか? それとも「より良い」方法はありますか？