Question

我正在尝试通过将大型类（2000多行）重构为更小，更有凝聚力的类（~200行）来将单一责任原则集成到我的Java代码中。但是我很困惑如何正确地减少类之间的耦合，因为某些类似乎必须通过new关键字创建多个“硬依赖”。

我主要通过构造函数使用依赖注入，然后是setter方法，或者接受依赖作为参数的方法，并使用它在方法体内的其他逻辑（不仅仅是一个简单的this.val = val; setter。 / p>

IntelliJ的自动重构实例化这个新提取的类，并使用this对LoadController的引用传递（注入）它。如果我必须重构一个2000行类，当然每次我提取一个新类时都会发生这种自动实例化+注入。以下LoadController是程序主阶段的JavaFX控制器类，它作为各种功能的起点：

public class LoadController{
        private final DBConnection dbConnection = new DBConnection(this); 
        private final UpdateLabels updateLabels = new UpdateLabels(this);
        private final OpenCloseMenu openCloseMenu= new OpenCloseMenu (this);
        private final CreateVBox createVBox= new CreateVBox (this, dbConnection);
        private final ...
        private final ...
}

这是错的吗？我的理解是，大型独立的函数应该在它们自己的类中......但是一些类必须具有多个上面的硬依赖，以便“引导”使用各种其他类之间的逻辑流。

Answer 1

如果您正在对JavaFX控制器进行依赖注入，您可能希望使用Gluon Ignite之类的东西来帮助您。

Gluon Ignite允许开发人员在他们的JavaFX应用程序中使用流行的依赖注入框架，包括在他们的FXML控制器中。 Gluon Ignite在几个流行的依赖注入框架上创建了一个通用的抽象

您选择使用的注射框架（例如Guice或Spring）将负责创建可注射组件（例如，您不会调用new）并将相关引用注入您的代码中（例如，你不需要写dbConnection = <some value>）。注入框架将包含大量文档和博客文章，介绍它如何工作以及如何最好地使用它，因此对此的全面讨论超出了本答案的范围。

Gluon Ignite的替代品是afterburner.fx，它类似但是对@Inject使用了一个小的自定义实现，因此更轻量级（并且功能稍弱），然后更成熟的依赖注入框架（虽然使用起来很简单。）

这只是一个选项，还有其他一些方法可以解决这个问题，但是当你说你希望用JavaFX执行依赖注入时，看起来有意义的是已经过验证的框架来实现这一点，而不是试图推动你的自己的实施。

某些类必须具有多个如上所述的硬依赖项，以便＆＃34;指导＆＃34;使用各种其他类之间的逻辑流程。

使用像Guice这样的东西，你提供了一个定义接口类型和实现之间绑定的模块。这些绑定告诉Guice如何构造依赖项，因此您不需要对类中的依赖项进行硬编码。有关模块示例，请参阅Guice getting started guide中的BillingModule。如果需要多个可注入对象实例，可以在Guice中使用Providers。 Spring有类似的概念，但名称不同。

决定是否使用依赖注入框架是在没有注入框架时需要做的工作与将框架集成到应用程序中的额外时间和复杂性之间的权衡。因此，决定是否使用一个需要是您做出的架构决策，对于每个应用程序是否合理使用这些框架都没有通用的正确或错误的答案。

我认为使用注入框架对我的要求来说是多余的，那么我在某些类中拥有多个硬依赖关系并没有做任何本质上不正确的事情，如上所示？

需要在某处定义依赖项。无论是在推断的还是集中的位置，例如依赖注入系统，都可以使用或者在给定类的本地，如您可能从传统的responsibility driven design approach中确定的那样。因此，通过拥有硬依赖关系，您不一定会做错任何事情。不总是需要抽象的解耦模式，例如依赖注入。

诀窍是确定哪些依赖项具有管理它们的位置和方式。通常它很明显并且自然地从问题域中消失，有时诸如CRC modeling之类的技术可以帮助构建依赖关系。

Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler。

我的假设是我可以将我的大类重构成更小的，有凝聚力的类，其中一些类具有多个硬依赖，使用new。

是的，你当然可以这样做。

注射框架可以在项目的生命中稍后集成，而不是在可能不需要的早期集成吗？

是的，它可以。这样做会有一些工作，但如果应用程序结构合理，那就不那么困难了。更方便的是尝试从已经基于它的应用程序和库中删除依赖注入框架的使用。

正确的类构造：使用多个硬依赖关系

1 个答案: