フィールドインジェクションとは正確には何であり、それを回避する方法は？

フィールドインジェクションは推奨されないというSpring MVCおよびポートレットに関するいくつかの投稿を読みました。私が理解しているように、フィールドインジェクションとは、次の@AutowiredようなBeanをインジェクトすることです。

@Component
public class MyComponent {
    @Autowired
    private Cart cart;
}

私の研究中に、コンストラクター注入についても読みました：

@Component
public class MyComponent {
    private final Cart cart;

    @Autowired
    public MyComponent(Cart cart){
       this.cart = cart;
    }
}

これらのタイプの注射の両方の長所と短所は何ですか？

EDIT 1：この質問はの重複としてマークされているとおり、この質問私はそれをチェックします。質問にも回答にもコード例がないため、使用している注入タイプを推測して正しいかどうかはわかりません。

注射タイプ

依存関係をBeanに注入する方法には3つのオプションがあります。

1. コンストラクタを介して
2. セッターまたはその他の方法
3. 反射を通して、フィールドに直接

オプション3を使用しています。これは@Autowired、フィールドで直接使用する場合に起こります。

注入ガイドライン

Springが推奨する一般的なガイドラインは次のとおりです（コンストラクタベースのDIまたはセッターベースのDIのセクションを参照）。

• 必須の依存関係の場合、または不変性を目指す場合は、コンストラクター注入を使用します
• オプションまたは変更可能な依存関係の場合は、セッター注入を使用します
• ほとんどの場合、フィールド注入を避けます

フィールド注入の欠点

フィールド注入が嫌われる理由は次のとおりです。

• コンストラクターインジェクションの場合のように、不変オブジェクトを作成することはできません
• クラスはDIコンテナーと密接に結合しており、それ以外では使用できません
• リフレクションなしでクラスをインスタンス化することはできません（たとえば、単体テストで）。それらをインスタンス化するにはDIコンテナーが必要です。これにより、テストは統合テストのようになります。
• 実際の依存関係は外部から隠されており、インターフェース（コンストラクターまたはメソッド）には反映されません。
• 10個ほどの依存関係を持つことは本当に簡単です。コンストラクターインジェクションを使用している場合、10個の引数を持つコンストラクターがあり、何かが怪しいことを通知します。ただし、フィールドインジェクションを使用して無期限にフィールドを追加できます。依存関係が多すぎると、クラスは通常複数のことを実行し、単一の責任の原則に違反する可能性があるという危険な状態になります。

結論

ニーズに応じて、主にコンストラクターの注入、またはコンストラクターとセッターの注入の組み合わせを使用する必要があります。フィールド注入には多くの欠点があり、回避する必要があります。フィールドインジェクションの唯一の利点は、すべての短所を上回るわけではないので、書く方が便利であることです。

参考文献

フィールドインジェクションが通常推奨されない理由についてブログ記事を書きました：フィールド依存性インジェクションは有害と見なされます。

これはソフトウェア開発における終わりのない議論の1つですが、業界の主要なインフルエンサーはこのトピックについてより理解を深め、より良いオプションとしてコンストラクターインジェクションを提案し始めています。

コンストラクター注入

長所：

• テスト性の向上。単体テストでは、モックライブラリやSpringコンテキストは必要ありません。新しいキーワードを使用して、テストするオブジェクトを作成できます。このようなテストはリフレクションメカニズムに依存しないため、常に高速です。（この質問は30分後に行われました。作成者がコンストラクターインジェクションを使用した場合は表示されませんでした）
• 不変。依存関係がいったん設定されると、変更することはできません。
• より安全なコード。コンストラクターの実行後、パラメーターとして渡されたものを検証できるため、オブジェクトを使用する準備が整います。オブジェクトは準備ができているかどうかに関係なく、その間に状態はありません。フィールドインジェクションを使用すると、オブジェクトが壊れやすいときに中間ステップを導入できます。
• 必須の依存関係のより明確な表現。この問題では、フィールドインジェクションがあいまいです。
• 開発者に設計について考えさせます。ditは、8つのパラメーターを持つコンストラクターについて書きました。これは、実際には悪いデザインとGodオブジェクトのアンチパターンの兆候です。クラスのコンストラクタまたはフィールドに8つの依存関係があるかどうかは関係ありません。常に間違っています。人々はフィールドを介するよりもコンストラクターに多くの依存関係を追加することに消極的です。これは、しばらく停止してコード構造について考える必要があるという、脳への信号として機能します。

短所：

• より多くのコード（ただし、最新のIDEは痛みを軽減します）。

基本的に、フィールド注入はその逆です。

好みの問題。それはあなたの決定です。

しかし、なぜコンストラクター注入を使用しないのかを説明できます。

1. すべての@Service、@Repositoryおよび@ControllerBeanにコンストラクターを実装したくありません。つまり、豆は40〜50個以上あります。新しいフィールドを追加するたびに、コンストラクターを拡張する必要があります。いいえ、必要ありません。必要はありません。

2. Bean（サービスまたはコントローラー）に他の多くのBeanを注入する必要がある場合はどうなりますか？4つ以上のパラメーターを持つコンストラクターは非常に醜いです。

3. CDIを使用している場合、コンストラクターは関係ありません。

編集＃1：Vojtech Ruzickaは言った：

クラスの依存関係が多すぎ、おそらく単一責任の原則に違反しているため、リファクタリングする必要があります

はい。理論と現実。次に例を示しDashboardControllerます*:8080/dashboard。単一パスにマップされます。

私DashboardControllerは他のサービスから多くの情報を収集して、ダッシュボード/システム概要ページに表示します。この単一のコントローラーが必要です。したがって、この1つのパス（基本認証またはユーザーロールフィルター）のみを保護する必要があります。

編集＃2：誰もがコンストラクターの8つのパラメーターに集中しているので...これは実際の例-お客様のレガシーコードです。私はそれを変えました。同じ論法が4つ以上のパラメーターに当てはまります。

これは、インスタンスの構築ではなく、コードインジェクションに関するものです。

もう1つのコメント-Vojtech Ruzickaは、Springは次の3つの方法で豆を注入すると述べています（ポイント数が最も多い答え）。

1. コンストラクタを介して
2. セッターまたはその他の方法
3. 反射を通して、フィールドに直接

この答えは間違っています-あらゆる種類の噴射に対して、春は反射を使用するためです！IDEを使用して、セッター/コンストラクターにブレークポイントを設定し、チェックします。

これは好みの問題になる場合がありますが、CASEの問題になる場合もあります。@dieterは、フィールドインジェクションが優れている優れたケースを提供しました。Springコンテキストを設定している統合テストでフィールドインジェクションを使用している場合-クラスのテスト可能性を含む引数も無効です-統合テストに後でテストを記述したい場合を除きます;）