GRASP通用职责分配软件模式

发表于 | 分类于

GRASP设计模式及OO设计原则

GRASP设计模式的全称是General Responsibility Assignment Software Patterns，即通用职责分配软件模式。它定义了9个基本的OO设计原则或基本的设计构件。这9个设计模式分别是：

  • 控制器(Controller)
  • 创建者(Creator)
  • 高内聚(High cohesion)
  • 间接性(Indirection)
  • 信息专家(Information expert)
  • 低耦合(Low coupling)
  • 多态(Polymorphism)
  • 预防变化(Protected variations)
  • 纯虚构(Pure fabrication)

1.The Controller pattern

  1. the controller collaborates with the bussiness objects to handle the actor request
  2. the controller delivers the result to the presentation,which displays the result to the actor
  3. 为了解决如下问题(a solution to these problems)
    A. Decouple the presentation and bussiness objects
    B. Remove the responsibility to handle an actor request from the presentation and assign it to another object
  4. 缺点(liabilities)
    A controller may be assigned too many responsibilities,resulting in a so-called bloated controller

2.Creator

  1. the creator is the object that is responsible for creating an object of a class
  2. a solution to these problems,supposed that an object of class A is the creator of an object of class B
    A. Class A is an aggregation(聚合) of class B
    B. An object of class A contains objects of class B
    C. An object of class A records object of class B
    D. An object of class A closely uses objects of class B
    E. An object of class A has the information to create objects of class B
  3. 缺点(liabilities)
    One same object may have different creation behaviors

3 6 High cohesion Low coupling

4 Indirection

间接性模式关注这样一个问题：为了避免两个或多个事务之间直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提高复用性潜力？

间接性模式对此的回答是：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介则实现了其他构件之间的间接性。

间接性模式的思想比较简单，即通过一个中介就能消除许多的耦合。在GoF的23种设计模式中，有许多模式都利用到了间接性的思想。比如桥接模式中，设计将抽象部分与其实现部分相分离，利用的就是在客户与实现之间增加了一个抽象层次。外观模式则是在整个子系统与客户之间增加了一个便于用户使用的外观类作为中介。而中介者模式中的中介者则更是典型的例子。

5 The expert pattern

  1. the expert is the object that is responsible for handling a request should have the information to fulfill the request
  2. a solution to these problems
    A. who should be assigned the responsibility to handle a request
    B. Remove the excessive responsibility from the controller and assigning them to other objects
  3. 缺点(liabilities)
    The expert may become a big object

7 多态(Polymorphism)

8 预防变化(Protected variations)

防止变异模式关注这样一个问题：如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响？

防止变异模式的回答是：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定的接口。

防止变异（PV）是非常重要和基本的软件设计原则，几乎所有的软件或架构设计技巧都是防止变异的特例。PV是一个根本原则，它促成了大部分编程和设计的模式和机制，用来提供灵活性和防止变化。在软件设计中，除了数据封装、接口、多态、间接性等机制是PV的核心机制之外，没有一种固定的或者是通用的办法能够防止一切变化的产生。因此PV的实现依赖的是一系列的OO设计方面的经验性原则，用以产生一个设计良好的高内聚、低耦合的系统，从而支持PV。

这里需要参考文章面向对象设计原则

9 纯虚构(Pure fabrication)

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

OO设计中的领域模型是对领域内的概念内或现实世界中的对象的模型化表示。创建领域模型的关键思想是减小软件人员的思维与软件模式之间的表示差异。因此，在OO设计时，系统内的大多数类都是来源于现实世界中的真实类。然而，在给这些类分配职责时，有可能会遇到一些很难满足低耦合高内聚的设计原则。纯虚构模式对这一问题给出的方案是：给人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念，而代表虚构出来的事物，用以支持高内聚、低耦合和复用。

纯虚构模式强调的是职责应该置于何处。一般来说，纯虚构模式会通过表示解析或者行为解析来确定出一些纯虚构类，用于放置某一类职责。理想状况下，分配给这种虚构物的职责是要支持高内聚低耦合的，从而使整个系统处于一种良好的设计之中。

例如，在信息专家模式的最后一段所举的例子中提到，许多后台系统都需要对数据库进行操作，将系统中的一些对象进行持久化。信息专家模式给出的建议是将持久化的职责分配给具体的每一个模型类。但是这种建议已经被证明是不符合高内聚低耦合原则的，因为不会被采纳。于是，设计者往往会在系统中加入类似于DAO或者PersistentStorage这样的类。这些类在领域模型中是并不存在的，它们完全由设计者根据系统的行为而虚构得到。然而，这些类的引入，使得操作数据库进行持久化这种高内聚的职责可以顺理成章地分配给它们。从而在整个系统中实现了比较好的内聚和耦合。

在使用纯虚构模式时，不能毫无限制地对系统中的各种行为进行解析并纯虚构。如此往往会导致系统中大量的行为对象的存在，这样会对耦合产生不良的影响。