0

質問

次のいずれかを決定する際に使用する基準は何ですか。

  • アノテーションで依存関係を指定し、
  • より具体的なインターフェースで依存関係を指定する

例

私が持っているとします：

interface FooLoader {
    Foo loadById(long id);
}

class DBFooLoader implements FooLoader {
    ... jdbc etc. etc. ...
}

class CachingFooLoader implements FooLoader {
    ...
    @Inject
    public CachingFooLoader(FooLoader delegate) {
        this.delegate = delegate;
    }
    ...
}

にバインドFooLoaderしたいとしCachingFooLoaderます。これを配線するには [少なくとも] 2 つの方法があります。

注釈バインディングを使用する

変化する：

public CachingFooLoader(FooLoader delegate)

に：

public CachingFooLoader(@NonCaching FooLoader delegate)

その後：

bind(FooLoader.class).annotatedWith(NonCaching.class).to(DBFooLoader.class);

より具体的なインターフェースを作成する

変化する：

public CachingFooLoader(FooLoader delegate)

に：

public CachingFooLoader(NonCachingFooLoader delegate)

where はNonCachingFooLoader単に extendsFooLoaderをDBFooLoader実装しNonCachingFooLoader、それに応じて接続します。

私の考え

私は複数の理由で注釈バインディングを使用することに惹かれています。

  • キーはインターフェイスよりも簡単に再利用できるため、インターフェイスが被る組み合わせの爆発が減少します。
  • 侵襲性が低くなります。構成は、クラスを「汚染」するのではなく、Guice モジュールにとどまります。

ただし、より具体的なインターフェイスを作成することには利点もあります。

  • インターフェイスにはより多くの意味があります。通常、Guice だけが注釈を読み取りますが、インターフェイスはさらに多くの用途に使用されます。

では、どのアプローチを採用するかを決定するには、どのような基準を使用する必要がありますか?

(春のユーザーは、私が知る限り、これは修飾子と呼ばれるものです。)

4

1 に答える 1

0

特定のインターフェイスを使用するのは、それが理にかなっている場合に限ってください。つまり、別の API を提供する必要があり、他のクラスが特定の方法でそれらを使用します。

同じ「サービス」をさまざまな方法で提供する場合は、共通のインターフェイスを 1 つだけ使用し、注釈を使用して実装を区別します。

于 2011-10-11T07:32:35.727 に答える