设计模式概述

该笔记是基于B站李建忠老师讲的设计模式所做
面向对象设计原则
1.依赖倒置原则（DIP）

 高层模块（稳定）不应该依赖低层模块（变化） ，二者都应该依赖于抽象（稳定）
 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）

2.开放封闭原则（OCP）

 对拓展开放，对更改封闭
 类模块应该是可拓展的，但是不可修改

3.单一职责原则（SRP）

 一个类应该仅有一个引起他变化的原因
 变化的方向隐含着类的责任

4.李氏替换原则（LSP）

 子类必须能够替换他们的基类
 继承表达类型抽象

5.接口隔离原则（ISP）

 不应该强迫客户程序依赖他们不用的方法
 接口一个小而完备 

6.优先使用对象组合，而不是类继承

  类继承通常为“白箱复用”，对象组合通常为"黑箱复用"
  继承在某种程度上破坏了封装性，子类父类耦合度高
  而对象组合则只要对被组合的对象具有良好的定义的接口，耦合度低

7.封装变化点

使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良影响从而实现对层次间的松耦合

8.针对接口编程而不是针对实现编程

  不将变量类型声明为某个特定类型的具体类，而是声明为某个接口。
  客户程序无需获知对象的具体类型，只需要知道对象所具有的接口
  减少系统中各个部分的依赖，从而实现高内聚，松耦合的类型设计方案。

设计模式分类
创建型 （工厂方法，抽象工厂 生成器 原型模式 单例模式)

      将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型现引来的冲击

结构型 （适配器，桥接，组合，装饰，外观，享元，代理模式）

     通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。

行为型 （责任链 命令模式 迭代器 中介者 备忘录 观察者 状态 策略 模板方法 访问者）

    通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击

**

创建型模式

**

• 动机（Motivation）
  1.在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。
  2.如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？

工厂方法模式

• 模式定义
  定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟

• 要点总结
  1.Factory Method模式用于隔离类对象的使用者和具体类型之间的 耦合关系。面对一个经常变化的具体类型，紧耦合关系(new)会导 致软件的脆弱。
  2.Factory Method模式通过面向对象的手法，将所要创建的具体对 象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
  3.Factory Method模式解决“单个对象”的需求变化。缺点在于要 求创建方法/参数相同。

抽象工厂模式

• 提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类

• 要点总结
  1 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。
  2 “系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
  3 Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

原型模式

• 原型模式是一种创建型设计模式， 使你能够复制已有对象， 而又无需使代码依赖它们所属的类。
• 原型模式将克隆过程委派给被克隆的实际对象。 模式为所有支持克隆的对象声明了一个通用接口， 该接口让你能够克隆对象， 同时又无需将代码和对象所属类耦合。 通常情况下， 这样的接口中仅包含一个 克隆方法

生成器模式

• 模式定义
  将一个复杂对象的构建与其表示相分离，使得同样的构建过
  程(稳定)可以创建不同的表示(变化)

• 要点总结
  Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
  变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动

单例模式

• 动机 (Motivation )
  在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。
  如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例?这应该是类设计者的责任,而不是使用者的责任。

• 模式定义
  保证一个类仅有一个实例，并提供一个该实例的全局访问点。

• 要点总结
  Singleton模式中的实例构造器可以设置为protected以允许子类派生。
  Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。
  如何实现多线程环境下安全的Singleton ?注意对双检查锁的正确实现。

**

结构型

**
适配器模式

• 动机(Motivation )
  在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
  如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口?

• 模式定义
  将一个类的接口转换成客户希望的另一个接口。Adapter模式可以使原本不相兼容的接口一起工作。

• 要点总结
  Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。
  GoF 23定义了两种Adapter模式的实现结构∶对象适配器和类适配器。但类适配器来用“多继承”的实现方式，一般不推荐使用。对象适配器采用“"对象组合”的方式，更符合松耦合精神。
  Adapter模式可以实现的非常灵活，不必拘泥于Gof23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象~作为新的接方法参数，来送到配合的目的。

