35

IoCとDIがどれほど優れているかについて多くの記事がありますが、コードがより複雑になる可能性があるため、IoCがそれほど優れていない理由については何もありません。また、IoCをコードのコア部分に含めるのではなく、ライブラリとプラグインに含める必要があることもわかりました。記事は通常、2つのパターンがコードをより複雑にする方法についての小さな参照ですが、その詳細についてはあまり説明していません。それが私の質問です-これらのパターンを具体的にどこで使用すべきではありませんか？

これは素晴らしいスレッドです：制御の反転とは何ですか？。さらに下を見ると、スペルチェッカーに関する投稿と、スペルチェッカーが1つしかない場合にIoCがおそらく適切に使用されない方法に関する別の投稿があります。一般的なガイドラインとして、IoCを使用すべきではありません。インターフェイスに具体的なクラスが1つしかないのでしょうか。つまり、私はIMyClassを持っています。そして、IMyClassを実装する具体的なMyClassAだけを用意します。なぜそこにIoCが欲しいのですか？

MyClassA、MyClassB、およびMyClassCがあり、それぞれがIMyClassを実装している場合、これらはおそらくIoCの適切な候補です。

同じスレッドから、この投稿の意味を誰かが知っていますか？

  • 制御の反転=結婚
  • IOCコンテナ=妻
4

8 に答える 8

35

インターフェイスの実装を1つだけにすることについての質問について。IoCを使用する場合でも、インターフェイスを使用すると便利です。これらのインターフェースのモックを使用して、実際の単体テスト（インターフェースの実装が正しく機能することに依存しない）を作成する方がはるかに簡単です。IoCを使用する上での核心は、コードのテストを容易にすることです。したがって、テストしたくない場合、またはIoCなしでテストするためのより良い計画がすでにある場合は、IoCを使用しないでください。

IMHO、DI、およびIoCの複雑さの増加は、テストが容易で、コードの結合が少ないことによってもたらされます。問題を切り分けて、将来の変更を加える方が簡単です。あなたもその振る舞いをよりよく制御することができます。

IoCコンテナを使用しない場合がわかります（構成のオーバーヘッドが発生するため）。これは、コンテナを使用する代わりに手動で実行できる小さなプロジェクトで発生します。しかし、コードをテストする予定がない限り、DIを使用することによる大きな損失は見られません...

于 2009-09-01T15:11:36.283 に答える
21

制御の反転=結婚

IOCコンテナ=妻

結婚は既知のパターンの定義です-妻はそのパターンの実装です;-)

バーナード。

于 2009-09-30T03:37:06.993 に答える
15

IoCコンテナーを使用するかどうかは、個々のクラスのレベルで決定することではありません。どのプロジェクトでも、コンテナーによって作成されるタイプと作成されないタイプがあります。

複雑さのトレードオフは次のとおりです。

  • 少数のコンポーネントの場合、IoCコンテナはオーバーヘッドを追加します
  • アプリケーション内のコンポーネントの数が増えると、次のようになります。
    • IoCコンテナがないと、新しいコンポーネントの追加やリファクタリングがますます困難になる傾向があります
    • IoCコンテナを使用すると、新しいコンポーネントの追加やリファクタリングは同じままです。追加または変更するコンポーネントの直接の依存関係についてのみ心配する必要があります。

適切に設計および保守されたコードベースでさえ、サイズによって管理できなくなるという現象を経験したことがある場合は、IoCコンテナーが解決する問題を経験したことがあります。

于 2009-09-01T17:54:36.937 に答える
11

キャッスルプロジェクトから：

なぜ私はそれを使わないのですか？

概念に精通しておらず、解決しようとしている問題に気付いていない場合は、制御の反転コンテナを使用しないでください。

また、プロジェクトのサイズと複雑さによっては、IoCコンテナーが過剰になる場合があります。中規模から大規模のプロジェクトで使用することをお勧めします。

于 2009-09-01T15:08:37.973 に答える
6

