language-agnostic - 依存性注入のベストプラクティスとアンチパターン

Question

私は依存性注入に比較的熟練していないので、DIを使用するときにそれぞれ使用するベストプラクティスとアンチパターンを学びたいと思います。

Answer 1

DI に関するこの記事は、DI の経験があまりないか、DI が何であるかさえ知らない人を対象としているため、非常に興味深いものでした。

https://mtaulty.com/2009/08/10/m_11554/

ユニティとは？

It’s a “dependency injection container”.

さて、その時点で、これを読んでいる多くの人々は、「はい、私たちは知っており、A、B、C の理由で既に使用しているか、X、Y、Z の理由で使用しないことを選択しました」と言うでしょう。他の多くの人が言うかもしれないと思います。

“Huh? What’s a dependency injection container?”

この投稿は後者の人々のためのものです – 網羅的であることを意図したものではありませんが、完全に役に立たないわけではないことを願っています :-)

Answer 2

私の意見では、Dhanji Prasanna の著書Dependency Injectionは、初心者と専門家の両方のソフトウェア設計者にとって必読です。DI に関する質問に直接対処します。

Answer 3

Guice のユーザー ガイドにベスト プラクティスのセクションがあります。

Answer 4

デメテルの法則の違反を見つけたとき、それは依存性注入が必要かもしれないというヒントであることがわかりました。

例えば：

void doit()
{
    i += object.anotherobject.addvalue; //violation of Law of Demeter
}

依存性注入が必要な場合があることを示唆することがありanotherobjectます。

Answer 5

いつ DI を使用するかについての私の基本的なルールは、レイヤー間に注入することです。つまり、コントローラーと dao の間がレイヤーになるので、注入できるので、レイヤーをモックアウトしたい場合はできるようになります。

同じレイヤー内で DI を使用することは良い考えではないと思います。これは主に、レイヤーが関連しているため、レイヤーが密接に結合されている必要があるためです。ユーザー ストーリーが役立つ場合を除きます。

たとえば、DAO が別々のコンピューター上にある場合、それらが 1 つのレイヤーであると見なすことができる必要があるかもしれませんが、DI を使用して、実際には 1 つのマシン上のすべてと別のマシンの間で切り替えることができます。その後、開発者は 1 台のマシンですべてを実行でき、別のマシンで動作するはずです。

しかし、差し迫った必要がない限り、同じレイヤー内での DI は不必要な複雑さだと思います。

Answer 6

依存性注入のアンチパターンは次のとおりです: Multiple Constructors。