2016-06-24 3 views
2

У меня возникли проблемы с Dagger2, что следующее:Предоставление различных объектов конкретизации с Dagger2

У меня есть XML Serializer, который принимает формат, стратегию и Искателя. Моя проблема заключается в том, что формат может быть один из следующих:

new Format() 
new Format("<?xml version=\"1.0\" encoding=\"UTF-8\"?>") 

Мой способ исправить это, чтобы создать интерфейсы Классификатор следующим образом:

@Qualifier @Retention(RUNTIME) public @interface NoFormat {} 

@Qualifier @Retention(RUNTIME) public @interface WithFormat {} 

[Edit:] // @Qualifier @Retention(RUNTIME) public @interface FormatSerializer {} <- This was unecessary 

[Edit:] // @Qualifier @Retention(RUNTIME) public @interface NoFormatSerializer {} <- This was unecessary 

А затем указать различные реализации каждого классификатора:

@Provides @Singleton @WithFormat Format provideWithFormat() { 
    return new Format(XML_PROLOG); 
} 

@Provides @Singleton @NoFormat Format provideNoFormat() { 
    return new Format(); 
} 

@Provides @Singleton @WithFormat 
Serializer provideFormattedSerializer(Strategy strategy, @WithFormat Format format,RegistryMatcher matcher) { 
    return new Persister(strategy, matcher, format); 
} 

@Provides @Singleton @NoFormat 
Serializer provideNoFormatSerializer(Strategy strategy, @NoFormat Format format,RegistryMatcher matcher) { 
    return new Persister(strategy, matcher, format); 
} 

@Provides @Singleton 
Retrofit provideRestAdapter(@WithFormat Serializer serializer) {} 

@Provides @Singleton 
XmlApiSerializer provideXmlApiSerializer(@NoFormat Serializer serializer) {} 

Это правильный подход? Я чувствую, что это слишком много. Я пробовал разные подходы, но я никогда не мог сообщить кинжалу, какую реализацию он должен использовать для каждого случая. Это был мой единственный случай «успеха».

Что вы думаете об этом? Можно ли улучшить его? Как?

Редактировать: Я понял, что использовал 2 отборочных, которые не были нужны. Теперь у меня есть только спецификатор forformat и noformat.

+0

либо '@ Qualifier's работы, или' @Named («ФОРМАТ») и '@Named («NO_FORMAT»)' – EpicPandaForce

+0

Да я в конечном итоге делает это с @Named который является в основном то, что я делаю, но это обеспечивается кинжалом – Peddro

+0

Это версия кинжала «проблемы с ногами»: https://github.com/google/guice/wiki/FrequentlyAskedQuestions#how-do-i-build-two-similar-but-slightly- различные деревья-оф-объектов – gk5885

ответ

1

может создавать небольшие графики связанных объектов путем делегирования отдельным компонентам. Вот как это может выглядеть только с Format и Serializer.

@Component(modules = {FormatModule.class, SerializerModule.class}) 
interface SerializerHelperComponent { 
    Serializer serializer(); 
} 

@Module 
final class FormatModule { 
    private final Format format; 

    FormatModule (Format format) { 
    this.format = format; 
    } 

    @Provides Format format() { 
    return format; 
    } 
} 

@Module 
final class SerializerModule { 
    /** This @Provides method doesn't need the qualifier! */ 
    @Provides static provideSerializer(
     Strategy strategy, 
     Format format, 
     RegistryMatcher matcher) { 
    return new Persister(strategy, matcher, format); 
    } 
} 

Теперь в оригинальном @Provides метод, вы можете просто создать новый вспомогательный компонент телеграфировать все с форматом, который вы выбрали.

@Provides @Singleton @WithFormat 
Serializer provideFormattedSerializer(
    Strategy strategy, 
    Format format, 
    RegistryMatcher matcher) { 
return DaggerSerializerHelperComponent.builder() 
    .formatModule(new FormatModule(return new Format()) 
    .build() 
    .serializer(); 
} 

С только один переплет, это, безусловно, не стоит свеч, но если есть сложный график, который будет создан в хелперов компонент для того, чтобы получить выход, это может быть стоит. Это, безусловно, призыв к суждению.

Смежные вопросы