设计模式的基础: GRASP (下)

最新推荐文章于 2020-06-03 00:12:09 发布

Joiningss

最新推荐文章于 2020-06-03 00:12:09 发布

阅读量2.7k

点赞数

CC 4.0 BY-SA版权

分类专栏：设计模式文章标签：设计模式 domain 数据库 class 编程扩展

本文链接：https://blog.youkuaiyun.com/Joiningss/article/details/7247440

设计模式专栏收录该内容

8 篇文章

订阅专栏

本文介绍了GRASP设计原则中的Pure Fabrication模式，指出如何处理非问题领域的职责，避免破坏Domain Class的高内聚。接着讨论了Indirection模式，强调通过引入第三方类来降低类之间的耦合。最后探讨了Protected Variations模式，通过稳定的接口应对变化，提高系统的适应性和低耦合性。文章通过实例解析了这三种模式在实际编程中的应用和优势。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

7、Pure Fabrication (纯虚构)

我们在设计类的时候，通常都是尽量于现实世界中的对象保持一致，那么我们从现实世界的对象抽象出来的类就叫做问题领域的类，这些类就承承担了问题领域内的职责。但是，当这些类需要进行一些非现实存在的操作时（比如说操作数据库），这些操作演变成了非问题领域的职责。这些非领域问题的职责还要非配给问题领域内的类吗？按照信息专家等模式的原则，这样的分配是不合理的，这样会违反高内聚低耦合的基本原则。那么要怎么还分配这些非问题领域的职责呢？

Pure Fabrication模式提倡把这些非问题领域的职责分配给那些人工生成的或者容易实现此类型职责的概念类。

    Domain Class的概念：我们设计对象的时候应该尽量保持与现实世界里的对象一致。这种与现实世界里的对象保持一致的从业务分析中抽象出来的类叫做“Domain Class”。它相当于上述问题领域里的类。
    比如一个简单的用例：用户注册
           用户就是一个“Domain Class”，它是现实世界里的业务对象。相当于这里的“问题领域里的类”。
       用户注册需要操作数据库，[数据库操作]是系统功能实现的一个必需功能，它不是现实世界里存在的业务对象，它是一个非

Domain Class。如果把[数据库操作]看作一个行为职责，它就相当于这里所说的“非问题领域里的职责”。一般来说，Domain

Class与非Domain Class的功能如果聚集在一个类里，就破坏了“高内聚”原则。

应用Pure Fabrication模式的好处：

- 高内聚。不必分配问题领域以外的职责给各Domain类，从而保证各Domain类内部功能上的高度聚集性。
- 低耦合。问题领域以外的职责被分配给第三方非Domain类，一方面可以降低各Domain类之间的关联程度，另一方面可以比较漂亮地

整合系统的各方面的职责。
- 重用性。各Domain类由于功能上的聚集与关联度的降低，可以更容易地得到重用。

GoF的抽象工厂模式就是ＧＲＡＳＰ纯虚构模式的一种实际体现．

8、Indirection (间接)

Indirection模式是GRASP模式中解决类的关联问题的模式。记得之前说过，不同模块之间的内部类一定不能直连，但是模块间一定是由联系的，那么该把“关联”责任分配给哪些类呢？

Indirection模式所提倡的解决方案：

当多个类之间存在复杂的消息交互（关联）时，Indirection模式提倡类之间不直接进行消息交互处理（非直接），而是导入第三方类，把责任（多个类之间的关联责任）分配给第三方类，降低类之间的耦合程度。

应用Indirection模式的好处：

   - 高内聚。通过把“关联”的功能分散到第三方类，原来的类可以更加关注自身功能的实现。
   - 低耦合。原本关联类之间不直接关联，降低类之间的耦合性。
   - 高重用性。第三方类对“关联”功能的集中处理，与原来的类对自身功能的专注，有利于类的重用。、

应用Indirection模式的一个最好范例是GoF的Mediator（中介者）模式。

9、Protected Variations (变化预防模式)

Protected Variations模式是GRASP扩展模式之一，它设计稳定的接口来应对将来可能发生的变化或其它不安定的因素。对存在于系统，子系统，或对象等元素中的各种变化或不安定的因素，为了不产生对其他元素的不利影响，在它们中间应该怎么样分配职责？

Protected Variations模式所提倡的解决方案：

Protected Variations模式提倡在可预测的变化或不安定因素的周围，用稳定的接口来承担职责。

在面向对象设计中，面向接口编程便符合Protected Variations模式的概念。

有人把Protected Variations模式称为Don't Talk to Strangers（别跟陌生人说话）。因为它跟实现Protected Variations模式的考

虑方法一致。Don't Talk to Strangers别名Demeter法则:（LoD: the Law of Demeter），它的基本原则是：只跟直接依赖的对象通

信（不要耦合没有明显通信需求的2个对象），也就是说2个对象之间，能不关联的就尽量不要关联。

   所谓直接依赖的对象，例如有一个对象A，跟它直接依赖的对象有：
   1，A对象本身
   2，A的属性成员对象
   3，通过参数传送给A的对象（A的方法里参数）
   4，A的方法内部生成的对象

   为什么说LoD跟实现Protected Variations模式的考虑方法一致呢？
   我们举例来说明。
    假如，系统需要实现这样一个功能，把一段字符串保存到文件，打印机等输出设备。
    这是一个可变的或者说存在不安定因素的功能需求，因为输出设备除了文件，打印机之外，还可能有数据库，屏幕终端，网络输出等。
    应用Protected Variations模式，我们为其定义一个能实现输出功能的稳定接口IOutputer，而具体的功能在具体的子类中实现，比如打

印机输出类PrinterOutputer，数据库输出类DatabaseOutputer，文件输出类FileOutputer等。使用此“输出功能”的用户只要知道接口

就行了。也就是说，对于用户来说，用户的直接依赖对象只有父接口IOutputer，至于其子类诸如

PrinterOutputer，DatabaseOutputer，FileOutputer等都属于陌生人。

应用Protected Variations模式的好处：

- 提高系统对变化的应对能力。一旦系统的可预见的不安定因素发生变化（比如追加功能等），只需要生成一个已有的稳定接口的实现

      类就可以了，无需修改原来的类。
    - 高内聚。具体的功能在各子类中实现，各类的内部功能具有高度聚集性。
    - 低耦合。用户类只跟稳定接口通信，减少了跟其它陌生对象的关联的机会，降低了类之间的耦合性。

参考文章：http://www.foreworld.net/article.asp?id=16

http://www.cnblogs.com/justinw/archive/2006/11/28/574573.html