去松散耦合和依赖注入的香蕉

随着我们的依赖注入框架(春季注释)的最新成员,创建DI管理组件的边际成本似乎已达到一个关键的新门槛.虽然之前有一个与spring相关的开销(大量的XML和额外的间接性),依赖注入似乎已经开始进入许多模式的地方; 他们陷入困境并"消失".

其结果是与大量组件相关的概念开销变得可接受.有争议的是,我们可以创建一个系统,其中大多数类只暴露一个单一的公共方法,并通过像疯狂一样聚合这些部分来构建整个系统.在我们的例子中,给出了一些东西; 应用程序的用户界面具有一些功能要求,可以塑造最顶层的服务.后端系统控制下半部分.但在这两者之间,一切都在争夺中.

我们不断的讨论真的,我们为什么要分组东西类以及应该怎样的原则？有几件事是肯定的; 门面图案已经死亡并被埋葬.任何包含多个不相关功能的服务也往往会被拆分."无关特征"的解释比我之前所做的更为严格.

在我们的团队中,有两种流行的思路:实现依赖性限制分组; 单个类中的任何功能最好应该是所有注入依赖项的客户端.我们是一个DDD项目,另一个部分认为域限制分组(CustomerService或更细粒度的CustomerProductService,CustomerOrderService) - 注入依赖项的规范化使用并不重要.

那么在松散耦合的DI宇宙中,为什么我们要在类中对逻辑进行分组？

编辑:duffymo指出,这可能正朝着功能性的编程方式发展; 这带来了国家问题.我们有很多"状态"对象代表(小)相关应用程序状态.我们将这些注入任何对此状​​态有合法需求的服务.(我们使用"状态"对象而不是常规域对象的原因是spring在未指定的时间构造它们.我将此视为一种轻微的解决方法或替代解决方案,让spring管理域对象的实际创建.可能有更好的解决方案这里).

因此,例如任何需要OrderSystemAccessControlState的服务都可以注入这个,并且消费者不容易知道这些数据的范围.一些安全相关状态通常用于许多不同的级别,但在中间的级别上完全不可见.我真的认为这从根本上违背了功能原则.我甚至很难从OO角度调整这个概念 - 但只要注入状态是精确且强类型,那么需要是合法的,即用例是正确的.

良好的OO设计的首要原则并不是停止松散耦合,而是高凝聚力,在大多数讨论中都会被忽略.

高凝聚力

在计算机编程中,凝聚力衡量单个模块的职责与强烈相关或集中的程度.当应用于面向对象的编程时,如果服务于给定类的方法在许多方面趋于相似,则该类被认为具有高内聚性.在高度凝聚的系统中,代码可读性和重用的可能性增加,而复杂性保持可管理性.

如果:

* 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我在看你)和命名不好的实现类.