疫情期间表现优异的企业均将数字化创新放在前列

延伸：在某些情况下，该方案并不合适，通常是由于耦合与内聚问题产生的，如：谁应该把对象A存入数据库?按照原则每个类都应该具有把自己持久化的能力。

5 纯虚构

为了保持良好的耦合和内聚，捏造业务上不存在的对象来承担职责。

问题：当你并不想违背高内聚和低耦合或者其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责?

解决方案：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念--虚构的事物，用以支持高内聚、低耦合和复用。

优点：

• 支持高内聚，因为职责被解析为细粒度的类，这种类只着重于极为特定的一组相关任务。
• 增加了潜在的复用性。

相关原则和模式：

• GRASP：低耦合、高内聚。
• 通常接纳本来是基于专家模式所分配给领域类的职责。
• 所有GoF设计模式都是纯虚构，事实上所有其他设计模式也都是纯虚构。

举例：计算商品总数量。根据专家模式计算商品总数量的职责也应该是分配给Order，照这样分配下去商品相关的还会有：总重量、总体积、总XX，这时Order的职责就会越来越多也可能会产生额外的耦合，通过纯虚构对象把这些职责分配出去能够得到更好的设计。
 

• Order包含Goods(Order脱离Goods就失去了完整性，没有存在的意义)。
• Order记录相关的Goods。
• Goods初始化数据：
  • 情况一：只需要订单上的Goods数据，这种情况Order具有Goods的初始化数据。
  • 情况二：订单上的Goods数据不完整，这种情况Order只有Goods初始化数据的一小部分，Order不能做为创建者。

4 信息专家(or 专家)

“信息”不单指数据。

问题：给对象分配职责的基本原则是什么?

解决方案：把职责分配给信息专家，它具有实现这个职责所必需的信息

优点：

• 对象使用自身信息来完成任务，所以信息的封装性得以维持，因此支持了低耦合(至少不会增加耦合性)。
• 行为分布在那些具有所需信息的类之间，这样功能更集中，因此支持了高内聚。

相关模式或原则：

• GRASP：低耦合、高内聚

注意：和“关注点分离”一起使用使得对象进一步内聚，从而达到高内聚，也能降低耦合。

举例：获取所有买的商品总金额，Order和Goods是一对多的关系。

（编辑：四平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!