23种设计模式及设计模式的六大原则

示例代码链接:https://github.com/Winter730/winterDesignPattern

设计模式的六大原则

总原则：开闭原则

开闭原则就是说对扩展开发，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码。实现一个热插拔的效果，所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。

单一职责原则

不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
即，就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

里氏替换原则

任何基类可以出现的地方，子类一定可以出现。(子类必须能够替换掉父类)

依赖倒转原则

面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
高层模块不应该依赖底层模块，两个都应该依赖抽象。
抽象不应该依赖细节。细节应该依赖抽象。

依赖依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计。

接口隔离原则

每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。

迪米特法则（最少知道原则）

一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

合成复用原则

尽量首先使用合成/聚合的方式，而不是使用继承。

聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成则是一种强的'拥有'关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。

优先使用对象的合成/聚合有助于保持每个类被封装，并被集中在单个任务上。这样类和类的继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

23种设计模式

总体来说设计模式分为三大类：
创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

创建型模式

单例模式

某个类只能有一个实例，提供一个全局的访问点
通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是,让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法
优点:由于单例模式在内存中只有一个实例，减少了内存开销。

• Singleton
  定义一个GetInstance操作,允许用户访问它的唯一实例。
  GetInstance是一个静态方法,主要负责创建自己的唯一实例。

简单工厂

一个工厂类根据传入的参量决定创建出那一种产品类的实例
该模式主要用于解决对象的创建问题

工厂方法

定义一个创建对象的接口，让子类决定实例化哪个类

Q1： 简单工厂&工厂方法
简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。(遇到某些问题时会违背开放-封闭原则)

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。想要加功能，本来是改工厂类的，现在是修改客户端。

工厂方法客服了简单工厂违背开放-封闭原则的缺点，又保持了封装对象创建过程的优点

工厂方法和简单工厂都是集中封装了对象的创建，使得要更换对象时，不需要做太大的改动就可实现，降低了客户程序与产品对象的耦合。
工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。但缺点是每加一个产品，就需要加一个产品工厂的类，增加了额外的开发量。

抽象工厂

提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类。
抽象工厂最大的好处便是易于交换产品系列，由于具体工厂类在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。同时，它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

• Builder
  为创建一个Product对象的各个部件指定的抽象接口
• ConcreteBuilder
  具体建造者，实现Builder接口，构造和装配各个部件
• Product
  具体产品，由多个部件组成
• Director
  指挥者，用来构建一个使用Builder接口的对象

建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。用于创建一些复杂对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。

建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。

原型模式

通过复制现有的实例来创建新的单例。

原型模式其实就是从一个对象再创建另外一个可定制的对象，而不需知道任何创建的细节。

结构型模式

适配器模式

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

• Adaptee
  需要适配的类
• Adapter
  通过在内部包装一个Adaptee对象,把源接口转换成目标接口
• Target
  这是用户所期待的接口。目标可以是具体的类或者抽象的类,也可以是接口

实现方式:1、对象适配器（采用对象组合方式实现）2、类的适配器模式（采用继承实现）

系统的数据和行为都正确，但接口不符时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。

组合模式

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

• Component
  Component为组合中的对象声明接口,在适当情况下,实现所有类共有接口的默认行为。
  声明一个接口用于访问和管理Component的子部件
• Composite
  Composite定义有枝节点行为,用来存储子部件,在Component接口中实现与子部件有关的操作
  比如增加Add和删除Remove
• Leaf
  Leaf在组合中表示叶节点对象,叶节点没有子节点

需求中是体现部分和整体层次的结构时，希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式了。

组合模式让客户可以一致地使用组合结构和单个对象。

装饰模式

动态的给对象添加新的功能

• Component
  定义一个对象接口，可以给这些对象动态地添加职责
• ConcreteComponent
  定义了一个具体的对象，也可以给这个对象添加一些职责
• Decorator
  装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的。
• ConcreteDecorator
  具体的装饰对象，起到给Component添加职责的功能

例如：角色的衣服设定

装饰模式是为已有功能动态地添加更多功能的一种方式
装饰模式把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地，按顺序地使用装饰功能包装对象了。
装饰模式的优点在于把类中的装饰功能从类中搬移去除，简化原有的类，有效地把类的核心职责和装饰功能区分开。而且可以去除相关类中重复的装饰逻辑。

代理模式

为其他对象提供一个代理以便控制这个对象的访问

• Subject
  定义了RealSubject和Proxy的共用接口，这样就在任何使用RealSubject的地方都可以使用Proxy
• RealSubject
  定义Proxy所代表的真实实体
• Proxy
  保存一个引用使得代理可以访问实体，并提供一个与Subject的接口相同的接口，这样代理就可以用来替代实体

代理模式的应用场景:

1. 远程代理，也就是为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。(nginx)

2. 虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。(ajax异步加载)

3. 安全代理，用来控制真实对象访问时的权限。一般用于对象有不同的访问权限的时候（shiro）

