dependency-injection - 依存性注入中毒？

Question

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

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

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

考え？悪い経験？それとも気にするのをやめますか？

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

曖昧でごめんなさい。マーティン・ファウラーは、おそらく私が今までできなかったよりもはるかにうまく説明しています...努力を無駄にする必要はありません.

偶然にも、これはそれについての 1 つのポイントを確認します。それは、それがまだ広く実践されておらず、チームで作業するときに全員がそれに慣れていない場合に障壁になる傾向があるということです.

score 13 · Accepted Answer

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

score 5 · Accepted Answer

私が DI で抱えている問題は、COM や次のようなコードで抱えている問題と同じです。

i = GetServiceOrInterfaceOrObject(...)

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

ドキュメントが非常によく書かれていない限り、オブジェクト間の関係を理解することは依然として容易ではありません。関係は一時的なものであり、発見するのがさらに難しくなることがあります。

私は KISS の原則が好きで、仕事に適したツールを使用することを強く信じています。特定のプロジェクトで DI の利点が、わかりやすいコードを記述する必要性を上回る場合は、DI を使用するよりも重要です。

score 4 · Accepted Answer

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

score 4 · Accepted Answer

また、それが自分の使っている言語の一部になれば、もっと気分が良くなるでしょう。

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

ServiceLoaderクラスを使用すると、クラスに基づいてサービス (またはサービスの多くの実装) を要求できます。

 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/servicesという名前のフォルダーを作成し、dependencyinjection.FooServiceという名前のファイルを作成します。このファイルには、サービスの実装を指す行が含まれています。その場合:dependecyinjection.FooImpl

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

score 3 · Accepted Answer

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

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

score 3 · Accepted Answer

心配するのはやめましょう。私の意見では、いずれ IoC 技術はほとんどの開発者にとって第二の天性になるでしょう。私は職場の開発者にそれについて教えようとしていますが、メッセージを伝えるのが難しいと感じています。また、IoC と私が見つけたプロジェクトの両方に不慣れな開発者は、さらに苦労しています。彼らは、IDE を使用して依存関係の軌跡をたどり、全体がどのように「つながっている」かを理解することに慣れています。その情報は、難解な XML に書き込まれることがよくあります。

score 2 · Accepted Answer

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

score 1 · Accepted Answer

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

score 0 · Accepted Answer

@Blorgbeard: http://www.martinfowler.com/articles/injection.htmlは、おそらくこの件に関する最高の記事の 1 つです。

dependency-injection - 依存性注入中毒？

9 に答える 9

Related

Reference