设计模式学习笔记<一>

模式的定义：

模式是一种问题的解决思路，它已经适用于一个实践环境，并且可以适用于其他环境。

设计模式得种类很多，包括分布式编程模式，用户界面模式，数据模型模式三大类。目前流行得GOF模式（gang of four：Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides），GRASP(General Responsibility Assignment Software Patterns)通用责任分配软件系列模式。

GRAPS模式着重考虑设计类的原则以及如何分配类的功能，而GOF模式则着重考虑设计的实现，类的交互和软件质量。可以说GOF模式就是符合GRASP模式要求的面向对象设计模式。

模式应该有以下特点：

（1） 在特定的场景下有可重用性，对相同类型的不同问题的环境，其解决方案都有效。
（2） 可传授性，即，问题出现的机会很多，解决问题的方案相同，人们相对可以接受。
（3） 有表示模式的名称。


GRASP模式的分类：

（1）Information Expert
（2）Creator
（3）Low coupling (低耦合)
（4）High Cohesion（高内聚）
（5）Polymorphism （多态）
（6）Pure Fabrication （纯虚构）
（7）Indirection （间接）
（8）Protected Variations （受保护的变化）


GRASP模式能让我们做好对象责任分配，要做好责任分配就要明确对象责任的含义。责任是类间的一种合约或是义务。责任可以包括行为（方法），数据，对象创建等。他们可以细分为两部分：知道责任－－－表示知道什么；行为责任－－－表示做什么。

责任＝知道责任 ＋ 行为责任

知道责任包括：

了解私有的封装数据
了解相关联的对象
了解能够派生或者计算的事物

行为责任包括：

自己执行一些行为，如创建一个对象或进行一次计算
在其他对象中的初始化操作
在其他对象中控制或协调各项活动

面向对象设计过程是将责任分配给对象的过程，注意，责任不是类的方法，类的方法是用来实现责任的。责任的分配可以反应在协作图或者顺序图中。

例如在销售业务中，存在一个交费行为，它属于一个责任。它的行为责任表示了交费的行为，它需要创建一个付款记录的对象。它的知道责任必须知道付款记录类Payment，知道如何记录及计算Payment类中的数据。而具有这个责任的对象应该是销售类Sales。

Information Expert

信息专家模式是面向对象设计的最基本原则。就是说，我们在设计类时，如果某个类能在某方面具有完整信息，足以实现某个责任，就将这个责任分配给这个类，这个类就是所谓的信息专家。

Creator

应用情况符合以下条件之一，类A应该具有创建类B的责任：

A是B的聚合
A是B的容器
A有初始化B的数据
A记录B的实例

当一个类有责任去创建其他类的实例时，这两个类就耦合起来。类间耦合用于测量一个类对另一个类依赖成都的大小。在程序设计中，以creator模式为原则，凡是不符合以上条件的应用，不要设计类的耦合。

Low Coupling

低耦合时指我们的设计有责任减少类间的链接。低耦合的作用很重要：
低耦合使得一个类的修改对其他类的影响范围有所降低。
低耦合使得系统变得更加容易维护。
低耦合使得类更加容易理解，因为类会变得简单，专业，高内聚。

以下情况会使得两个类产生耦合：

A具有B的属性。
A调用B的方法。
A的方法包含对B的引用，例如返回的是B类型或者参数是B类型。
A是B的子类或者A是B的实现类。

不要相连不需要通信的两个对象，不要无谓的耦合。

拇指规则两条：
如果A已经与B有链接，如分配责任A给B不合适（违反信息专家模式），那么分配责任B给A。
两个模块中的内部类间链接是一个大错误。


High Cohesion

高内聚是指分配责任时使得内聚保持为最高。目的时提高类的重用性，并且控制类设计的复杂度。也就是说，我们要努力分解类，使得分解出来的类具有独立的责任。

Controller

人们通常将接受和处理系统事件的职责分配给以下类：

能全面代表系统／设备或者子系统的类
可以代表系统事件发生时用例发生情景的类
代表某些卷入真实世界应用中的活动的类


以上这些类就是控制器类。GRASP有以下这些共识：
系统事件的接受和处理通常由一个高级类来代替。
一个子系统会有很多控制器类来分别处理不同的事务

多态

当相关的行为只是由于种类不同时，可以分配相关的责任给制定的种类。多态允许你设计出组件插入式的系统。

纯虚构

实现高内聚和低耦合是系统设计的目标，也是软件设计人员的责任。但是高内聚和低耦合是相互矛盾的，因为高内聚意味着类的数量增多，对象间要合作完成任务，他们之间的链接就要增加，使得耦合提高。要解决这个问题，就需要纯虚构模式，而应用这个模式又增加了高内聚的特征。GOF的抽象工厂模式就是纯虚构模式的一种实际体现。

间接
避免对象间的直接耦合，可以将协调组件或服务的职责分配给中间对象，这个中介对象称为间接或者中介对象。 GOF的Facade模式也是间接的例子。


受保护变化

找出预计又变化或不稳定的电，我们又责任为这些变化的点创建稳定的接口。受保护变化也可以理解为开闭原则（The OPen Closed Principle OCP）也就是说，一个软件实体应当对扩展开放，对修改关闭。换句话说，就是我们在设计一个模块的时候，应当使得这个模块在不被修改的前提下可以被扩展。

GOF的适配器Adapter模式就是受保护变化的一个普遍例子。