4. 智能指引，当调用真实的对象时，代理处理另外一些事。(aop)

享元模式

通过共享技术来有效的支持大量颗粒度的对象

• FlyweightFactory
  一个享元工厂,用来创建并管理Flyweight对象.它主要是用来确保合理地共享Flyweight
  当用户请求一个Flyweight时,FlyweightFactory对象提供一个已创建的实例或者创建一个(如果不存在的话)
• Flyweight
  它是所有具体享元类的超类或接口,通过这个接口,Flyweight可以接受并作用于外部状态
• ConcreteFlyweight
  继承Flyweight超类或者实现Flyweight接口,并为内部状态增加存储空间
• UnsharedConcreteFlyweight
  UnsharedConcreteFlyweight是指那些不需要共享的Flyweight子类
  因为Flyweight接口共享称为可能,但它并不强制共享

享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。
如果能发现这些实例除了几个参数外基本上都是相同的，有时就能够大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数目。

外观模式

对外提供一个统一的方法，来访问子系统中的一群接口

• Facade
  外观类，知道哪些子系统类负责处理请求，将客户的请求代理给适当的子系统对象
• SubSystem Classes
  子系统类集合，实现子系统的功能，处理Facade对象指派的任务，注意子类中没有Facade的任何信息，即没有对Facade对象的引用。

外观模式的使用场景：

1. 在设计初期阶段，应该要有意识的将不同的两个层分离，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。

2. 其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂。增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。

3. 在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖于它。此时用外观模式Facade也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰的简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

桥接模式

将抽象部分和它的实现部分分离，使它们都可以独立的变化

行为型模式

模板模式

定义一个算法结构，而将一些步骤延迟到子类实现，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤

当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方式模式来处理。

• AbstractClass
  抽象类，也是抽象模板，定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。
• ConcreteClass
  实现父类所定义的一个或多个抽象方法。每一个AbstractClass都可以有任意多个ConcreteClass与之对应，而每一个ConcreteClass都可以给出这些抽象方法(也就是顶级逻辑的组成步骤)的不同实现，从而使得顶级逻辑的实现各不相同。

模板方法特点

• 模板方法模式是通过把不变行为搬移到超类，去除子类中的重复代码来体现它的优势。它提供了一个很好的代码复用平台。

• 当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。我们通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠。

解释器模式

给定一个语言，定义它的文法的一种表示，并定义一个解释器。这个解释器使用该表示来解释语言中的句子。

• Context
  包含解释器之外的一些全局信息
• AbstractExpression
  声明一个抽象的解释操作，这个接口为抽象语法树中所有的结果所共享
• TerminalExpression
  实现与文法中的终结符相关联的解释操作，实现抽象表达式中所要求的接口,主要是一个interpret()方法，文法中每一个终结符都有一个具体终结表达式与之对应
• NonterminalExpression
  为文法中的非终结符实现解释操作，对文法中每一条规定R1,R2...Rn都需要一个具体的非终结符表达式类，通过实现抽象表达式的interpret()方法实现解释操作。
  解释操作以递归方式调用上面所提到的代表R1、R2...RN中各个符号的实例变量。

如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

策略模式

定义一系列算法，把他们封装起来，并且使它们可以相互替换，此模式让算法的变化，不会影响到使用算法的客户。

• Strategy
  定义所有支持的算法的公共接口
• ConcreteStrategy
  封装了具体的算法或行为
• Context
  用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用。

策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。

策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。
当不同的行为堆砌在一个类中时,就很难避免使用条件语句来选择合适的行为。
将这些行为封装在一个个独立的Strategy类中，可以在使用这些行为的类中消除条件语句。

策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只是在分析过程中遇到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

策略模式简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

状态模式

允许一个对象在其对象内部状态改变时改变它的行为

• State
  抽象状态类，定义一个接口以封装与Context的一个特定状态相关的行为
• Context
  维护一个ConcreteState子类的实例，这个实例定义当前的状态
• ConcreteState
  具体状态，每一个子类实现一个与Context的一个状态相关的行为

状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

状态模式的好处是将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。
将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。

状态模式的目的在于消除庞大的条件分支语句。
状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。
当一个对象的行为取决于它的状态，并且它必须运行时刻根据状态改变它的行为时，就可以考虑使用状态模式。

观察者模式

观察者模式定义了对象间一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

• Subject
  主题或抽象通知者，一般用一个抽象类或一个接口实现。它把所有对观察者对象的引用保存在一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。

• Observer
  抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。这个接口叫做更新接口。
  抽象观察者一般用一个抽象类或一个接口实现。更新接口通常包含一个Update()方法，这个方法叫做更新方法。

• ConcreteSubject
  具体主题或具体通知者，将有关状态存入具体观察者对象，在具体主题的内部状态改变时，给所有登记过的观察者发出通知，具体主题角色通常用一个具体子类实现。