桥模式

• 动机 (Motivation )
  由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。
  如何应对这种“多维度的变化”?如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度?
• 模式定义
  将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。
  要点总结
  Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
  所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。
  Bridge模式有时候类似于多继承，但多继承往往违背单一职责原则，复用性较差。Bridge模式是比多继承方案更好的解决方法。
  Bridqe模式的应用一般在“两个非常强的变化维度”.，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

组合模式

• 动机(Motivation )
  在软件在某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器丙部实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。
  如何将“客户代码与复杂的对象容器结构”解耦?让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器?

• 模式定义
  将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性（稳定)。

• 要点总结
  Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一"的关系，使得客户代码可以二致地(复用)处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
  将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口—.而非对象容器的内部实现结构二—发生依赖，从而更能“应对变化”。
  Composite模式在具体实现中，可以让父对象中的子对象反向追溯;如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

装饰模式

• 动机（Motivation )
  在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性;并且随着子类的增多（扩展功能的增多),各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。
  如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响将为最低?
• 模式定义
  动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类(继承）更为灵活（消除重复代码&减少子类个数)。
• 要点总结
  通过继承而非组合的思想Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免 了使用继承带来的“灵活性差”和“多子类衍生问题
  ator类在接口上表现为is-a Component的继承关系，即 Decorator类继承了Component类所具有的接口。但在实现上又 表现为has-a Component的组合关系，即Decorator类又使用了 另外一个Component类。
  decorator模式的目的并非解决“多子类衍生的多继承”问题， Decorator模式应用的要点在于解决“主体类在多个方向上的扩展 功能”——是为“装饰”的含义。

门面模式（外观模式）

• 模式定义
  为子系统中的一组接口提供一个一致(稳定)的界面，Facade模式定义了一个高层接口，这个接口使得这─子系更加容易使用（复用）
• 要点总结
  从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对子组件丙部与外部客户程序来说，达到了一种“解耦”的效果—内部子系统的任何变化不会影响到Facade接口的变化。
  Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Faade很多时候更是一种架构设计模式。
  Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。

享元模式

• 动机(Motivation )
  在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价—主要指内存需求方面的代价。
  如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?
• 模式定义
  运用共享技术有效地支持大量细粒度的对象。
• 要点总结
  面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代桥尚题，一般不触及面向对象的抽象性问题。
  Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在真体实现方面，要注意对象状态的处理。
  对象的数量太大从而导致对象内存开销加大——什么样的数量才算天?这需要我们仔细的粮据真体应用情况进行评估，而不能凭空臆断。

代理模式

• 动机 (Motivation )
  在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等)直接访问会给使用者、或者系统结构带来很多麻烦。
  如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性?增加一层间接层是软件开发中常见的解决方式。
• 模式定义
  为其他对象提供—种代理以控制（隔离,使用接口)对这个对象的访问。
• 要点总结
  “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方活:舍面向对象系统史直接使用某些对象会带来很多问题，作另尚接层的proxy对象便是解沃这一问题的常用手段。
  具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块摸供抽象代理层在架构层次对对象做proxy。
  Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时损失一些透明性是可以接受的

行为型

责任链模式

• 动机 (Motivation )
  在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。
  如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。

• 模式定义
  使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。

• 要点总结
  Chain of Responsibility 的应用场合在于一个对象请求有多个接受者，但最后真正的接受者是只有一个，这是请求发送者与解耦者的耦合可能变得脆弱，职责链的目的是将两者解耦
  从而更好的应对变化。
  应用了Chain of Responsibility模式后，对象的职责分派将更具复活性。我们可以在运行时动态添加/修改请求的处理职责。
  如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责在，而不皇发出请求的对象的责任。

命令模式

• 动机 (Motivation )
  在软件构建过程中，“行为请求者”与“行为实现者”通常呈现—种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重(undo/redo)、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
  在这种情况下，如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象，可以实现二者之间的松耦合。
• 模式定义
  将一个请求(行为)封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。
