依存性注入とIoCコンテナーを使用する利点は何ですか？
Dependency InjectionとIoC Containersについて講演する予定で、それを使用するためのいくつかの良い議論を探しています。
この手法とこれらのツールを使用する最も重要な利点は何ですか？
私にとって最も重要なのは、 単一の責任の原則 を理解しやすくすることです。
DI/IoCを使用すると、オブジェクト間の依存関係を簡単に管理できます。これにより、一貫性のある機能を独自のコントラクト（インターフェイス）に分割しやすくなります。その結果、DI/IoCを知って以来、コードははるかにモジュール化されています。
これのもう1つの結果は、 オープン-クローズドプリンシプル をサポートするデザインまでの道のりをずっと簡単に確認できることです。これは、最も信頼性の高い手法の1つです（自動テストに次いで2番目）。私は、開閉原理の美徳を十分に支持できるとは思えません。
DI/IoCは、プログラミングのキャリアにおいて「ゲームチェンジャー」であった数少ないものの1つです。 DI/IoCを学ぶ前と後で書いたコードの間には、品質に大きなギャップがあります。もう少し強調しておきます。 [〜＃〜]巨大[〜＃〜]コード品質の改善。
実際に私の目を開いた例は、そのようにして作成されたオブジェクトを簡単に単体テストすることがどのように可能になったかを見ていました。その前は、単体テストでオブジェクトを分離するのに苦労していました。私はしばしば、はるかに大きなシステムと相互作用するためのテストを作成しました。システム全体が予測可能性が低く、個々のコンポーネントよりも変更される傾向があるため、これは本当に困難でした。
依存性注入の利点は次のとおりです。
- コードはクリーンで読みやすくなっています。
- コードは疎結合です。
- 実装はXMLファイルで構成されているため、再利用性が高く、別のコンテキストで使用できます。
- コードは、さまざまなモック実装で簡単にテストできます。
実際の利益は技術的というより政治的だと思います。 DIはService Locatorパターンの代わりに過ぎません。それ自体では、SRPやOCPのような原則に従うことや、レイヤーを分離することは容易ではありません。ここの他の回答者は、さまざまな概念と手法を混乱させています、IMO。
サービスロケーターを使用するか、該当する場合は常に依存関係を直接インスタンス化することによって（ほとんどの場合）、高い凝集性と低い結合に関して同じ目標を達成できます。
今、私は多くの人がこの意見に反対することを知っています。具体例についてお話しさせていただきます。