Guiceの@ImplementedByアノテーションの背後にある動機は何ですか？

最近@ImplementedBy、Google Guiceで利用できるアノテーションについて読みました。プログラマーは、依存関係注入で将来使用するために、インターフェースとその実装の間のバインディングを指定できます。これは、ジャストインタイムバインディングの例です。

次の構文を使用して、モジュールで明示的なバインディングを定義することに慣れています。

bind(SomeInterface.class).to(SomeInterfaceImplementation.class);

ドキュメントによると、これは次の@ImplementedByアノテーションの使用と同等です。

@ImplementedBy(SomeInterfaceImplementation.class)
public interface SomeInterface {
    //method declarations
}

ここでわかる唯一の利点は、コードがわずかに短いことです。同時に、このアプローチには、同じドキュメントで正しく指摘されている欠点があります。

@ImplementedBy慎重に使用してください。インターフェイスからその実装にコンパイル時の依存関係を追加します。

そのような依存関係は多くの場合問題にはならないかもしれませんが、私は個人的にそれをコードのにおいとして見ています。

@ImplementedByアノテーションを使用する価値のあるユースケースは何ですか？

1つの可能な方法は、ライブラリまたはフレームワークのコードで使用することです。ドキュメントで説明されているように、アノテーションは明示的なバインディングによって簡単にオーバーライドされるデフォルトのバインディングを提供できます。

タイプがbind()（最初の引数として）ステートメント内にあり、@ImplementedBy注釈がある場合、そのbind()ステートメントが使用されます。このアノテーションは、バインディングでオーバーライドできるデフォルトの実装を提案しています。

このようにして、ライブラリの開発者として、クライアントコードのどこかでカスタマイズできるすぐに使えるバインディングをユーザーに提供できます。

これが注釈が存在する唯一の理由ですか？それとも私が見逃しているものはありますか？ライブラリ/フレームワークを拡張するのではなく、いくつかのビジネスロジックを処理するアプリケーションだけのコードでそれを使用することで何かを得ることはできますか？

ここでの危険は注釈のみを使用していることだと思います@ImplementedBy。bind()モジュールのステートメントなどと組み合わせて適切に使用すれば、問題ありません。

デフォルトの実装はテストに最適です。多くの依存関係があるクラスをテストするたびにモックインジェクションを明示的に定義する必要があるとは限りません。つまり、多くのものが依存しているクラスがある場合（毎回モックを定義する必要があります） ）。

たとえば、次のようなクラスがあるとします。

@ImplementedBy(NoOpDataService.class)
interface DataService {
    Map<String, MyPOJO> getData();
}

そしてそれNoOpDataServiceは：

class NoOpDataService implements DataService {
    @Override
    public Map<String, MyPOJO> getData() {
        return Collections.emptyMap();
    }
}

もちろん、これを実際のコードで使用することは決してありません。Guiceモジュールでは、実際に何かを行う実装をバインドします。ただし、注入されたクラスのすべてのテストでDataServiceは、モックバインディングを使用する必要はありません。

tl; drあなたのインターフェースをあなたの実装に依存させることはコードの匂いになる可能性があることに同意します。ただし、定型コードを削除してテストを容易にすることもできます。機能を実装することは難しくありません。悪用の可能性は少しありますが、最終的には結果が悪くなりすぎることはありません（サービスが突然開始されます）。