松耦合和依赖注入变得疯狂

随着我们的依赖注入框架的最新添加（春季的注释），创建 DI 管理的组件的边际成本似乎已经达到了一些关键的新阈值。虽然以前存在与 spring 相关的开销（大量的 XML 和额外的间接），但依赖注入似乎已经开始出现在许多模式所在的地方；他们躲在引擎盖下然后“消失”。

这样做的结果是与大数字 http://www4.java.no/web/show.do?page=205的组件变得可以接受。有争议的是，我们可以创建一个大多数类仅公开的系统 一个单一的公共方法，并通过疯狂地聚合这些片段来构建整个系统。在我们的例子中，给出了一些东西；应用程序的用户界面有一些塑造最顶层服务的功能要求。后端系统控制下层部分。但在这两者之间，一切都是有待争夺的。

我们不断的讨论确实是为什么我们要把东西分组到类中 and 原则应该是什么？有几件事是确定的：立面图案已死并被埋葬。任何包含多个不相关功能的服务也往往会被拆分。 “不相关的特征”的解释比我之前所做的要严格得多。

在我们的团队中，有两种流行的思路： 实现依赖性限制分组；单个类中的任何功能最好应该是all注入的依赖项。我们是一个 DDD 项目，另一部分认为域限制分组（CustomerService 或更细粒度的 CustomerProductService、CustomerOrderService） - 注入依赖项的规范化使用并不重要。

那么，在松散耦合的 DI 世界中，为什么我们要将逻辑分组到类中？

编辑：duffymo 指出这可能正在朝着函数式编程风格发展；这就提出了国家问题。我们有相当多的“状态”对象，它们代表相关应用程序状态的（小）部分。我们将这些注入到任何对此状​​态有合法需求的服务中。 （我们使用“状态”对象而不是常规域对象的原因是 spring 在未指定的时间构建这些对象。我认为这是让 spring 管理域对象的实际创建的一个小解决方法或替代解决方案。可能有更好的解决方案这里）。

因此，例如任何需要 OrderSystemAccessControlState 的服务都可以注入它，并且消费者不容易知道该数据的范围。一些与安全相关的状态通常在许多不同的级别上使用，但在中间的级别上完全不可见。我真的认为这从根本上违反了功能原则。我什至很难从面向对象的角度来适应这个概念 - 但只要注入的状态是精确的和强类型的，那么need是合法的，即用例是正确的。

良好的 O 设计的首要原则不仅限于松散耦合，还包括高内聚力，在大多数讨论中都被忽略了。

高内聚力

在计算机编程中，内聚性是 衡量相关程度或 集中了a的职责 单模块是。如应用于 面向对象编程，如果 为给定类提供服务的方法 在很多方面都趋于相似， 然后据说班级有高 凝聚。在一个高度内聚的系统中， 代码的可读性和可能性 复用性增加，同时复杂性增加 保持可控。

如果出现以下情况，内聚力就会降低：

* The functionality embedded in a class, accessed through its methods,
  have little in common.
* Methods carry out many varied activities, often using coarsely-grained or 
  unrelated sets of data.

低内聚力（或“弱内聚力”）的缺点是：

* Increased difficulty in understanding modules.
* Increased difficulty in maintaining a system, because logical changes in 
  the domain affect multiple modules, and because changes in one module 
  require changes in related modules.
* Increased difficulty in reusing a module because most applications
  won’t need the random set of operations provided by a module.

当人们对 IoC 容器着迷时，会迷失的一件事是失去了内聚力，并且某件事的内容和方式的可追溯性成为以后自己弄清楚的噩梦，因为所有关系都被一堆 XML 配置所掩盖。文件（Spring 我正在看着你）和命名不当的实现类。