•  09-06-2019
  •  | 
  •  

質問

マイナス面はありますか？今ではほぼそれに依存しているような気がします。プロジェクトが一定のサイズを超えると、標準パターンに対するアレルギー反応をほとんど感じ、すぐに依存性注入フレームワークを使用して再接続します。

私が発見した最大の問題は、それを学んだばかりの他の開発者にとって混乱を招く可能性があることです。

また、それが私が使用している言語の一部であれば、ずっと気分が良くなるでしょう。ただし、少なくとも Java については、非常に優れた非常に軽量なライブラリがいくつかあります。

考えは？悪い経験はありますか？それとも心配するのをやめますか？

[編集] Re:依存性注入自体の説明

曖昧ですみません。 マーティン・ファウラー おそらく私がこれまで説明したよりもはるかにうまく説明していると思います...努力を無駄にする必要はありません。

偶然にも、このことは、それがまだ広く実践されておらず、全員がそれに慣れていない場合、チームで作業する際に障害となる傾向があるという、この点についての 1 つの点を裏付けています。

役に立ちましたか？

解決

私はここのブログ投稿で考えられる欠点のいくつかを説明しました。 http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

他のヒント

DI に関する問題は、COM や次のようなコードに関する問題と同じです。

i = GetServiceOrInterfaceOrObject(...)

問題は、そのようなシステムがコードから理解できないことです。サービス/インターフェイス/オブジェクト X によってどのサービス/インターフェイス/オブジェクトをリクエストできるかを定義するドキュメントが [他の場所] のどこかに存在する必要があります。このドキュメントは維持するだけでなく、ソースと同じように簡単に利用できるようにする必要があります。

ドキュメントがよほどうまく書かれていない限り、オブジェクト間の関係を理解するのは依然として簡単ではないことがよくあります。場合によっては、関係が一時的なものであるため、発見がさらに難しくなります。

私は KISS の原則が好きで、仕事には適切なツールを使用することを強く信じています。特定のプロジェクトにおいて、わかりやすいコードを書く必要性よりも DI の利点が大きい場合は、DI を使用する必要はありません。

また、それが私が使用していた言語の一部であれば、私はずっと気分が良くなります。

参考までに、JDK 6 の一部として、非常にシンプルで機能的な依存関係の注入があります。軽量で簡単な依存関係の注入が必要な場合は、それを使用してください。

使用する サービスローダー class を使用すると、クラスに基づいてサービス (ま​​たはサービスの多くの実装) をリクエストできます。

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }

ServiceLoader は返されるサービス実装をどのように定義しますか?

プロジェクト フォルダーに、という名前のフォルダーを作成します。 META-INF/サービス という名前のファイルを作成します 依存関係の注入.FooService. 。このファイルには、サービス実装を指す行が含まれています。その場合:dependecyinjection.FooImpl

このことはまだ広く知られていません。

私はIOの大ファンですが、誰も理解できない巨大なXML設定ファイルを含むプロジェクトをいくつか見ました。したがって、XML でのプログラミングには注意してください。

私の意見では、主な欠点は、学習曲線 (ご指摘のとおり) と、抽象化が追加されることでデバッグがより困難になる可能性 (これも実際には学習曲線の一部です) です。

私にとって、DI はより大規模で複雑なシステムに適しているように思えます。小規模な 1 回限りのアプリの場合、基本的にアプリが過度にアーキテクチャ化される可能性があり、アーキテクチャを遵守するのに開発時間が必要になります。それが提供する価値でそれを補うことはできます。

心配するのはやめてください。私の意見では、やがて IoC テクニックはほとんどの開発者にとって自然なものになるでしょう。私は職場の開発者にこのことについて教えようとしていますが、これまでのやり方ではとても不自然に感じられるため、メッセージを伝えるのが難しいと感じています。それはたまたま間違った方法だっただけです。また、IoC を初めて使用する開発者も、プロジェクトに初めて参加する開発者も、さらに苦労していることがわかりました。彼らは、IDE を使用して依存関係の痕跡をたどり、全体がどのように「連携」しているかを理解することに慣れています。その情報は多くの場合、難解な XML に書き込まれます。

家で一緒に遊んでいる私たちのために、依存関係の挿入とは実際には何なのかを説明するリンクを 1 つか 2 つ追加していただけますか?の ウィキペディアの記事 面白いですが、あまり啓発的ではありません。

私が考える唯一の欠点は、継続的な仮想呼び出しによるパフォーマンスのわずかな低下です:)

@ブログビアード: http://www.martinfowler.com/articles/injection.html おそらくこのテーマに関する最高の記事の 1 つです

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top