2

すぐに構築したいアプリケーションを開始しており、後で 20 人以上の開発者によって開発されます。

複数の開発者がいる環境で DI について知っていることを踏まえて、比較的高速に構築したい新しいアプリケーションに DI を使用しますか?

現在私にとって DI を使用するコストは、すべてのオブジェクトに対してインターフェイスを使用しない場合と比べて、記述および生成されるコード行になります。そして、リフレクションのためにDIがパフォーマンスの問題にならないことを願っています。

4

4 に答える 4

2

DIは基本的にフレームワークに関するものではありません。たとえば、依存関係をパラメーターとしてコンストラクターに追加するだけの場合は、DI を行っていることになります。実際には、インターフェイスを作成する必要さえありません (ただし、テストには役立ちます。後でインターフェイスを導入するのは、Java などの言語での単純なリファクタリングです)。DI は、クラスのユーザーから作成の責任を取り除くだけです。

私の頭の中で最大のコストは、考えを変えることです。DIの考え方を学ぶ。利点には、テストが容易になることが含まれます。懸念事項の分離など。

于 2011-11-12T23:11:11.130 に答える
1

簡単に言うと、依存性注入を行わずにオブジェクト指向開発を行うのは良くありません。ひどい。私の意見では、依存性注入はよく理解された OO 開発の根幹です: 関心の分離、独立したコンポーネント間の疎結合、レイヤーでのコーディング、これらはすべて DI を使用して行われます。また、テストが非常に簡単になり、TDD、モッキング (BDD) などの手法が可能になります。

釈迦牟尼が彼の答えで言ったように、DI は使用するフレームワークに関するものではありません。Spring は DI を発明したのではなく、DI を達成するためのソリューションを提案しただけです。したがって、元の質問が「Spring を使用する必要があるか」である場合、それは個人的な好みの問題だと思います。自分でやれば、まったく同じ結果が得られます。私はコンテナ (Spring、pico など) の有無にかかわらずプロジェクトで作業してきましたが、それらにはすべて利点と欠点があります。ただし、私の個人的な好みは、それを使用せず、自分で DI を管理することです。

これはDIです：

// constructor
public MyClass(MyDependencyInterface injected) {
    this.dependency = injected;
}

またはその：

// setter injection
public void setDependency(MyDependencyInterface injected) {
    this.dependency = injected;
}

そして、リフレクションのためにDIがパフォーマンスの問題にならないことを願っています。

それが何を意味するのかわかりません。DI はリフレクションを必要としません。

于 2011-11-12T23:22:25.197 に答える
0

特に開発者が多い場合は、間違いなくDIを提唱します。

これにより、各開発者は、制御外で開発されている注入されたコンポーネントに依存することなく、独自のコードを記述してテストできます。

また、インターフェイスの定義を容易にすることができるため、どのコンポーネントからどの機能を利用できるかを誰もが知ることができます。

于 2011-11-12T23:17:00.953 に答える
0

Java の基本的な問題は、クラス A で a を実行するnew B()と、クラス A がバイト コード レベルでクラス B に非常に緊密にバインドされることを意味することです。

これは、すべての「レンガ」が非常によく「接着」されているため、結果としてアプリケーションが非常に頑丈になることを意味するため、通常は良いことです。

ただし、多くの場合、いくつかの設計上の問題をデプロイ時間 (場合によっては実行時) まで延期する必要があり、Java でこれを処理する方法は、伝統的に Factory に委任することでした。これは、おそらく別のファクトリなどに委任することさえあります。決断する場所。ifこれは通常、コード内のステートメントに対応するフラグ (プログラマーがコードを記述するときにすべての状況を予測する必要があります)、または解決するクラス名Class.forName()(コンパイラーが支援できないため脆弱です) のいずれかを含むプロパティ ファイルで行われます。

依存性注入の利点はnew、適切なオブジェクトを独自のコードの外部で作成する責任を委任することによって、オペレーターのハード バインディングを回避することです (コンテナーに、しかし神である可能性もあります)。物事をまとめることができるいくつかの非常に明確なカットラインを作成し、コード構成を提供する DI フレームワーク (Guice など) の場合、結果は堅牢でモジュラーになります。

インターフェイスの使用法は通常注入ポイントに対応するため、インターフェイスにコーディングすると、カットラインの切り込みを作成する適切な場所を簡単に特定できることに注意してください。

于 2013-01-21T14:31:43.763 に答える