Guice에서 @ImplementedBy 주석의 동기는 무엇입니까?

최근 Google Guice@ImplementedBy 에서 사용할 수 있는 주석 에 대해 읽었습니다 . 이를 통해 프로그래머는 인터페이스와 구현 간의 바인딩을 지정하여 향후 의존성 주입에 사용할 수 있습니다. JIT (Just-In-Time) 바인딩 의 예입니다 .

다음 구문을 사용하여 모듈에서 명시 적 바인딩을 정의하는 데 꽤 익숙합니다.

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

설명서에 따르면 이는 다음 @ImplementedBy주석 사용과 동일합니다 .

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

내가 볼 수있는 유일한 이득은 코드가 약간 짧다는 것입니다. 동시에이 접근법에는 동일한 문서에서 지적한 단점이 있습니다.

@ImplementedBy신중하게 사용하십시오 . 인터페이스에서 구현으로 컴파일 타임 종속성을 추가합니다.

이러한 의존성은 많은 경우 문제가되지 않지만 개인적으로 코드 냄새라고 생각합니다.

@ImplementedBy주석을 사용할 가치가 있는 사용 사례는 무엇입니까 ?

한 가지 가능한 방법은 라이브러리 또는 프레임 워크의 코드에서 사용하는 것 같습니다. 문서에서 설명했듯이 주석은 명시 적 바인딩에 의해 쉽게 무시되는 기본 바인딩을 제공 할 수 있습니다 .

유형이 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 나는 당신의 인터페이스가 당신의 구현에 의존하는 것이 코드 냄새 일 수 있음에 동의합니다. 또한 상용구 코드를 제거하여 테스트를 쉽게 할 수 있습니다. 기능을 구현하는 것은 어렵지 않습니다. 남용의 가능성은 적지 만 결과는 그리 나쁘지 않으며 (서비스는 놀라움으로 시작됩니다), 발생하더라도 해결하기가 어렵지 않습니다.