熟悉GRASP，撰写心得

熟悉GRASP，并撰写心得回答设计模式是怎样解决设计问题的，在实际编程中是如何使用的？

GRASP（职责分配原则）的九个原则

1、Infomation Expert（信息专家）

信息专家模式是面向设计的最基本原则，是我们平时使用最多，应该跟我们的思想融为一体的原则。也就是说，我们设计对象（类）的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。
示例：我们在设计购物网站的时候，为避免重复，一种商品只能在购物车中出现一次，如果多次出现，则需要将其数量增加。这个时候我们在将物品放入购物车的时候，要首先判断当前物品是否在购物车中，判断两个物品是否为同一个物品的方法这个职责应该委托给谁呢？显而易见，商品类中有唯一标识，所以这个职责由商品类实现，而不是购物车。

2、创造者原则(creator)

creator原则的本质是创建类对象职责应该委托给那个对象，也就是谁应该负责产生某个类的实例。

解决方案:　如果符合下面的一个或者多个条件，则可以将创建A的实例的职责分配给B;

a、A 是 B 的聚合
b、A 是 B 的容器
c、A 持有初始化 B 的信息（数据）
d、A 记录 B 的实例
e、A 频繁使用 B

满足上述一种或者多种情况的时候，我们应该奖创建A的实例的职责分配给B。

合理的creator原则带来的优点：如果职责分配合理，设计就能降低耦合，提高设计的清晰度，封装性和重用性。

示例:例如订单和商品的关系是聚合关系，这个时候我们将在订单中创建商品。

3、低耦合(Low coupling)

耦合是评价一个系统中各个元素之间连接或者依赖关系强弱的尺度。低耦合的原则是我们在设计系统的时候尽量降低系统中各个元素之间的耦合度，这样对于系统的理解和维护都有很大的益处。

耦合性高的系统会带来的坏处:

一个类的修改导致其他类产生较大的影响； 系统难以维护和理解； 系统的重用性差，在重用一个高耦合类的时候，不得不重用它所依赖的所有类。

低耦合模式的意思就是要我们尽可能地减少类之间的连接。

其作用非常重要：

a、低耦合降低了因一个类的变化而影响其他类的范围。

b、低耦合使用类更容易理解，因为类会变得简单，更内聚。

下面这些情况会造成类 A、B 之间的耦合：

a、A 是 B 的属性
b、A 调用 B 的实例的方法
c、A 的方法中引用的 B，例如 B 是 A 方法的返回值或参数。
d、A 是 B 的子类，或者 A 实现 B

关于低耦合，还有下面一些基本原则：

a、Don’t Talk to Strangers 原则

意思就是说，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题，不连接就一了百了了。

b、如果 A 已经和 B 有连接，如果分配 A 的职责给 B 不合适的话（违反信息专家模式），那么就把 B 的职责分配给 A。

例如：Creator 模式的例子里，实际业务中需要另一个出货人来清点订单（Order）上的商品（SKU），并计算出商品的总价，但是由于订单和商品之间的耦合已经存在了，那么把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。

4、纯虚构(pure Fabrication)

纯虚构原则与我们所说的纯虚函数类似。

　　纯虚构的作用是用来解决高内聚和低耦合之间的矛盾的。高内聚低耦合是我们系统设计的终极目标，高内聚意味着我们要将类拆分成多个功能集中的类，但是拆分的多个类之间需要进行协作才能正常工作，这样又增加了类之间的耦合性。

　　纯虚构原则是用来解决上述问题的方案。它要求将一部分类的职责转移到纯虚构类中，在理想的情况下，分配给这种虚构类的职责是为了达到高内聚低耦合的效果。在实际的操作过程中，纯虚构类的实现又很多种方式，例如将数据库中操作的方法从数据库实体中分离出来，形成专门的数据访问类；通过对类的分解来实现类的重用，新增加的数据访问类对应于数据的持久化存储，这是软件开发过程中为了方便虚构出来的一个概念。一般情况下，纯虚构模式通常基于功能进行划分的。

• A具有一个类型为B的属性；
• A调用B的方法
• A的方法包含对B的引用(参数或者返回值的方式)
• A是B的直接或者间接的子类
• A是接口B的一种实现
• 在类的划分上，尽量创建松耦合的类，类之间的耦合性越低，越有利于复用，修改一个类不会影响其他类。
• 在类的设计上，尽量降低类中成员和方法的访问权限。
• 在类的设计上，尽量将类设计为不变类
• 在类的引用上，将一个对象对另一个对象的引用降低到最小
• 例如：Creator 模式的例子里，实际业务中需要另一个出货人来清点订单（Order）上的商品（SKU），并计算出商品的总价，但是由于订单和商品之间的耦合已经存在了，那么把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。

5、控制器原则(controller)

控制器模式的实质是将一些系统事件的接受和处理委托给一个的对象controller，这个对象可以是一个类，系统或者子系统，它不与UI进行交互，它只负责系统信息的接收和处理。

一般情况下，控制器是一个系统，这个系统中包括多个处理器，分别对应处理不同的事务。通常情况下，一个控制器应当把要完成的功能委托给其他对象，而它只负责任务的协调控制和分配。

控制器原则与MVC模式相对应，MVC模式是一种比设计模式更高的架构模式。

6、中介模式(indirect)

中介模式的目的是为了避免两个对象之间产生直接耦合，降低对象之间的耦合度。

解决方案是建立中间对象来协调两个对象之间的交互，避免耦合性过高。

 

7、高内聚(high cohesion)

内聚是评价一个对象的职责被关联的尺度或者强弱，也可以说是功能性内聚的职责。也就是功能性紧密的相关职责应该放在同一个类中，并共同完成有限的功能。这样做更加有利于对类的理解和重用，也可以降低类的维护成本。

往往低内聚的系统设计会导致类的混乱，当对功能进行扩展或者改进的时候带来不必要的麻烦，低内聚的类也不利于重用，因为他们的职责如此之混乱。

为了达到高内聚，我们需要对类的职责进行分解，使分解出来的类具有独立的职责，满足单一职责原则。将一些需要在多个类中使用到的方法封装到一个类中，其他的类只负责他们需要负责的相关功能，这样我们可以提高类的内聚程度。

例如：一个订单数据存取类（OrderDAO），订单即可以保存为 Excel 模式，也可以保存到数据库中；那么，不同的职责最好由不同的类来实现，这样才是高内聚的设计。

8、受保护模式(protected variations)

受保护模式的实质与OCP(开放闭合原则)类似，我们首先找到系统中不稳定的变化点，使用统一的接口封装起来，如果未来发生变化的时候，可以通过扩展接口来扩展新的功能，而不需要改变旧的代码。这样达到易于扩展的目的。

9、多态原则(polymorphism)

多态原则与面向对象设计原则中的多态概念类似

例如：我们想设计一个绘画程序，要支持可以画不同类型的图形，我们定义一个抽象类 Shape，矩形（Rectangle）、圆形（Round）分别继承这个抽象类，并重写（override）Shape 类里的Draw() 方法，这样我们就可以使用同样的接口（Shape抽象类）绘制出不同的图形。