1.信息专家（Information Expert）
如果这个类能够在某个方面具有完整的信息，足以实现某个责任，就将这个责任分配给这个类，这就是所谓的信息专家。
购物车系统里，当用户购买两个想相同的商品的时候，购物车类只会列出一种商品，再在数量上增加1.那判断商品是否存在，是否相同的责任应该交给那个类呢？我们都知道，根据业务规则，两个商品是依赖商品编码来表示的，在建模时会表述为productID，那个类会有productID？这当然是Item类。所以根据信息专家原则，Item应该包括责任检测。所以我们就重写equal方法。而对于ShoppingCar类，它具有将商品的数量增加1的责任，所以应该有检测商品是否已经存在的责任。
2.创造者（Create）
应用情况符合以下条件之一，类A应该具有创建类B的责任
1. A是B的聚合
2. A是B的容器
3. A有初始化B的数据
4. A记录B的实例
5. A频繁使用B
当一个类有责任去创建其他类的实例时，这两个类就连接（又称耦合）起来了。连接本身没有错，但是我们需要出去某些不好的连接。类间的耦合用于测量一个类对另一个类的依赖大小，当两个类进行耦合，就会有一个类需要另一个类才能正常的工作。
3.低耦合（low coupling）
低耦合是指我们的设计有责任减少（降低）类间的连接。
1. 低耦合使得一个类的修改对其他类的影响范围有所降低。
2. 低耦合使得系统更加容易维护。
3. 低耦合使得类更容易理解，以为类会变得简单、专业、高内聚。
下列情况让A、B两个类产生耦合
1. A具有一个B的属性
2. A调用B对象的方法
3. A的方法包括对B的引用，例如返回的是B类型活参数是B类型
4. A是B的子类，或者A是B的实现类
不对陌生人说话原则（don’t talk to strangers）
不要相连不需要通信的两个对象，不要作无谓的耦合。
拇指规则两条
1. 如果A已经于B有连接，如分配责任A给B不合适（违反信息专家模式），那么分配责任B给A
2. 两个模块中的内部类间连接是一个大错误。
4.高内聚（high cohesion）
高内聚是指分配职责时使内聚保持最高，目的是提高设计类的重用性，并且控制类设计的复杂程度。也可以这样理解，我们要努力分解类，使得分解出来的类具有独立的责任。高内聚的宗旨是，类只处理与模块相关的功能，它与其他类合作共同完成任务。
高内聚的优点：
1. 高内聚可以表现关联责任的一个抽象，易于实现类的重用。
2. 高内聚使得维护工作变得简单。
3. 高内聚使得系统模块化。
5.控制器（constroller）
控制器类
1. 能全面代表系统、设备或者子系统的类。
2. 可以代表系统是假发生是用例发生情景的类。
3. 代表某些卷入真实世界应用中的活动类
不要将这些责任分配给用户界面类，因为控制器类不会是用户界面类。因为GRASP有以下共识：
1. 系统事件的接受与处理通常有一个高级类来代替。
2. 一个字系统会有很多控制器类，分别处理不同的事物。
范例：在银行系统中，我们会有一个控制器类用于处理所有银行事务，即类TransactionController，当用户出纳点击用户界面中用于执行支付账单的按钮时，这个事务控制器类就会取得并且处理这个事件。
6.多态（Polymophism）
7.纯虚构（Pure Fabrication）
高内聚于低耦合是相互矛盾的，因为高内聚意味着类的数量多，对象间要合作完成任务，他们之间的连接就会增加，使得耦合提高。要决绝这个矛盾，我们可以应用纯虚构模式，而应用这种模式又增加了高内聚的特征。
8.间接（indirection）
为了对象之间进行直接的耦合，可以协调组件或服务的职责分配给中间对象，这个中间对象称为间接或中介对象。，直接耦合两个子系统是错误的，会引起维护困难，间接模式就是一个解决方案。
9.受保护变化（protected variations）
找出预计有变化或不稳定的点，我们有责任为这些变化的点创建稳定的接口，受保护变化可以理解为开闭原则（the open close principle），一个软件实体应当对扩展开放，对修改关闭。换句话说，我们在设计一个模块的时候，应当使这个模块在不被修给的前提下可以扩展。
范例：jdbc 和odbc它们是连接数据库的公共接口，允许用户书写运行于来自不同产商的数据库服务器上的应用。同一应用来访问不同数据库的接口是一样的。
2950
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
