建设者还是二传手？

不用说，每个对象都需要先创建才能使用。无论我们是在谈论域，框架，库还是任何其他类型的类，都没有关系。当您的代码是面向对象的时，这些类仅是对象的定义。在创建对象之前，不能使用它们。

在谈论对象的初始化时，我们经常需要考虑依赖关系。您将如何注入它们？您会使用构造函数还是二传手？

让我来帮助您做出正确的决定。

很久以前..

……需要处理一些事件。为此，我们必须首先从存储库中检索必要的数据，然后将其传递给触发器，该触发器负责根据给定的数据触发适当的操作。

在实现过程中，我们创建了以下类：

public class SomeHandler {public SomeHandler(Repository repository, Trigger trigger) {// some code}public void handle(SomeEvent event) {// some code}
}

事情总是在变化。我们的客户告诉我们，他们有时会需要存储从存储库中检索到的一些信息，然后才能采取适当的措施。他们需要此数据用于统计目的和进一步分析。

更改后，这是我们班级的样子：

public class SomeHandler {public SomeHandler(Repository repository, Trigger trigger) {// some code}public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker) {// some code}public void handle(SomeEvent event) {// some code}
}

又过了一个月，客户提出了另一个要求。他们希望有可能在触发事件后立即启用通知。对于某些紧急事件，这对于他们来说是必要的。他们希望具有更高的透明度。

好的，现在我们可以启用两件事：

public class SomeHandler {public SomeHandler(Repository repository, Trigger trigger) {// some code}public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker) {// some code}public SomeHandler(Repository repository, Trigger trigger, Notifier notifier) {// some code}public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker, Notifier notifier) {// some code}public void handle(SomeEvent event) {// some code}
}

代码看起来不错，不是吗？好的，这是一个反问。让我们做些事情。

构造器与否？

在上面的示例中，我们有四个构造函数的类。为什么那么多？由于客户需求的变化。这很好。一个应用程序应该满足客户的需求。

问题出在哪里？问题在于类的设计。

为什么我们有这么多构造函数？由于某些依赖项是可选的，因此它们的存在取决于外部条件。

我们需要这么多构造函数吗？

在回答这个问题之前，最好先问一个不同的问题： 构造函数的目的是什么？

我们应该创建一个处于有效状态的对象。如果需要做更多的事情来使对象可用，我们就不应创建实例。这就是为什么所有必需的依赖项都应放在构造函数中的原因 。

另一方面， 我们应仅将所需的依赖项放在构造函数中 。构造函数不是放置任何可选内容的地方。如果某些东西是可选的，则意味着我们不需要它来创建有效的对象。

如果我们想使用其他很好的依赖项，则应该以其他方式注入它们。这就是二传手的角色。我们没有被迫调用setter方法。我们可能有需要，但这不是必需的。 当依赖项为选项时，应使用setter 。

那么，我们需要那么多构造函数吗？让代码作为答案：

public class SomeHandler {public SomeHandler(Repository repository, Trigger trigger) {// some code}public void setSnapshotTaker(SnapshotTaker snapshotTaker) {// some code}public void setNotifier(Notifier notifier) {// some code}public void handle(SomeEvent event) {// some code}
}

更少的代码，更具描述性。从第一刻起，您就知道需要什么以及可以使用什么。

塞特犬？

我不喜欢二传手。为什么？因为这些方法以某种方式破坏了封装。

但是，我们可以用什么代替二传手？在给定的示例中可以代替使用什么？

好吧，我们不会避免使用这些方法。或更确切地说，我们需要它们的功能。需要让客户启用该功能。在给定的示例中，因为需要变量，所以需要保留它们。但是，我们总是可以使代码更好。与域更多相关。怎么样？我们只需要显示与域的这种关系：

public class SomeHandler {public SomeHandler(Repository repository, Trigger trigger) {// some code}public void enable(SnapshotTaker snapshotTaker) {// some code}public void enable(Notifier notifier) {// some code}public void handle(SomeEvent event) {// some code}
}

我写道，我不喜欢setter，因为它们的中断封装，但这不仅与方法的功能本身有关。使用诸如setX之类的方法的另一个问题是，即使它们的名称也是面向实现的。有时，setter功能是必需的。但是，请记住以一种显示域含义的方式来命名方法。