autowired_@Autowired所有的东西！

autowired

最近，我写了@Autowired注释，它使我们可以编写更少的代码，从而使我们的生活更轻松。但是，使用它通常会使您的设计更加复杂。尤其是当我们谈论在类的属性上使用它时。它更容易违反
单一责任原则。这样可以更容易地注意到这一点。

可以将@Autowired与属性一起使用，但是，我认为，构造函数的存在会在问题出现时以过多的依赖关系可视化该问题。即使没有在我们这边加倍照顾。

不断增长的代码

让我们使用文章中有关构造方法和设置方法的已知示例，但我们将对其进行一些修改。

因此，曾经有一个事件必须处理。首先，我们必须从数据库中检索所有必需的信息，然后，我们就可以基于该信息触发适当的操作。

根据需求，我们创建了以下代码片段：

public class SomeHandler {@Autowired private final Repository repository;@Autowired private final Trigger trigger;public void handle(SomeEvent event) {// some code}
}

但是改变是唯一可以确定的。客户提出了新的要求，我们不得不扩展功能。客户希望存储所有信息，然后才能采取适当的措施。他们还希望在发生任何紧急事件时得到通知。

经过所有更改，我们最终得到了这样的结果：

public class SomeHandler {@Autowired private final Repository repository;@Autowired private final Trigger trigger;@Autowired private final SnapshotTaker snapshotTaker;@Autowired private final Notifier notifier;public void handle(SomeEvent event) {// some code}
}

从类的角度来看，这是编写良好的代码吗？好吧，我相信三到四个依赖关系一定会给我们提供开始考虑进行小型重新设计的理由。

不幸的是，四个依赖不是我在单个类的代码中见过的最多的依赖关系……

@Autowired在哪里？

好的，但是@Autowired必须做什么？解决该问题的方法是在需要时重构和重新设计代码，对吗？我相信有些人会同意我的观点。但是，在做出任何更改决定之前，我们必须找出问题所在。

好的，再说一次– @Autowired必须做什么？依赖项的数量是否有问题，这不是很明显吗？好吧，在字段上使用@Autowired使它有点模糊。当您查看上面的代码时，似乎并不会感到很痛苦。这些只是四行代码，短行代码。我们可能会争辩说，任何优秀的开发人员都应该知道什么时候太多了，但是为什么我们应该假设何时可以编写可以表达问题本身的代码呢？

如果所有这些依赖项都是必需的，我们可以使用构造函数来注入它们：

public class SomeHandler {private final Repository repository;private final Trigger trigger;private final SnapshotTaker snapshotTaker;private final Notifier notifier;@Autowiredpublic SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker, Notifier notifier) {this.repository = repository;this.trigger = trigger;this.snapshotTaker = snapshotTaker;this.notifier = notifier;}public void handle(SomeEvent event) {// some code}
}

现在，代码“告诉”我们一些东西。这个长的构造函数声明看起来并不好。我们不必考虑四个是否太多。我们看到了。

在示例中，我们同时使用了类和方法的简称，但在实际应用中，有时这些名称要更长一些，以便尽可能地描述：

@Autowired
public SomeHandler(EventRepository eventRepository, EventActionTrigger eventActionTrigger, EventSnapshotTaker eventSnapshotTaker, EmergencyIssueNotifier emergencyIssueNotifier) {this.repository = eventRepository;this.trigger = eventActionTrigger;this.snapshotTaker = eventSnapshotTaker;this.notifier = emergencyIssueNotifier;
}

现在问题更明显了，不是吗？

并且添加另一个依赖关系只会伤害我们的眼睛（如果尚未发生）：

@Autowired
public SomeHandler(EventRepository eventRepository, EventActionTrigger eventActionTrigger, EventSnapshotTaker eventSnapshotTaker, EmergencyIssueNotifier emergencyIssueNotifier, SomeAnotherDependency someAnotherDependency) {this.eventRepository = eventRepository;this.eventActionTrigger = eventActionTrigger;this.eventSnapshotTaker = eventSnapshotTaker;this.emergencyIssueNotifier = emergencyIssueNotifier;this.someAnotherDependency = someAnotherDependency;
}

我们需要更深入！

但是现在不要停下来。让我们看一下扩展类时的代码：

public interface Handler {void handle(Event event);
}public abstract class BasicEventHandler {@Autowired private final EventRepository eventRepository;@Autowired private final EventActionTrigger eventActionTrigger;// some code
}public class SomeHandler extends BasicEventHandler implements Handler {@Autowired private final EventSnapshotTaker eventSnapshotTaker;@Autowired private final EmergencyIssueNotifier emergencyIssueNotifier;@Autowired private final SomeAnotherDependency someAnotherDependency;public void handle(SomeEvent event) {// some code}
}

在第一个示例中，我们可以争论声明对象依赖项的代码行数是否足够大，这使我们感到担忧。当我们扩展一个类时，在一个特定的类中这个数字可能很好。

但是，此代码的问题甚至比前面的示例更大。

作者通常可以确定他们的解决方案是好的。这就是我们（作者）对待正在创造的东西的方式。

但是这一次，即使是代码审阅者也可能不会注意到问题。不幸的是，并不是每个人都会看到父类。在检查代码时，需要付出额外的努力。即使没有签出分支，我们仍然必须转到我们的IDE并打开类。也许不是很多，但请相信我，对于我们中的某些人来说，太多了。

如果我们同意构造函数是我们类的必需部分，那么就不会出现问题。

public class SomeHandler extends BasicEventHandler implements Handler {private final EventSnapshotTaker eventSnapshotTaker;private final EmergencyIssueNotifier emergencyIssueNotifier;private final SomeAnotherDependency someAnotherDependency;@Autowiredpublic SomeHandler(EventRepository eventRepository, EventActionTrigger eventActionTrigger, EventSnapshotTaker eventSnapshotTaker, EmergencyIssueNotifier emergencyIssueNotifier, SomeAnotherDependency someAnotherDependency) {super(eventRepository, eventActionTrigger);this.eventSnapshotTaker = eventSnapshotTaker;this.emergencyIssueNotifier = emergencyIssueNotifier;this.someAnotherDependency = someAnotherDependency;} public void handle(SomeEvent event) {// some code}
}