Robert C. Martin 在他的书“清洁架构：软件结构和设计的工匠指南”中提到，良好的架构允许延迟有关细节的决策。他提到的其中之一是：
没有必要在早期就采用依赖注入框架 发展，因为高层政策不应该关心如何 依赖关系已解决
实现这一目标的正确工作方法是什么？在没有特定依赖注入框架的情况下，如何以有效的方式开始开发？
【问题讨论】：
标签： dependency-injection clean-architecture dependency-inversion
如何在没有特定依赖注入框架的情况下以有效的方式开始开发？
简短的回答是：
就像你在那些 DI 框架出现之前所做的那样！
即使这些框架也有很多好处，最好在没有它们的情况下开始以独立于框架的方式编写代码。这解决了代码异味固定性。
假设您要设置一个控制器、一个用例和存储库。
+------------+ +----------+ +------------+
| Controller | ---> | Use Case | ---> | Repository |
+------------+ +----------+ +------------+
只需使用标准的构造函数和设置器。
Repository repo = new RepositoryImpl();
UseCase useCase = new UseCaseImpl(repo);
Controller controller = new ControllerImpl(useCase);
注意：我不喜欢 Impl 结尾。本例只是为了区分接口和实现。
我上面展示的这段代码与 DI 框架所做的一样。
如果您想使用 DI 框架，您可以将上面的代码包装在 DI 框架使用的方法中。在 java spring 中，我们将此类方法称为 工厂方法。例如
@Bean
public Controller controller(){
Repository repo = new RepositoryImpl();
UseCase useCase = new UseCaseImpl(repo);
return new ControllerImpl(useCase);
}
也许UseCase 应该是一个单例，因此应该放在一个单独的工厂方法中。
@Bean
public UseCase useCase(DataSource ds){
Repository repo = new RepositoryImpl(ds);
repo.setCacheEnabled(true);
return new UseCaseImpl(repo);
}
@Bean
public Controller controller(UseCase useCase){
ControllerImpl controller = new ControllerImpl(useCase);
SomeConfig c = ...;
controller.setSomeConfig(c);
return controller;
}
主要的一点是，我的示例中的控制器、用例和存储库只告诉他们需要什么，而不是从哪里来。将设置代码或引导代码彼此分开是个好主意。
【讨论】：