设计模式的基础：GRASP (上)
设计模式帮助我们高效地、灵活地使用类和对象，然而在使用这些类和对象时，我们首先需要创造出这些东西。如何合理地设计和得到这些类、对象？这时候我们就需要遵循GRASP(General Responsibility Assignment Software Rattern)原则。所谓的OOP，首先要把现实世界的业务功能抽象成对象，如何把现实世界的业务功能抽象成对象，如何决定一个系统有多少对象，每个对象都包括什么职责，GRASP所包括的9种模式从各个方面描述了对象设计和职责分配的指导原则。所以说GRASP是设计模式的基础。
以下便是GRASP9个模式的介绍及一些自己的理解：
1、Low Coupling (低耦合)
GRASP的核心思想自己能干的事情自己干，并且只干自己的事情。在面对对象的开发过程中，小到一个类，大到一个功能模块，如果他们之间的依赖性过高就会对整个项目的开发造成很对不必要的麻烦。
低耦合有着一下的作用：
a. 低耦合降低了因一个类的变化而影响其他类的范围。
b. 低耦合使类更容易理解，因为类会变得简单，更内聚。c. 低耦合有利于类或者模块的复用，因为类和模块的低耦合性，当我们复用的时候，就不会牵涉到太多其他的类和模块。
d. 低耦合让程序的调试变得简单，出现故障的时候，我们能够很容易定位到出问题的地方。
下面这些情况会造成类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。
c. 两个不同模块的内部类之间不能直接连接，否则很容易悲剧。
例如：Creator模式的例子里，实际业务中需要另一个出货人来清点订单(Order)上的商品(SKU)，并计算出商品的总价，但是由于
订单和商品之间的耦合已经存在了，那么 把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。
如下图：
2、Hight Cohesion(高内聚)
高内聚指的是类中方法和方法之间职责的相关性，也就是类自己能做的事情自己做。功能性紧密相关的职责(也就是方法)应该放在一个类里，并共同完成有限的功能，那么就是高内聚合。高内聚和低耦合往往是伴随在一起的，低耦合减少和类和类之间的联系，高内聚也可以说是一种隔离，就像人体由很多独立的细胞组成，大厦由很多砖头、钢筋、混凝土组成，每一个部分(类)都有自己独立的职责和特性，每一个部分内部发生了问题，也不会影响其他部分，因为高内聚的对象之间是隔离开的。
例如：一个订单数据存取类(OrderDAO)，订单即可以保存为Excel模式，也可以保存到数据库中；那么，不同的职责最好由不同的
类来实现，这样才是高内聚的设计，如下图：
查OrderDAOExcel类就可以了，这样也使系统更模块化，方便划分任务，比如这两个类就可以分配个不同的人同时进行开
发，这样也提高了团队协作和开发进度。
3、Information Expert(信息专家)
如何实现高内聚和低耦合，关键在于如何给类分配职责。我们要遵循的原则就是把职责分配给具有完成该职责的那个类。信息专家模式是面向对象设计的最基本原则。我们设计对象(类)的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。
例如：常见的网上商店里的购物车(ShopCar),需要让每种商品(SKU)只在购物车内出现一次，购买相同商品，只需要更新商品的数
量即可。如下图：
(SKUID)来唯一区分商品，而商品编号是唯一存在于商品类里的，所以根据信息专家模式，应该把比较商品是否相同的方法
放在商品类里。
小结：高内聚和低耦合可以说是软件开发中最重要的原则，GRASP的其它模式都是一高内聚、低耦合的原则为中心的。而实现高内聚、低耦合的原始方法这体现在信息专家这一模式里。最后，自己跟自己讲，不能为用模式才去用模式，并不是所有的地方都要用到模式，而且模式是活的，思维不要被限制住!
参考文章：http://www.cnblogs.com/justinw/archive/2006/11/28/574573.html