依存性注入の反対を示す専門用語？

これは、純粋に技術的な質問というよりも、命名法（技術文書）です。私は、アプリケーションでの依存性注入の拡大を中心に、リファクタリングの提案を書いています（そして、それを自分に割り当てます）。Beanの自動配線にSpringを使用していますがMyClass obj = new MyClass(...)、を使用してBeanをインスタンス化するインスタンスがまだあります。私の提案では、エレガントな命名法を使用し、適切な用語でDIの反対のデザインパターンを参照したいと思います。

「密結合」は、DIの反意語として適切な用語ですか？

いいえ。密結合は、依存性注入が処理する以上のものです。

依存性注入は、実装の決定を外部化します。これは切り離しに大いに役立ちますが、カップリングはこれ以上のものです。

依存性注入の良い反意語は、依存性のハードコーディングです。ビヘイビアーオブジェクト内で構築する（新しいファクトリーを使用するか、直接ファクトリーを使用する）場合、2つの異なる懸念事項をまとめてしまいます。サービスロケーターは分離に役立ちますが、ユーザーはサービスロケーター自体に結合されたままになります。

結合は、構造と動作を分離するだけではありません。クラスAからクラスBに特定の順序で呼び出す必要がある101個のメソッドがある場合、私は密結合しています。構造と動作がどれほど素晴らしく分離されていても構いません。

結合は、2つのオブジェクトの相互依存性の尺度です。他方に影響を与えずに一方を変更することを困難にすることに貢献するものはすべて、カップリングに貢献しています。依存性注入はこれに役立ちますが、これだけではありません。

厳密に言えば、依存性注入は実際にはNOT依存性注入にのみ反対します。したがって、依存性注入ではない依存関係管理戦略にのみ反対します。

[望ましくない]カップリングは、厳密に直交する問題ではありませんが、どちらの方法でも発生するか、軽減される可能性があります。これらは両方とも以下に結合されDependencyClassます。

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructorDependencyClassこの場合、特定のものに結合されます。しかし、それらは両方とも結合されていDependencyClassます。本当の悪は、ここに存在する場合、必ずしもカップリングではありません。突然、独自の依存性を注入する必要があるDependencyLookupConstructor場合、変更するDependencyClass必要があります¹。

ただし、このコンストラクター/クラスはさらに疎結合です。

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

C＃で作業している場合、上記は、呼び出されたときに何でもServiceLocator返すことができるようにします。完全なインターフェイス²に結合することなく、コンパイル時の署名検証のメリットを享受できます。GetMyDoer()do()DependencyLocatingConstructordo()

だから、あなたの毒を選んでください。

しかし、基本的に、依存性注入の具体的な「反対」がある場合、それは「依存性管理戦略」の領域の別のものになります。とりわけ、会話で次のいずれかを使用した場合、依存性注入ではないと認識します。

• サービスロケーターパターン
• 依存関係ロケーター/場所
• オブジェクト/依存関係の直接構築
• 非表示の依存関係
• 「非依存性注入」

^{1.皮肉なことに、DIが上位レベルで解決する問題の一部は、下位レベルでDIを使用しすぎた結果です。私は不必要な複雑さを持つコードベースに取り組んでの喜び持っていたすべてのオーバーとしてその複雑さは、実際に助けた場所の一握りを収容した結果を...私は確かに悪いの暴露によってバイアスされています。}

^{2.サービスの場所を使用すると、依存関係がどのように構築されているかについて大部分はわからないまま、呼び出しコードからの機能的役割によって同じタイプの異なる依存関係を簡単に指定できます。解決する必要がある場合UserやIUser、さまざまな目的で、たとえば、Locator.GetAdministrator()対、またはその他のことを行う必要があるとしますLocator.GetAuthor()。私のコードは、サポートするインターフェイスを知らなくても、機能的に必要なものを尋ねることができます。}

特定の広く受け入れられている業界用語があることは知りませんが、思い浮かぶ代替案には、内部インスタンス作成、内部依存関係作成、ローカル依存関係、またはローカルスコープ依存関係が含まれます。

私は依存関係のカプセル化に行きます。これは、再度アクセスして離れるのではなく、依存関係がロックされていることを表しています。