• ConcreteObserver
  具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。具体观察者角色可以保存一个指向主题对象的引用。具体观察者角色通常用一个具体子类实现。

观察者模式的关键对象是主题Subject和观察者Observer，一个Subject可以有任意数目的依赖它的Observer，一旦Subject的状态发生了改变，所有的Observer都可以得到通知。Subject发出通知时并不需要知道谁是它的观察者，也就是说，具体观察者是谁，它根本不需要知道。而任何一个具体观察者不知道也并不需要知道其他观察者的存在。

观察者模式的场景
当一个对象的改变可以同时改变其他对象，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。
观察者模式所做的工作其实就是在接触耦合，让耦合的双方都依赖于抽象，而不是依赖于具体，从而使得各自的变化都不会影响另一边的变化。

备忘录模式

在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保持对象的内部状态。这样以后就可将该对象恢复到原先保存的状态。

• Originator
  负责创建一个备忘录Memento，用以记录当前时刻它的内部状态，并可使用备忘录恢复内部状态。
  Originator可根据需要决定Memento存储Originator的哪些内部状态.
• Memento
  负责存储Originator对象的内部状态，并可防止Originator以外的其他对象访问备忘录Memento
  备忘录有两个接口，Caretaker只能看到备忘录的窄接口，它只能将备忘录传递给其他对象，Originator能够看到一个宽接口,允许它访问返回到先前状态所需的所有数据。
• Caretaker
  负责保存好备忘录Memento，不能对备忘录的内容进行操作或检查

Memento模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分时，Originator可以根据保存的Memento信息还原到前一状态。

如果在某个系统中使用命令模式时，需要实现命令的撤销功能，那么命令模式可以使用备忘录模式来存储可撤销操作的状态。

最大的作用在于当角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原。

中介者模式

• Colleague
  抽象同事类
• Mediator
  抽象中介者类，定义了同事对象到中介者对象的接口
• ConcreteColleague
  具体同事类，每个具体同事只知道自己的行为，而不了解其他同事类的情况，但它们都认识中介者对象
• ConcreteMediator
  具体中介者类，实现抽象类的方法，它需要知道所有具体同事类，并从具体同事接收消息，向具体同事对象发出命令

用一个中介对象来封装一系列的对象交互
中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。

命令模式

将命令封装为一个对象，使得可以用不同的请求来进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

• Invoker
  要求该命令执行这个请求
• Command
  用来声明执行操作的接口
• Receiver
  知道如何实施与执行一个与请求相关的操作，任何类都可能作为一个接收者
• ConcreteCommand
  将一个接收者对象绑定于一个动作，调用接收者相应的操作，以实现Execute。

命令模式的优点

1. 它能较容易地设计一个命令队列

2. 在需要的情况下，可以较容易地将命令记入日志

3. 允许接收请求的一方决定是否要否决请求

4. 可以容易地实现对请求的撤销和重做

5. 由于加进新的具体命令类不影响其他的类，因此增加新的具体命令很容易。

6. 命令模式把请求的一个操作和对象与知道怎么执行一个操作的对象分割开。

敏捷开发原则告诉我们，不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。

访问者模式

在不改变数据结构的前提下，增加作用于一组对象元素的新功能
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

• Visitor
  为该对象结构中的ConcreteElement的每一个类声明一个Visit操作
• ConcreteVisitor
  具体访问者,实现每个由Visitor声明的操作，每个操作实现算法的一部分，而该算法片段乃是对应于结构中对象的类
• Element
  定义一个Accept操作，它以一个访问者为参数
• ConcreteElement
  具体元素，实现Accept操作
• ObjectStructure
  ObjectStructure类，能枚举它的元素，可以提供一个高层的接口以允许访问者访问它的元素

访问者模式适用于数据结构相对稳定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化。
访问者模式的目的是要把处理从数据结装饰构分离出来。

责任链模式

将请求的发送者和接收者解耦，使得多个对象都有处理这个请求的机会

• Handler
  定义一个处理请求的接口
• ConcreteHandler
  ConcreteHandler类，具体处理者类，处理它所负责的请求，可访问它的后继者。
  如果可处理该请求，就处理之，否则就将该请求转发给它的后继者

优点：降低系统的耦合度（请求者与处理者代码分离），简化对象的相互连接，同时增强给对象指派责任的灵活性，增加新的请求处理类也很方便。
缺点：不能保证请求一定被接收，且对于比较长的职责链，请求的处理可能涉及到多个处理对象，系统性能将受到一定影响，而且在进行代码调试时不太方便。

将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

迭代器模式

一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构

当你需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，就应该考虑用迭代器模式。即需要对聚集有多种方式遍历时，可以考虑用迭代器模式。

迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代类来负责，这样既可以做到不暴露集合的内部结构，又可以让外部代码透明地访问集合内部的数据。

补充

1. 面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类

参考资料

《大话设计模式》---程杰