12

私は単純なツリー構造のデータベースを開発しており、通常はビルダー (ビルダー パターン) を介して依存関係またはオプション設定を設定しています。たとえば、いつ Guice を使用するか、いつ Builder パターンを使用するか、いつコンストラクター自体の代わりに静的ファクトリ メソッドを使用するかがわかりません。私はEffective Javaを何度か読みましたが、コンストラクターを公開しないことの少なくとも多くの利点について言及していると思います。読み直す時が来ました;-)

では、明確に区別できるケースを知っていますか? そして、コンストラクターを公開するべきではありませんか? したがって、たとえば、すべての場合にpublic static Foo getInstance(...) { return new Foo(...)}?を書きます。

4

3 に答える 3

15

私は、依存性注入をすべてに使用する必要はないと固く信じています。

  • a の場合、その実装を構成によって交換できるようにaを注入LookupServiceするのは自然なことです。Dictionary

  • Firewall一方、aの場合。FireWallRulesおそらく供給されたFactoryやBuilder.

ガイドラインとして、構成に必要なものを注入し、他のすべてを自動的に注入しないでください。

static factory (*)いつを考える

  • 名前付きの構築ロジックが必要です。例えば、Lists.newArrayList()
  • 構造が複雑すぎてクラス自体に属さない
  • ファクトリの構成は不要であり、ファクトリには副作用がありません

検討instance factoriesする時期

  • 複雑なインスタンス化ロジックがある
  • 工場の設定が必要です
  • AbstractFactoryデザインパターンの使用
  • プログラムのライフサイクル全体で追加のオブジェクトを作成する必要がある

builderいつを考える

  • 複雑なパラメーターの選択があります。たとえば、一部がオプションである 5 つのパラメーター。

(*) 静的メソッドは常にテスト可能であるとは限らず、私の意見では、静的メソッドの存在は常に動機付けられるべきです。工場の典型的なユースケースは、カップリングを減らすことです。static factoryその能力を使用すると、完全に失われます。

于 2012-09-20T21:05:34.283 に答える
13

ビルダーパターンと依存性注入

これらの2つは、あなたの心の中でどのように匹敵するものに近いのでしょうか？ビルダーパターンは、コンストラクターが圧倒的な数のパラメーター（オプションの可能性がある）を持つクラスを処理する必要がある場合に使用されます。このパターンにより、コードの読み取りと書き込みが容易になります
。

依存性注入は、高レベルのクラスから低レベルのクラスへの依存性を取り除く緩い結合を容易にするアプローチです。たとえば、データベースに接続する必要のあるクラスは直接接続を作成しませんが、接続は「注入」され、この接続は、それを使用するコードに影響を与えることなく、別のデータベースにスワップできます。

于 2012-09-20T21:23:50.200 に答える
2

ほとんどのプロジェクトでビルダーの使用を開始しましたが、すべての DI をビルダーとシングルトンに置き換えることができることがわかりました。

すなわち:

AppContext appContext = 新しい AppContext.Builder()
.setProperties(testProps)
.setDB(テストDB)
。建てる（）;

// テストを実行

私のコードは、DI なしで管理するのがはるかに簡単になりました。

于 2015-03-04T20:10:09.787 に答える