是小光a~

总体来说基本的23种设计模式分为三大类：创建型模式（5种）：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式（7种）：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。行为型模式（11种）：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。推荐资料（电子版：书籍/笔记总结）生活不止眼前的苟且，还有将来的苟且，偶尔带一些诗和远方~ 加油，奥利给！

设计模式UML图创建型模式（5种）：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式（7种）：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。行为型模式（11种）：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

设计模式原则单一职责原则单一职责原则（Single Responsibility Principle，简称SRP），就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离，要判断是否应该分离，就是如果想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类

对设计模式的简要概括（转）创建型：抽象工厂模式（Abstract Factory）:提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。构建器模式（Builder）：将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示。工厂方法模式（Factory Method）：定义一个创建对象的接口，但由子类决定需要实例化哪一个类。工厂方法使得子类实例化的过程推迟。原型模式（Prototype）：用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象。单例模

访问者模式：访问者模式（Visitor），表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。主要解决：稳定的数据结构和易变的操作耦合问题。如何解决：在被访问的类里面加一个对外提供接待访问者的接口。关键代码：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。优点：1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。缺点： 1、具体元素对访问者公布细节，违反了迪米特原则。 2、具体元素变更比较困难。 3、违反了依赖倒置原则，依赖了

享元模式：享元模式（Flyweight）：运用共享技术有效地支持大量细粒度的对象。减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。何时使用： 1、系统中有大量对象。 2、这些对象消耗大量内存。 3、这些对象的

中介者模式：中介者模式（Mediator）（调停者模式），用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立的改变它们之间的交互。主要解决：对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。何时使用：多个类相互耦合，形成了网状结构。如何解决：将上述网状结构分离为星型结构。例：中介者模式UML结构图：例：MVC 框架，其中C（控制器）就是

职责链模式：职责链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连接成一条链，并沿着这条链传递该请求，直到有一个（ConcreteHandler）对象处理它为止。职责链模式UML结构图：这里发出的请求，客户端并不知道这当中的哪一个对象最终处理这个请求，这样系统的更改可以在不影响客户端的情况下动态地重新组织和分配任务。职责链模式使得接收者和发送者都没有对方的明确信息，且链中的对象自己也不知道链的结构，简化了对

命令模式：命令模式（Command）（行动（Action）模式或交易（Transaction）模式。），是一种数据驱动的设计模式，它属于行为型模式，将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令允许请求的一方和接收请求的一方能够独立演化，从而有以下的优点：命令模式使新的命令很容易地被加入到系统里。允许接收请求的一方决定是否要否决（Ve

桥接模式：桥接模式（Bridge），将抽象部分与它的实现部分分离，使它们都可以独立地变化。（实现系统可能有多角度分类，每一种分类都有可能变化（只用继承会造成类的大量增加，不能满足开放——封闭原则），那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合）抽象与它的实现分离，并不是说让抽象类与其派生类分离，实现指的是抽象类和它的派生类用来实现自己的对象。例：手机既可以按照品牌来分类，也可以按照功能来分类，具体可以参考下面实例：按品牌分类：按软件实现分类：由于实现的方式有多种，桥接模式的核心

单例模式：单例模式（Singleton），保证一个类仅有一个实例，并提供一个访问它的全局访问点。（本质：控制实例数目）单例模式UML结构图：Singleton模式包含的角色只有一个，就是Singleton。Singleton拥有一个私有构造函数，确保用户无法通过new直接实例它。除此之外，该模式中包含一个静态私有成员变量instance与静态公有方法GetInstance。GetInstance方法负责检验并实例化自己，然后存储在静态成员变量中，以确保只有一个实例被创建。单例模式的实现又分为两种：

