クラスにコンテナーによって注入されたプライベート フィールドしかない場合はどうなりますか? それは良いですか悪いですか?その場合、テストで DI フレームワークを使用する必要があります (それは悪くないかもしれません) が、セッターも不要なコードもありません。それは悪い習慣ですか?
2 に答える
セッター メソッドは、OOP の最も重要な原則の 1 つである抽象化を実現する方法です。コードがコンテナーに依存しないことが理想的です。セッターメソッドは、DI を使用する標準的な方法を提供し、さらにコードの読みやすさを向上させると思います。クラスのインスタンス化が他の依存関係 (コンストラクターベースの DI を使用する) に依存していない限り、私は常にセッター DI を良い習慣と考えています。
DIを行うためにコンテナに依存するべきではないと思います。
お役に立てれば。
strong text**まず、setter メソッドによる DI の代替手段は何ですか? Martin Fowler は3 つの方法を区別しています: **インターフェース、セッター、コンストラクター注入。したがって、これらの方法のいずれも定義上、良いも悪いもありません。それは、それらをどのように使用し、システムに最も適しているかです。オブジェクトの作成後にフィールドを不変にする場合は、プライベート フィールドでコンストラクター インジェクションを使用します。それにもかかわらず、Setter インジェクションは DI の最も一般的な方法であり、いくつかのフレームワークがこれに依存しています。よくわからない場合は、この方法で行ってください。また、それに関する多くの情報を見つけることができます。
質問がセッターの使用をまったく対象としている場合、問題はクラスがデータ構造であるかどうかです(詳細については、Martin のClean Code ch. 6 を参照してください)。つまり、クラスにデータを保持する以外の目的がなく、フィールドをパブリックにすることができる場合 (*)。ビジネス ロジックを保持する場合は、プライベート フィールドとゲッター/セッターを使用します。
(*) 個人的にはそれには同意しませんが、それは私だけです。:-)