Gof的23种设计模式.docxVIP

I I:接口隔离原则（Interface Segregation Principle, ISP ）， Gof 的 23 种设计模式 从 2005 年初听说设计模式， 到现在虽然已经 8 年多了， 但 GoF 的 23 种模式依然盛行，当然 GoF 提出这些模式的 年代更加久远（ 1995 年）。 在工作的过程中，陆陆续续 接触了 GoF 的大部分模式， 我记得在 2008 年的时候就想总 结一下设计模式（最近想做的两件事情） ，最后因为各种原 因也没有完成。最近这段时间正好是职业空档期，没什么事 儿做，就把之前看过的设计模式翻出来整理了一下，于是就 有了上面几篇文章。整理设计模式的过程，也是一个深 有了上面几篇文章。 整理设计模式的过程，也是一个深 刻理解面向对象设计的过程。通过对各个模式的回顾，让我 更能够明白前辈们关于面向对象设计提出的各种“最佳实践”， 特别是 S.O.L.I.D ，我觉得在这里再说一次，也不算矫情。 ），S :单一职责原则(Single Res ponsibility P rinci pie, SRP ）， 个类只能有一个原因使其发生改变，即一个类只承担一个 职责。 O:开放-圭寸闭原则(Open-Close Principie, OCP ),这 里指我们的设计应该针对扩展开放，针对修改关闭，即尽量 以扩展的方式来维护系统。 ），L :里氏替换原则 ( Liskov Subsititution Principle, LSP ）， 它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响， 这样可以保证我们使用“继承”并没有破坏父类。 客户端不应该依赖于它不需要的接口，两个类之间的依赖应 该建立在最小接口的基础上。这条原则的目的是为了让那些 使用相同接口的类只需要实现特定必要的一组方法，而不是 大量没用的方法。 D :依赖倒置原贝廿（ Dependence Inversion Principle, DIP）,高层模块不应该依赖于低层模块，两者应该都依赖于 抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主 要是提倡“面向接口”编程，而非“面向实现”编程。设计 要是提倡“面向接口”编程，而非“面向实现”编程。 设计 模式，从本质上讲，是针对过去某种经验的总结。每种设计 模式，都是为了在特定条件下去解决特定问题，离开这些前 提去讨论设计模式，是没有意义的。面，我们快速回 提去讨论设计模式，是没有意义的。 面，我们快速回 顾 GoF 的 23 种模式。工厂方法 意图:定义一个用户创建对象的接口，让子类去决定具体使 用哪个类。 适用场合: 1）类不知道它所要创建的对象的类信息； 2） 希望由它的子类来创建对象。抽象工厂 意图:提供一个创建一系列相关或者相互依赖的对象的接口， 而无须指定它的具体实现类。 3）适用场合: 1）系统不依赖于产品是如何实现的细节； 2 3） 统的产品族大于 1，而在运行时刻只需要某一种产品族； 属于同一个产品族的产品，必须绑在一起使用；4 ）所有的 属于同一个产品族的产品，必须绑在一起使用； 4 ）所有的 产品族，可以抽取公共接口单例 意图：保证一个类只有一个实例，并且在系统全局范围内提 供访问切入点。 适用场合：各种“工厂类”构造者 意图：将复杂对象的构造与表示相分离，使得同样的构造过 程可以产生不同的复杂对象。 适用场合： 1 适用场合： 1）需要创建的对象有复杂的内部结构； 2）对象 的属性之间相互依赖，创建时前后顺序需要指定。原型 意图：用原型实例指定创建对象的种类，并通过复制原型实 例得到对象。 适用场合： 1 适用场合： 1）系统不关心对象创建的细节； 2）要实例化的 对象的类型是动态加载的； 3 ）类在运行过程中的状态是有 意图：将一个类的接口转换成用户希望的另一个接口。 适用场合：系统需要使用现有类的功能，但接口不匹配装饰 意图：动态的为对象添加额外职责 加或者取消； 3）添加的职责很多，从而不能用继承实现。 适用场合： 1 适用场合： 1）需要添加对象职责； 2）这些职责可以动态添 桥接器 意图：将抽象部分与实现部分分离，从而使得它们可以独立 变化 适用场合： 1）系统需要在组件的抽象化角色与具体化角色 之间增加更多的灵活； 2 ）角色的任何变化都不应该影响客 户端； 3 ）组件有多个抽象化角色和具体化角色享元 意图：运用共享技术支持大量细粒度的对象 适用场合：1 适用场合： 1）系统中有大量对象； 2）这些对象占据大量内 4）可存； 3 4）可 以按照内部状态将对象分为不同的组； 5 ）对系统来讲，同 个组内的对象是不可分辨的门面 意图：为系统的一组接口提供一个一致的界面 适用场合： 1）为一个复杂的接口提供一个简单界面； 2）保 持不同子系统的独立性；