迭代器模式：迭代器模式（Iterator），提供一种方法顺序访问每一个聚合对象中的各个元素，而又不暴露该对象的内部表示。何时使用：当需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，就可以考虑使用迭代器模式。需要对聚集有多种遍历方式时，可以考虑使用迭代器模式。使用场景：访问数组，集合，列表等数据时，尤其是在操作数据库数据时，是非常普遍的应用，但是由于它过于普遍，很多高级语言都对它进行了封装。例：.Net中的foreach inJava中的for(Leaf leaf:childL

组合模式：组合模式（Composite），将对象组合成树形结构以表示“部分整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。组合模式UML结构图：组合模式的目的：让客户端不再区分操作的是组合对象还是叶子对象，而是以一种统一的方式来操作对象树，组合模式会组合出树形结构来，这也就意味着，所有可以使用对象树来描述或操作的功能，都可以考虑使用组合模式。比如读取XML文件，或是对语句进行语法分析等。组合模式的实现根据所实现接口的区别分为两种形式，分别称为安全模式和透明模式。组合模式可以

备忘录模式：备忘录模式（Memento），在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态。示意图如下：优点：1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。2、实现了信息的封装，使得用户不需要关心状态的保存细节。（有时一些发起人对象的内部信息必须保存在发起人对象以外的地方，但是必须要由发起人对象自己读取，这时，使用备忘录模式可以把复杂的发起人内部信息对其他的对象屏蔽起来，从而可以恰当地保持

适配器模式：适配器模式（Adapter），将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。简单地说，就是所需要的东西就在眼前，但却不能使用，而在短时间内又无法改造它，于是我们就想办法适配它。适配器模式主要应用于我们希望复用一些现存的类，但是接口与复用环境要求不一致的情况，这在遗留代码复用、类库迁移等方面非常有用。其本质就是：转换匹配，复用功能GOF设计模式中，对适配器讲了两种类型：类适配器模式和对象适配器模式。类适配器模式通过多重

状态模式：状态模式（State），当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。状态模式主要解决的是当一个控制对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。（面向对象设计其实就是希望做到代码的责任分解，方法很长是坏味道！如果一个方法很长，而且有很多判断分支，这就意味着它的责任过大了，无论任何状态，都需要通过它来改变，这实际上是很糟糕的。）优点：1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确

抽象工厂模式：提供一个创建一系列相关或者相互依赖对象的接口，而无需指定它们具体的类。例：我们在调用数据库时，可能会采用不同的数据库，进而其实现细节也会有所不同。如果我们在客户端实例化数据库对象，那么这个对象就完全被这个数据库限制了，若采用其他数据库时，在执行同样地操作时（比如插入数据）我们就不能利用这个对象的方法去调用Insert（）实现。因此我们可以考虑工厂方法模式去改进实现，达到多态（工厂方法模式是定义一个用于创建对象的接口，让子类决定实例化那一个类）工厂方法模式下的数据库访问UML图:采用I

观察者模式：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态发生变化时，会通知所有观察者对象（依赖它的对象），使它们能够自动更新自己。观察者模式属于行为型模式。观察者模式又叫：发布——订阅（Publish/Subscribe）模式模型——视图（Model/View）模式源——监听器（Source/Listener）模式从属者（Dependents）模式意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知

建造者（生成器）模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。如果我们采用建造者模式，我们只需要指定需要创建的类型就可以得到他们，而不需要了解具体的创建过程和细节。建造者模式UML结构图：建造者（Builder）角色：定义创建一个Product对象所需的各个部件的操作。具体建造者（Concrete Builder）角色：实现Builder角色提供的接口，一步一步完成创建产品实例的过程。在建造过程完成后，提供产品的实例。指导者（Director）角色：主要用来使

外观（门面）模式：为子系统中的一组接口提供一个一致的界面，此时模式定义了一个高层接口，这个接口使得这一个子系统更加容易使用，即该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。何时使用： 1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口。如何解决：客户端不与系统耦合，外观类与系统耦合。关键代码：在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。应用实

模板方法模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式实际上是所有模式中最为常见的几个模式之一，而且很多人可能使用过模板方法模式而没有意识到自己已经使用了这个模式。模板方法模式是基于继承的代码复用的基本技术，模板方法模式的结构和用法也是面向对象设计的核心。缺点：算法骨架不容易升级（模板和子类是非常耦合的，如要对模板中的算法骨架进行变更，会影响子类变化）UML结构图（以登录界面实现为例）：例（通过JD

原型模式：用原型实例指定创建对象的种类，并且通过拷贝这种原型创建新的对象。（从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节）使用场景： 1、资源优化场景。 2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 3、性能和安全要求的场景。 4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5、一个对象多个修改者的场景。 6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。

工厂方法模式：简单工厂 VS 工厂方法（以计算器为例）：简单工厂UML结构图：工厂方法UML结构图：简单工厂模式最大的优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。但是我们增加新功能时，我们一定要修改工厂类中的Case分支条件，这样就不满足开放——封闭原则了。工厂方法模式定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法模式使一个类的实例化延迟到了其子类。工厂方法模式UML结构图：这样整个工厂和产品体系其

代理模式：代理模式（Proxy Pattern），为其他对象提供一种代理以控制对这个对象的访问，这种类型的设计模式属于结构型模式。代理模式其实就是访问对象时引入一定程度的间接性，因为这种间接性，可以附加多种用途（代理就是真实对象的代表。）应用实例： 1、Windows 里面的快捷方式。 2、猪八戒去找高翠兰结果是孙悟空变的，可以这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，所以说孙悟空是高翠兰代理类。 3、买火车票不一定在火车站买，也

装饰器模式：装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。缺点：多层装饰比较复杂。使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销

策略模式：策略模式的用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化（策略模式是对算法的包装，是把使用算法的责任和算法本身分割开，委派给不同的对象管理）。使用策略模式可以把行为和环境分割开来。环境类负责维持和查询行为类，各种算法则在具体策略类( ConcreteStrategy)中提供。由于算法和环境独立开来，算法的增减、修改都不会影响环境和客户端。当出现新的促销折扣或现有的折扣政策出现变化时，只需要实现新的

简单工厂模式：接口是用来封装隔离具体的实现的，目标就是不要让客户端知道封装体内部的具体实现。简单工厂的位置是位于封装体内的，所以简单工厂知道具体类的实现是没有关系的。对于客户端来说，只是知道了接口和简单工厂。优点:工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。简单工厂模式通过这种做法实现了对责任的分割。缺点:当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模式的缺点。因为工厂类集中了所有产品创建逻辑