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

前端之家收集整理的这篇文章主要介绍了依赖注射 – 松散耦合和依赖注入的香蕉前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
随着我们的依赖注入框架(春季注释)的最新补充,创建DI管理组件的边际成本似乎已经达到了一些关键的新阈值。虽然以前有一个与Spring(吨的XML和额外的限制)有关的开销,依赖注入似乎已经开始走向许多模式去;他们脱口而出,“消失”。

这样做的后果是与large number组件相关联的概念开销变得可以接受。有争议的是,我们可以建立一个大多数类只暴露的系统
一种单一的公共方法,通过将这些片段总结为疯狂来构建整个系统。在我们这个例子中,给了几件事情。您的应用程序的用户界面具有形成最高服务的一些功能需求。后端系统控制下部。但在这两者之间,一切都是为了抓住。

我们不断的讨论真的是为什么我们在课堂上分组,原则应该是什么?有几件事情是肯定的;门面图案已经死亡和埋葬。任何包含多个不相关功能的服务也倾向于分解。 “不相关的功能”的解释比我以前做的非常严格。

在我们的团队中,有两条盛行的思路:实施依赖关系限制分组;单个类中的任何功能最好是所有注入依赖关系的客户端。我们是一个DDD项目,另一个部分认为域限制分组(CustomerService或更细粒度的CustomerProductService,CustomerOrderService) – 注入依赖关系的标准化使用是不重要的。

所以在松散耦合的DI宇宙中,为什么我们将逻辑分组在类中?

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

所以例如任何需要OrderSystemAccessControlState的服务都可以注入这个,而且这个数据的范围不是消费者所不知道的。一些安全关联状态通常用于很多不同的级别,但是在其间的级别上完全不可见。我真的认为这是从根本上违背功能原则的。我甚至很难从OO角度对这个概念进行调整,但是只要注入状态是精确而强烈的类型,那么用例就是合法的。

良好的OO Design的首要原则并不是停止在松耦合,而是高度凝聚力,在大多数讨论中被忽略。

高凝聚力

In computer programming,cohesion is a
measure of how strongly-related or
focused the responsibilities of a
single module are. As applied to
object-oriented programming,if the
methods that serve the given class
tend to be similar in many aspects,
then the class is said to have high
cohesion. In a highly-cohesive system,
code readability and the likelihood of
reuse is increased,while complexity
is kept manageable.

Cohesion is decreased if:

06000

Disadvantages of low cohesion (or “weak cohesion”) are:

06001

当人们对IoC容器疯狂时,失去了一件事情就是失去了内聚力,而且跟踪什么以及如何做某些事情成为一个噩梦,以便在后面找到自己的道路,因为所有的关系都被一堆XML配置所掩盖文件(Spring我正在看你)和不良命名的实现类。

原文链接:https://www.f2er.com/javaschema/282097.html

猜你在找的设计模式相关文章