MarkSeemannによる.NETのDependencyInjectionを読んでいますが、一生の間、これに頭を悩ませることはできません。
新しいキーワードは、揮発性依存性に関してはコードの臭いですが、安定性依存性に使用することを心配する必要はありません。新しいキーワードは、一般的に突然「違法」になることはありませんが、VOLATILEDEPENDENCIESのインスタンスを取得するために使用することは控えてください。
たぶんそれは、グローバル変数ではなくインジェクションであるアンビエントコンテキストに頭を悩ませることができないためかもしれませんが、著者が言っていることを理解していないだけです。
DIを上から下まで理解したいのですが、今は行き詰まっていて、これは本の3分の1の道のりです... Control-Freakアンチパターンは、これまで生きてきたすべてのプログラマーのようです。 ..。。
誰かが何か洞察を持っていますか？
ボラティリティ（私にとって）は、クラスを変更する必要がある可能性の尺度です。
理想的には、拡張に対してオープンであるが変更に対してクローズであるようにクラスを設計します（オープンクローズド原則）。これが常に可能であるとは限りません。変更に近いクラスは、他のクラスよりも揮発性が低くなります。
NDepend（.Net静的分析メトリクスツール）には、私の考えでは同義語である不安定性と呼ばれるメトリクスがあります。彼らはこれを次のように定義しています。
不安定性（I）：総結合度に対する効率的な結合度（Ce）の比率。I = Ce /（Ce + Ca）。このメトリックは、アセンブリの変更に対する回復力の指標です。このメトリックの範囲は0から1で、I = 0は完全に安定したアセンブリを示し、I=1は完全に不安定なアセンブリを示します。
StableクラスがStableクラスに依存することは望ましくありません。
注入するかどうかを決定する限り、それはクラスの役割の問題のように聞こえます。ドメイン駆動設計から、（DDD）クラスは通常、エンティティ（IDを持っている）、サービス（物事を調整する）、または値（REDや100mlのように不変で比較可能）のいずれかです。
あなたはサービスを注入し、Valuesでnewを呼び出します。エンティティは通常、（注入する）リポジトリから取得されますが、内部的にはリポジトリがそれらに対してnewを呼び出します。それは役に立ちますか？
通常、DIコンテナは、すべての依存関係を具体的な実装に解決し、存続期間を処理します。しかし、DI Control-Freakは反対のことをしますnew。キーワードを使用して具体的なオブジェクトを作成し、それらを注入して、自分だけでライフタイムを処理します。したがって、コードの外部で依存関係を構成および処理する可能性は他にありません。したがって、他の実装や偽物を提供して、再利用またはテストします。
これが@mark-seemannの本からの引用で、あなたの質問に答えます。
DEPENDENCIESの制御を放棄しないクラスを説明するために、これをCONTROLFREAKと名付けました。
これは、新しいキーワードを使用して型の新しいインスタンスを作成するたびに発生します。これを行うときは、インスタンスの存続期間を制御し、他の誰もその特定のオブジェクトをインターセプトする機会がないことを明示的に示します。
これらの用語はこれまで聞いたことがありませんが、依存性注入について知っていることを置き換えて、次のように定義します。
安定した依存関係とは、具体的な実装が、クラスや構成、時間の経過、またはさまざまな状況で変化しない依存関係です。
揮発性の依存関係とは、その具体的な実装が、クラスや構成、時間の経過、またはさまざまな状況で変化する可能性がある依存関係です。
Javaでの例を許すことができれば、安定した依存関係はになりますStringBuilder。文字列を作成するメソッドを作成している場合は、StringBuilder注入する必要はなく、作成するだけで済みます。ArrayList、などの同上HashMap。標準ライブラリクラスを超えて、銀行のアプリケーションを作成している場合、RunningTotaliserそれは単に数値を合計するオブジェクトであるため、おそらく注入しないでしょう。
標準ライブラリの揮発性の依存関係の例は、思い付くのが難しいです。古典的な例はDataSource-データベースの接続の詳細をカプセル化するオブジェクトであり、実際に接続を行っているコードによってそれらが提供されることはほぼ確実ではありません。