Когда я должен использовать привязки аннотаций против более специфичных интерфейсов? - PullRequest
0 голосов
/ 07 октября 2011

Вопрос

Какие критерии следует использовать при выборе между:

  • указанием зависимости с аннотацией и
  • указанием зависимости с более конкретным интерфейсом

Пример

Предположим, у меня есть:

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, у меня есть [по крайней мере] два способа связать это:

Используйте привязку аннотации

Измените:

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)

, где NonCachingFooLoader просто расширяется FooLoader,а затем наберите DBFooLoader орудия NonCachingFooLoader и подключите соответствующим образом.

Мои мысли

Меня привлекает использование привязки аннотаций по нескольким причинам:

  • Ключи могут быть более легко использованы повторно, чем интерфейсы, что уменьшает комбинаторный взрыв, от которого пострадают интерфейсы.
  • Это менее инвазивно: конфигурация остается в модулях Guice, а не в «отравляющих» классах.

Однако создание более конкретного интерфейса также имеет свои преимущества:

  • Интерфейсы имеют большее значение.Как правило, только Guice будет читать аннотацию, где в качестве интерфейсов используется гораздо больше.

Итак, какие критерии следует использовать, чтобы определить, какой подход выбрать?

(пользователи Spring,насколько я могу судить, это то, что вы, ребята, называете квалификаторами.)

1 Ответ

1 голос
/ 11 октября 2011

Используйте определенные интерфейсы только , если это имеет смысл, то есть они должны предлагать другой API, и, таким образом, другие классы будут использовать их особым образом.

Если они предлагают один и тот же «сервис» по-разному, то используйте только один общий интерфейс и различайте реализации с аннотациями.

...