• 要点总结
  Command模式的根本目的在于将“行为请求者"与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
  实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令”封装为一个“复合命令”MacroCommand。

迭代器模式

• -动机(Motivation )
  在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。
  在这种情况下，将特定领域的问题表达为某种语法规则下的句子然后构建一个解释器来解释这样的句子，从而达到解决问题的自的。
• 模式定义
  给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。
• 要点总结
  有满定“业务规则频繁变化，直类似的结构不断董复出b，并直容易抽象为语法规则的问题”才适合使用Interpreter模式。
  使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧来方便地“扩展”文法。
  Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，Interperter模式会产生比较大的类层次结构，需要求助于语法分斤牛战器这锋的标准I

中介者模式

• 动机 (Motivation )
  在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
  在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
• 模式定义
  用一个中介对象来封装（封装变化)一系列的对象交互。中介者使各对象不需要显式的相互引用(编译时依赖→运行时依赖)，从而使其耦合松散（管理变化)，而且可以独立地改变它们之间的交互。
• 要点总结
  将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。
  随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
  Facade模式是解耦系统间(单向）的对象关联关系;Mediator模式是解耦系统内各个对象之间(双向)的关联关系。

备忘录模式

• 动机(Motivation )
  在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
  如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏对象本身的封装性。
• 模式定义
  在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。
• 要点总结
  备忘录（ Memento)存储原发器(Originator)对象的内部状态，在需要时恢复原发器状态。
  Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但筒时又需要将状态保持到外界
  (Memento )。
  由于现代语言运行时（如C#、Java等）都具有相当的对象序列化支持，因此往往采用效率较高、又较容易正确实现的序列化方案来实现Memento模式。

观察者模式

• 动机(Motivation )
  在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”———个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密将使软件不能很好地抵御变化。
  使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
• 模式定义
  定义对象间的一种一对多（变化)的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到涌知并自动更新。
• 要点总结
  使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
  目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数)会自动传播。
  观察者自己决定是否需要订阅通知，目标对象对此一无所知。
  Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

状态模式

• 动机(Motivation )
  在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
  如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?
• 模式定义
  允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。
• 要点总结
  State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象;但同时维持State的接首，这样卖现了真体操作与状态转换之间的解耦。
  为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的一—即要么彻底转换过来，要么不转换。
  如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。

策略模式

• 动机 （Motivation )
  在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。
  如何在运行时根据需要透明地更改对象的算法﹖将算法与对象本身解耦，从而避免上述问题?
• 模式定义
  定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）
  该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化)。
• 要点总结
  Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
  Strateqy模式提供了用条件判断语句以外的另一种选择，消除条件判断语苟，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。
  如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strateav对缘从而节省对象开销

模板方法

• 动机(Motivation )
  在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现
  如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求?
• 模式定义
  定义一个操作中的算法的骨架(稳定)，而将一些步骤延迟(变化)到子类中。Template Method使得子类可以不改变(复用)一个算法的结构即可重定义(overr’ride重写)该算法的某些特定步骤。
• 要点总结
  Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性)为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。
  除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用。
  在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法。

访问器模式

• 动机(Motivation )
  在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。
  如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题?
• 模式定义
  表示一个作用于某对象结构中的各元素的操作。使得可以在不改变（稳定)各元素的类的前提下定义(扩展）作用于这些元素的新操作（变化)。
• 要点总结
  Visitor模式通过所谓双重分发(,double dispatch).来实现在不更改（不添加新的操作-编译）Element类层次结构下，在运行时透明的为类层次结构上的各个类动态的添加新的操作
  所谓双重分发即MisitQr模式中间包插了两全多态分发(注意其中的多态机制):第二个为accept方法的多态辨析
  visitElementX方法的多态辨析。
  Visitor模式的最大缺点在于扩展类层次结构(增添新的Element子"x草猷ior然的改女贪的Vistor模式送用子"Element羹层次结稿赣定，而食甲的藻作却经常面临频繁改动”。

这里给大家推荐一个超好用的学习设计模式的网站