IoCに関する不満は簡単に理解できます。IoCは単純なものを複雑なものに変えます。リストの各要素に対して（擬似コードで）何かをしたいとします。

for each i in list:
    do_something(i)

IoCは、基本的に、ループの反復の責任を他の誰かに移しています。したがって、次のような結果になります。

ioc = new IocContainer()
ioc.register_callback(do_something)
ioc.go()

この単純な形式でも、コードは元のコードよりも長いことに注意してください...そしてそれはIocContainerの実装をカウントしていません。

次に、最も優れた形式で、IocContainerは静的に、または静的なMain（）関数または他の隠された場所によって初期化され、register_callback（）関数は、すべてをリストするXMLファイルを反復処理する他のコードに基づいて自動的に呼び出されます。 do_something（）関数、および（場合によっては）リストの内容を反復処理します。

はい、XMLファイルによってソフトウェアがより構成可能になりました。右？単純なテキストファイルを変更するだけで、リストに対して実行する処理を変更できます。

皮肉なことに、ソースコードが長くなり、理解しにくくなったことを除けば、あらゆる種類の新しい、おそらくバグのあるライブラリ（IocContainerやXMLパーサーを含む）に依存し、実際に保守が難しくなっています。XMLコード元の単純なソースコードループよりも理解と編集が困難です（ループがどの言語で記述されていても）。また、IocContainerがその責任を引き継いでいるため、反復をどのように実行するか（ソートされているか、ソートされていないか、深さ優先か幅優先か）を正確に制御することもできません。

プラグインのようなものについては、メインアプリケーションが実行プロセスを制御し、プラグインにあちこちで助けを求めるのが論理的であるため、 IoCを使用することは理にかなっています。これは「フックの提供」と呼ばれ、IoCの用語よりもはるかに長い間使用されてきました。

ユニットテスト（私は通常それが投げられるのを見た場所です）のようなものについては、IoCは通常役に立たないことがわかります。なぜなら、テストはさまざまな奇妙な状況をシミュレートできる必要があり、IoCは常にこの方法。

IoCの基本的な前提は、データのロードとループスルーはどういうわけか困難であり、抽象化する必要があるということです。とにかく数行を超えることはなく（または別の関数に移動することもできます）、コードを保存したとしても柔軟性が低下するため、この仮定は正しくありません。

于 2009-09-01T15:30:11.270 に答える
4

IoC / DIはテクノロジーではなく、パラダイムです。あなたの質問は、「オブジェクト指向プログラミングをいつ使用すべきではないのか」という質問に似ています。これは、コードベースの個々のユニットよりも大きな決定です。

特定の質問に答えるために、手作業でオブジェクトグラフを合理的に作成できるクラスが十分になく、同じオブジェクトグラフのインスタンス化を複数回繰り返さない場合は、IoCコンテナは必要ない場合があります。

于 2009-09-01T17:55:46.873 に答える
2

簡単な答えは、単体テストを行うオブジェクトに対してのみIoCを使用すると思います。

これがばかげているように思われる場合は、申し訳ありませんが、ユニットテストを文字通り考慮せずに記述されたコードに対するフラストレーションからです。複雑さが増す理由がよくわかりません。実際のオブジェクトタイプを確実に知る必要がある場合は、実行時にいつでもクラスを出力できます。

于 2009-09-01T18:00:03.743 に答える
0

この記事では、「これらのパターンを具体的にどこで使用すべきではないか」という質問に対処します。「2つのパターン（[IoCとDI]）はコードをより複雑にする可能性がある」というコメントに関する詳細な例を示します。

http://java.dzone.com/articles/beyond-injection-concerns-ioc。

この記事の2つのポイントを要約すると：

  1. カプセル化が重要な場合は、IoC/DIを使用しないでください。
  2. IoC / DIの使用によって追加された複雑さが、IoC / DIを使用する利点とどのように比較されるかについての具体的な例を示すことができない場合は、IoC/DIを使用しないでください。
于 2013-08-12T15:40:11.723 に答える