weixin_52566131的博客

GOF设计模式的定义和分类 设计模式的出现可以让开发人员站在前人的肩膀上，通过一些成熟的设计方案来指导新项目的设计和开发，以便于开发出具有更好的灵活性和可拓展性，以便易于复用的软件系统。 GOF：Gang of Four。创立23种设计模式的四位创始人。 1> 设计模式的定义 设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 面向对象设计模式是“好的面向对象设计”，即是那些可以满足

面向对象的设计原则 软件的可维护性和可复用性是用于衡量软件质量的质量属性，软件的可维护性是指软件能够被理解、改正、适用以及扩展的难易程度，软件的可复用性是指软件能够被复用的难易程度。 1> 开闭原则（OCP） 开闭原则（Open Closed Principle，OCP）， 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。 1.1 开闭原则的作用 开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定

单例模式（创建型模式） 1> 动机 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例? 这应该是类设计者的责任，而不是使用者的责任。 2> 意图 保证一个类仅有一个实例，并提供一个该实例的局访问点。 3> 简单的实现 public class Singleton { private static Singleton instanc

抽象工厂模式（创建性模式） 1> new 的问题 常规的对象创建方法: //创建一个Road对象 Road road=new Road(); new的问题：实现依赖，不能应对“具体实例化类型的变化。 解决思路：封装变化点一哪里变化，封装哪里。潜台词：如果没有变化，当然不需要额外的封装。 2> 工厂模式的缘起 变化点在“对象创建”，因此就封装“对象创建” 面向接口编程——依赖接口，而非依赖实现 最简单的解决方法: class RoadF actory { p

生成器模式（创建型模式） 1> Building模式的缘起 假设创建游戏中的一个房屋House设施，该房屋的构建由几个部分组成，且各个部分要富于变化。 如果使用最直观的设计方法，每一个房屋部分的变化，都将导致房屋构建的重新修正。 2> 设计目的 在软件系统中，有时候而临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。 如何应对这种变化?如何提供一种“封

工厂生产模式（创建型模式） 1> 从耦合关系谈起 耦合关系直接决定着软件面对变化时的行为 模块与模块之间的紧耦合使得软件面对变化时，相关的模块都要随之更改 模块与模块之间的松耦合使得软件面对变化时，一些模块更容易被替换或者更改，但其他模块保持不变 2> 动机( Motivation) 在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有比较稳定的接口。（例如床需要床单，但是床单可以经常换，但是床不

原型模式（创建型模式） Prototype原型模式 1> 依赖关系的倒置 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。 抽象A直接依赖于实现细节b （人用陶瓷水杯喝水，人直接依赖于陶瓷水杯） 抽象A依赖于抽象B，实现细节b依赖于抽象B（人A用杯子B喝水，杯子是陶瓷水杯b） 2> 动机 在软件系统中，经常面临着“某些结构复杂的对象’的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。 如何应对这种变化?如何

适配器模式（结构性模式） 1> 适配(转换)的概念无处不在 适配，即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。 2> 动机 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种"迁移的变化”?如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口? 3> 意图(Intent) 将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本

适配器模式（结构性模式） 1> 抽象与实现 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。 问题在于如果抽象B由于固有的原因，本身并不稳定，也有可能变化，怎么办? 2> 举例来说 假如我们需要开发一个同时支持PC和手机的坦克游戏，游戏在PC和手机上功能都一样， 都有同样的类型，面临同样的功能需求变化，比如坦克可能有多种不同的型号: T50,T75, T90 对于其中的坦克设计，我们可能很容易设计出来一个Tank的抽象基类，然后各种不同型号的Tank继承自该类

组合模式（结构性模式） 1> 对象容器的问题（俄罗斯套娃） 在面向对象系统中，我们常会遇到一类具有“容器”特征的对象——即它们在充当对象的同时，又是其他对象的容器。 2> 动机( Motivation ) 上述描述的问题根源在于：客户代码过多地依赖干对象容器复杂的内部实现结构，对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。 如何将“客户代码与复杂的对象容器结构”解耦？让对象容器自己来实现自身的复杂结构，从而使

装饰模式（结构型模式） 1> 子类复子类，子类何其多 假如我们需要为游戏中开发一种坦克，除了各种不同型号的坦克外，我们还希望在不同场合中为其增加以下一种或多种功能：比如红外线夜视功能，比如水陆两栖功能，比如卫星定位功能等等。 2> 动机(Motivation) 上述描述的问题根源在于我们“过度地使用了继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多(扩展功能的增多)，各种子类的组合(扩 展功能的组合)会导致更多子类的膨胀(多

外观模式（结构型模式） 1> 系统的复杂度 》假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为，其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。 2> 如何使用这样的系统 》左侧方案系统内部系统和外部接口相耦合，复杂度提高。 》右侧方案组合只提供一个接口拓展外部接口，保护内部系统稳定。抵抗变化的能力比较大。 3> 动机（Motivation） 》上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化