1、模式：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。解释模式：模式是一种经验的积累和总结，所以通过模式，我们可以站在巨人的肩膀上去思考问题、解决问题，熟练使用设计模式可以提高我们的工作效率，改善产品质量，最终带来经济效益。因此对于任何想开发出灵活高效、健壮的软件产品的个人或团体，熟练掌握并正确使用设计模式都是必须掌握的基本技能。GRASP (职责分配原则)GRASP(General Responsibility Assignment Software Patterns)，中文名称为“通用职责分配软件模式”，GRASP 一共包括 9 种模式，它们描述了对象设计和职
2、责分配的基本原则。也就是说，如何把现实世界的业务功能抽象成对象，如何决定一个系统有多少对象，每个对象都包括什么职责，GRASP 模式给出了最基本的指导原则。初学者应该尽快掌握、理解这些原则，因为这是如何设计一个面向对象系统的基础。可以说，GRASP 是学习使用设计模式的基础。1. Information Expert (信息专家)信息专家模式是面向对象设计的最基本原则，是我们平时使用最多，应该跟我们的思想融为一体的原则。也就是说，我们设计对象(类)的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。2. Creat
3、or (创造者)实际应用中，符合下列任一条件的时候，都应该由类来创建类，这时是的创建者：a. 是的聚合b. 是的容器c. 持有初始化的信息(数据)d. 记录的实例e. 频繁使用如果一个类创建了另一个类，那么这两个类之间就有了耦合，也可以说产生了依赖关系。依赖或耦合本身是没有错误的，但是它们带来的问题就是在以后的维护中会产生连锁反应，而必要的耦合是逃不掉的，我们能做的就是正确地创建耦合关系，不要随便建立类之间的依赖关系，那么该如何去做呢？就是要遵守创建者模式规定的基本原则，凡是不符合以上条件的情况，都不能随便用 A 创建 B。3. Low coupling (低耦合)低耦合模式的意思就是要我们尽
4、可能地减少类之间的连接。其作用非常重要：a.低耦合降低了因一个类的变化而影响其他类的范围。b.低耦合使类更容易理解，因为类会变得简单，更内聚。下面这些情况会造成类 A、B 之间的耦合：a. A 是 B 的属性b. A 调用 B 的实例的方法c. A 的方法中引用了 B，例如 B 是 A 方法的返回值或参数。d. A 是 B 的子类，或者 A 实现了 B关于低耦合，还有下面一些基本原则：a. Dont Talk to Strangers 原则：意思就是说，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题，不连接就一了百了啦！b.如果 A 已经和 B 有连接，如果分配 A 的职
5、责给 B 不合适的话(违反信息专家模式)，那么就把 B 的职责分配给 A。c.两个不同模块的内部类之间不能直接连接，否则必招报应！嘿！4. High cohesion (高内聚 )高内聚的意思是给类尽量分配内聚的职责，也可以说成是功能性内聚的职责。即功能性紧密相关的职责应该放在一个类里，并共同完成有限的功能，那么就是高内聚合。这样更有利于类的理解和重用，也便于类的维护。高内聚也可以说是一种隔离，就想人体由很多独立的细胞组成，大厦由很多砖头、钢筋、混凝土组成，每一个部分(类)都有自己独立的职责和特性，每一个部分内部发生了问题，也不会影响其他部分，因为高内聚的对象之间是隔离开的。5. Contro
6、ller (控制器)用来接收和处理系统事件的职责，一般应该分配给一个能够代表整个系统的类，这样的类通常被命名为“XX 处理器”、“XX 协调器”或者“XX 会话”。关于控制器类，有如下原则：a.系统事件的接收与处理通常由一个高级类来代替。b.一个子系统会有很多控制器类，分别处理不同的事务。6. Polymorphism (多态)这里的多态跟 OO 三大基本特征之一的“多态”是一个意思。7. Pure Fabrication (纯虚构)这里的纯虚构跟我们常说的纯虚构函数意思相近。高内聚低耦合，是系统设计的终极目标，但是内聚和耦合永远都是矛盾对立的。高内聚以为这拆分出更多数量的类，但是对象之间需要
7、协作来完成任务，这又造成了高耦合，反过来毅然。该如何解决这个矛盾呢，这个时候就需要纯虚构模式，由一个纯虚构的类来协调内聚和耦合，可以在一定程度上解决上述问题。8. Indirection (间接)“间接”顾名思义，就是这个事不能直接来办，需要绕个弯才行。绕个弯的好处就是，本来直接会连接在一起的对象彼此隔离开了，一个的变动不会影响另一个。就想我在前面的低耦合模式里说的一样，“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块，这样对于这两个模块来说，他们之间仍然是没有耦合/依赖关系的。9. Protected Variations (受保护变化)“抽象不应该依
8、赖于细节。细节应该依赖于抽象。”关于这个原则，还有种说法是.“高层不应该依赖于底层，两者都应该依赖于抽象。”其实怎么说都是对的，关键就是要理解一点，只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！哈哈！比设计模式更重要：设计原则对于设计模式来说，为什么这个模式要这样解决这个问题，而另一个模式要那样，它们背后都遵循的就是永恒的设计原则。可以说，设计原则是设计模式的灵魂。1. 单一职责原则(SRP)“就一个类而言，应该仅有一个引起它变化的原因。”也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到
9、不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)2. 开放封闭原则(OCP)“软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。”嘿！多么朴实的话语，第一次看这个原则的时候我都看傻了，我当时在想“这不是&#%做白日梦吗！不修改怎么扩展啊？”但是随着学习的深入，理解了这个“不修改”是什么意思，意思是“你可以随便增加新的类，但是不要修改原来的类”。从这个角度去理解就好多了，其实这里还是一个隔离变化的问题。3. 依赖倒置原则(DIP)“抽象不应该依赖于细节。细节应该依
10、赖于抽象。”关于这个原则，还有种说法是.“高层不应该依赖于底层，两者都应该依赖于抽象。”其实怎么说都是对的，关键就是要理解一点，只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！哈哈！4. 接口隔离原则(ISP)“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。5. 替换原则(LSP)“子类型必须能够替换掉它们的基类型。”也就是说继承中的“IS A”关系是必须保证的，否则还算什么继承啊！如果违反了 LSP 原则，常会导致在运行时(RTTI)的类型判断违反 OCP 原则。作者：Justin出处：http:/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
