GRASP 通用职责软件分配模式

  GRASP（General Responsibility Assignment Software Pattern）是通用职责软件分配模式。GRASP关注于职责的分配，不会像GOF模式一样提供具体的类结构，更像一种原则,一种想法。

低耦合（Low Coupling）

所谓耦合，即两个对象之间联系的紧密程度

问题：如何减少因变化产生的影响？

解决方案：分配职责以使耦合保持在较低的水平。

低耦合是构建软件最重要的目标之一。

要注意：我们讲低耦合，是降低与不稳定系统之间的耦合度，而不是那些稳定的系统，比如说我们在JAVA编程过程中，没有必要想专门的办法来降低与JDK核心类库之间的耦合度，因为JDK核心类库非常稳定，很少会发生变化。

 

 

高内聚（High Cohesion）

所谓内聚，即对象职责的相关性（或对象的操作之间联系的紧密程度）。高内聚，即保持对象职责的高度相关性。不良内聚和不良耦合往往都是齐头并进的！

 

问题：怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？

解决方案：分配职责以保持较高的内聚性。

内聚性较低的类，要做许多不相关的工作，或需要完成大量的工作。这样的类是不合理的。这样的类会有下列问题：

l  难以理解

l  难以复用

l  难以维护

l  脆弱，经常会受到变化的影响

 

高内聚、低耦合是我们进行系统设计时，应该尽量要达到的目标。但是在某些情况下，这些原则也许不太合适。比如在分布式系统的开发中。分布式系统开发中的分布式对象之间的互相调用，可能会跨越网络，跨网络调用会导致系统性能的下降，为了提高性能，所以必须寻找某种手段来降低跨网络调用的次数。 

 

信息专家(Information Expert)

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

解决方案：把职责分配给具有完成该职责所需信息的那个类。（描述一种直觉！）

举例：

Classes

public class Classes { private int id; private Set students; //描述一种直觉 public void addStudent(Student student){ if(students == null){ students = new HashSet(); } students.add(student); } //将职责放在拥有这个职责所需信息的那个类中 public boolean hasStudent(Student student){ for (Iterator iterator = students.iterator(); iterator.hasNext();) { Student s = (Student) iterator.next(); if(s.equals(student)){ return true; } } return false; }

 

Student

public class Student { private int id; private String name; //判断两个学生对象是否相同的职责，交给Student来完成，因为它拥有这个 //职责所需要的所有信息 public boolean equals(Student student) { if(name.equals(student.getName())){ return true; } return false; }

 

TreeNode

public class TreeNode { private int id; private int level; private String nodeName; private TreeNode parent; private List<TreeNode> children; public void print(){ for(int i=0; i<level; i++){ System.out.print("--"); } System.out.println(nodeName); for (Iterator<TreeNode> iterator = children.iterator(); iterator.hasNext();) { TreeNode node = iterator.next(); node.print(); } }

 

 

创建者（Creator）

问题：谁创建了A？

解决方案：如果以下条件之一为真时（越多越好），将创建类A实例的职责分配给B：

l  B“包含”或组成聚合了A

l  B记录A

l  B紧密地使用A

l  B具有A的初始化数据

举例：

比如在富客户端应用开发中，主程序创建一个主窗口对象，然后有主窗口对象来负责创建它内部的各种菜单、按钮等对象（而不是由主程序来创建这些菜单或按钮对象之后，再把它设置到主窗口中去）

 

控制器（Controller）

问题：在UI层下首先接收和协调（“控制”）系统操作的对象是什么？

解决方案：把职责分配给能代表下列选择之一的对象：

l  代表整个“系统”、“根对象”（外观控制器）。 - 一般用Façade模式来实现

l  代表发生系统操作的用例场景（用例控制器）。 - 如果使用Façade来实现一个外观控制器，会使得这个控制器非常臃肿，那么可以考虑采用用例控制器。

举例：

比如说，“导入组织机构的数据”用例，要求能够在界面上上传两个Excel文件，一个Excel是部门信息，一个Excel是人员信息。那么在实现这个用例的时候，UI层在接收到数据之后，应该将业务逻辑统一交给一个业务逻辑处理对象来完成。很显然，这个业务逻辑对象，需要调度Excel处理相关的对象、人员信息处理相关的对象、部门信息处理相关的对象等来完成这个导入数据的业务。此业务逻辑对象就是用例控制器。

 

要注意：MVC中的C，并不是我们这里的控制器。因为MVC中的C处于UI层，而不是业务逻辑层。

多态（Polymorphism）

问题：如何处理基于类型的选择？如何创建可插拔的软件构件？

解决方案：当相关选择或行为随类型（类）有所不同时，使用多态操作为变化的行为类型分配职责。

 

不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。

纯虚构模式（Pure Fabrication） 

 

问题：当你并不想违背高内聚和低耦合或其它目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责？（很多情况下，只对领域对象分配职责会导致不良内聚或耦合，或者降低复用潜力）

解决方案：

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

 

所有GOF设计模式（或其它模式）都是纯虚构。

 

间接性（Indirection） 

问题：为了避免两个或多个事物之间的直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提供复用性潜力？

解决方案：将职责分配给中介对象，避免它们之间的直接耦合。中介实现了间接性。

 

例如：

类A和类B是多对多的关联关系，当A改变的时候，B需要做相应的改变，当B改变的时候，A需要做相应的改变，这是违反低耦 合原则的，解决方法就是在A和B之间加入一个C类，类C的属性只有A和B，用C来记录A和B之间的关系，当A想使用B或者B使用A的时候，他们都通过C来调用对方。

 

大量GOF模式，如适配器、外观等等都是间接性的体现。

 

防止变异（Protected Variation）

问题：如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其它元素产生不良影响？

解决方案：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口。

 

例如：坐汽车去广州当中的坐汽车就是一个不稳定的因素，以后也许会坐飞机或者火车，那么我们就要把坐汽车 抽象出一个坐车的接口，当有一天想坐火车的时候直接加一个实现的类就可以了。

 

几乎所有的软件或架构设计技巧，都是防止变异的特例，比如封装、多态、接口、虚拟机、配置文件等等等等！

 

 

 

根据以下链接和腾飞兄的资料整理

 http://hi.baidu.com/zhzhy917/blog/item/eb6e9b16f5b3431e972b43c3.html