一些想法來到我的頭上。取決於你想如何以及何時交換這個。一種可能性是用配置實例化你的模塊。可以是一個簡單的布爾值:
@Module
public class RepositoryModule {
private final boolean isDemo;
public RepositoryModule(boolean isDemo) {
this.isDemo = isDemo;
}
@Provides
public Repository providesRepository() {
return isDemo? new DemoRepository() : new RemoteRepository();
}
// Other providers
}
我不是這種方法的粉絲,但它適合您的使用情況。我認爲這是相當嚴格的,不容易維護。我可能會選擇使用工廠,並提供工廠而不是回購本身。
public interface RepositoryFactory {
Repository getRepository(Configuration configuration);
}
public class RepositoryFactoryImpl implements RepositoryFactory {
@Inject
public RepositoryFactoryImpl() {}
// The implementation
}
@Module
public class RepositoryModule {
@Provides
public RepositoryFactory providesRepositoryFactory(
RepositoryFactoryImpl factory) {
return factory;
}
// Other providers
}
Configuration
將是一個簡單的POJO,你可以指定幾個屬性來配置你的回購協議。例如說:
public class Configuration {
private final boolean isDemo;
// all the POJO stuff you need
}
然後你可以讓你的域對象取決於工廠:
public class SomeAwesomeBusinessLogic {
private final RepositoryFactory repositoryFactory;
@Inject
public SomeAwesomeBusinessLogic(
RepositoryFactory repositoryFactory) {
this.repositoryFactory = repositoryFactory;
}
//awesome stuff going down
}
然後,您可以做repositoryFactory.getRepository(new Configuration(true/false));
在你的業務邏輯。
我更喜歡這種方法,因爲它更容易擴展到新類型的回購。您也可以測試工廠邏輯是否正確。沒有人通常測試匕首模塊,這就是爲什麼我不那麼熱衷於第一種方法。
另一件好事是,如果可以通過向工廠提供不同的Configuration
對象來改變應用程序的配置並突然更改爲演示回購,此方法允許您保留相同的模塊實例。
第三種可能性可能是Producers。但是,這實際上取決於您的用例以及您希望如何處理此運行時依賴關係交換。我覺得這種方法很好,但可能有點矯枉過正。
希望這會有所幫助