私の同僚と私は、ここ数週間論争が続いています。そして、これについてコミュニティの意見を聞きたかったのです。
アプリケーションではguiceを使用します。このアプリケーションの UI 部分では、すべてのフィールドとコンポーネントを DI とカスタム アノテーション (ファクトリの配置としても知られています) を介してインスタンス化し、それらを buildUI メソッドに接続することを好みます。
それは次のようになります。
私のアプローチ:
@Inject
@PreConfigured(caption="foo", width="100%")
Label field;
private void buildUI() {
this.addComponent(field);
}
データ バインディングと i18n の注釈もいくつか書きました。
私の同僚はこのようにしています：
彼のアプローチ:
private Label field;
private void buildUI() {
field = new Label();
field.setCaption("foo");
field.setWidth("100%");
this.addComponent(field);
}
ここのコードは非常に長くなる可能性があります。データ バインディングやその他のトピックを考慮すると、2 番目のコードはさらに長くなる可能性がありますが、私のアプローチは別の注釈にすぎません。
私の理由は次のとおりです。
- すべてのコンポーネントの動作と外観を構成する中心的な場所
- コードの再利用
- パフォーマンス - 長時間実行されるアプリケーションでは、コンポーネントの初期化コードが「ホット」になり、jit がさらに最適化を行います。
- より読みやすく。
彼の理由は次のとおりです。
- 可読性
- ビュー コードがあちこちに散らばっているわけではありません。
- クラスはDIなしで機能します
- 特に具象クラスが注入される場合、依存性注入の柔軟性は過大評価されています。
- DI を使用する唯一の有効な方法は、コンストラクター インジェクションです。
しかし、Fowler の記事もいくつか読みました。彼は、セッター インジェクション (フィールド インジェクションによる代用) は設計上の決定として不適切であると述べています。しかし、他のプロジェクトで再利用されないビューはどうでしょうか?
フィールド注入は悪い設計ですか? それとも、上記の他の方法はよりエレガントですか?
敬具クリスチャン
PS: 議論が単に意見に基づいて始まったことは知っていますが、それは長い間進行中の議論 (セッター対コンストラクター注入) であり、おそらく手放す価値があります。