24种设计模式及原则简介

一、设计模式的分类

总体来说设计模式分为三大类：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、多例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

创建型模式

1. 抽象工厂模式(Abstract factory pattern)：提供一个接口，用于创建相关或依赖对象的家族，而不需要指定具体类。
2. 生成器模式(Builder pattern)：使用生成器模式封装一个产品的构造过程，并允许按步骤构造。将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
3. 工厂模式(Factory method pattern)：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到子类。
4. 原型模式(Prototype pattern)：当创建给定类的实例过程很昂贵或很复杂时，就使用原形模式。使用深拷贝或浅拷贝。
5. 单例了模式(Singleton pattern)：确保一个类只有一个实例，并提供全局访问点。
6. 多例模式(Multition pattern)：在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。

结构型模式

1. 适配器模式(Adapter pattern)：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。对象适配器使用组合，类适配器使用多重继承。该模式并不适合在软件设计初期使用。
   主要角色：
   目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。
   适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。
   适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。
2. 桥接模式(Bridge pattern)：使用桥接模式通过将实现和抽象放在两个不同的类层次中而使它们可以独立改变。业务抽象角色Abstraction的部分实现是由业务实现角色Implementor完成的。桥梁模式描述了类间弱关联关系，解决继承强关联关系带来的弊病。桥接模式中的组合线可以认为是一座桥连接抽象和实现。
   主要角色：
   抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。
   扩展抽象化（Refined    Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
   实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。
   具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。
3. 组合模式(Composite pattern)：允许你将对象组合成树形结构来表现”整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。
   主要角色：
   抽象构件（Component）角色：它的主要作用是为树叶构件和树枝构件声明公共接口，并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口；在安全式的组合模式中不声明访问和管理子类的接口，管理工作由树枝构件完成。
   树叶构件（Leaf）角色：是组合中的叶节点对象，它没有子节点，用于实现抽象构件角色中 声明的公共接口。
   树枝构件（Composite）角色：是组合中的分支节点对象，它有子节点。它实现了抽象构件角色中声明的接口，它的主要作用是存储和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法。
4. 装饰者模式(Decorator pattern)：动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
   在装饰模式中，必然有一个被提取出来最核心、最原始、最基本的接口或抽象类，设计模式就是 Component；ConcreteComponent 是最核心、最原始、最基本的接口或抽象类的实现，要装饰的就是ConcreteComponent 。Decorator 一般是一个抽象类，实现接口或者抽象方法，它里面不一定有抽象的方法，在它的属性里必然有一个 private 变量指向 Component（通过这个变量可以形成一个执行链，通过这个组合链灵活解决单一继承链问题）。装饰模式可以替代继承，解决我们类膨胀的问题。
   主要角色：
   抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。
   具体构件（Concrete    Component）角色：实现抽象构件，通过装饰角色为其添加一些职责。
   抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
   具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。
5. 外观模式(Facade pattern)：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
   主要角色：
   外观（Facade）角色：为多个子系统对外提供一个共同的接口。
   子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
   客户（Client）角色：通过一个外观角色访问各个子系统的功能。
6. 亨元模式(Flyweight Pattern)：如想让某个类的一个实例能用来提供许多”虚拟实例”，就使用蝇量模式。
   主要角色：
   抽象享元角色（Flyweight）:是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。
   具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。
   非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。
   享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。
7. 代理模式(Proxy pattern)：为另一个对象提供一个替身或占位符以控制对这个对象的访问。
   主要角色：
   抽象主题（Subject）类：通过接口或抽象类声明真实主题和代理对象实现的业务方法。
   真实主题（Real Subject）类：实现了抽象主题中的具体业务，是代理对象所代表的真实对象，是最终要引用的对象。
   代理（Proxy）类：提供了与真实主题相同的接口，其内部含有对真实主题的引用，它可以访问、控制或扩展真实主题的功能。

结构模式中很多模式设计都是为了对抗继承，使之设计更为灵活。

从UML中组合和装饰模式都使用继承和聚合方式关联各个部件，桥接模式使用到继承和组合方式，代理和适配器模式使用继承和依赖方式。

行为型模式

1. 责任链模式(Chain of responsibility pattern)：通过责任链模式，你可以为某个请求创建一个对象链。每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象。该处理方式类似递归方式把所有请求都遍历一次。
   主要角色：
   抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
   具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。
   客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。
2. 命令模式(Command pattern)：将“请求”封闭成对象，以便使用不同的请求，队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。如果命令子类非常多，会导致类膨胀（类似状态模式，需要组合这些子对象）。
   主要角色：
   抽象命令类（Command）角色：声明执行命令的接口，拥有执行命令的抽象方法 execute()。
   具体命令角色（Concrete  Command）角色：是抽象命令类的具体实现类，它拥有接收者对象，并通过调用接收者的功能来完成命令要执行的操作。
   实现者/接收者（Receiver）角色：执行命令功能的相关操作，是具体命令对象业务的真正实现者。
   调用者/请求者（Invoker）角色：是请求的发送者，它通常拥有很多的命令对象，并通过访问命令对象来执行相关请求，它不直接访问接收者。
3. 解释器模式(Interpreter pattern)：使用解释器模式为语言创建解释器。是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。
   主要角色：
   抽象表达式（Abstract Expression）角色：定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。
   终结符表达式（Terminal    Expression）角色：是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。
   非终结符表达式（Nonterminal Expression）角色：也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。
   环境（Context）角色：通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。
   客户端（Client）：主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树，然后调用解释器的解释方法，当然也可以通过环境角色间接访问解释器的解释方法。
4. 迭代器模式(Iterator pattern)：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。迭代器模式也有点没落了，基本上很少有项目再独立写迭代器了，直接使用 List 或者 Map 就可以完整的解决问题。
5. 中介者模式(Mediator pattern) ：使用中介者模式来集中相关对象之间复杂的沟通和控制方式。多个对象有依赖关系，但是依赖的行为尚不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险扩散。
   中介者模式作为调停者模式，每个类都与中介者进行交流，变成一个中心，情况也随之变的复杂。(把环形依赖变为中心式的星形关系，例如：交换机)
   主要角色：
   抽象中介者（Mediator）角色：它是中介者的接口，提供了同事对象注册与转发同事对象信息的抽象方法。
   具体中介者（ConcreteMediator）角色：实现中介者接口，定义一个 List 来管理同事对象，协调各个同事角色之间的交互关系，因此它依赖于同事角色。
   抽象同事类（Colleague）角色：定义同事类的接口，保存中介者对象，提供同事对象交互的抽象方法，实现所有相互影响的同事类的公共功能。
   具体同事类（Concrete Colleague）角色：是抽象同事类的实现者，当需要与其他同事对象交互时，由中介者对象负责后续的交互。
6. 备忘录模式(Memento pattern)：当你需要让对象返回之前的状态时(例如，你的用户请求”撤销”)，使用备忘录模式。（通过管理者拷贝当前Memento状态，实现备份，可以实现多状态或单一状态管理）
   主要角色：
   发起人（Originator）角色：记录当前时刻的内部状态信息，提供创建备忘录和恢复备忘录数据的功能，实现其他业务功能，它可以访问备忘录里的所有信息。
   备忘录（Memento）角色：负责存储发起人的内部状态，在需要的时候提供这些内部状态给发起人。
   管理者（Caretaker）角色：对备忘录进行管理，提供保存与获取备忘录的功能，但其不能对备忘录的内容进行访问与修改。
7. 观察者模式(observer pattern)：在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新。Observable 相当于生产者（添加、删除、通知观察者），Observer相当于消费者 。观察者可以实现消息的广播，一个消息可以触发多个事件。
   主要角色：
   抽象主题（Subject）角色：也叫抽象目标类，它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法，以及通知所有观察者的抽象方法。
   具体主题（Concrete    Subject）角色：也叫具体目标类，它实现抽象目标中的通知方法，当具体主题的内部状态发生改变时，通知所有注册过的观察者对象。
   抽象观察者（Observer）角色：它是一个抽象类或接口，它包含了一个更新自己的抽象方法，当接到具体主题的更改通知时被调用。
   具体观察者（Concrete Observer）角色：实现抽象观察者中定义的抽象方法，以便在得到目标的更改通知时更新自身的状态。
8. 状态模式(State pattern)：允许对象在内部状态改变时改变它的行为，对象看起来好象改了它的类。通过状态机来管理各种状态。状态模式通过Context这个类与各种状态类进行比对，最终不使用循环解决问题。
   主要角色：
   环境（Context）角色：也称为上下文，它定义了客户感兴趣的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。
   抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为。
   具体状态（Concrete    State）角色：实现抽象状态所对应的行为。
9. 策略模式(Strategy pattern)：定义了算法族，分别封闭起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
   主要角色：
   抽象策略（Strategy）类：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，环境角色使用这个接口调用不同的算法，一般使用接口或抽象类实现。
   具体策略（Concrete Strategy）类：实现了抽象策略定义的接口，提供具体的算法实现。
   环境（Context）类：持有一个策略类的引用，最终给客户端调用。
10. 模板方法模式(Template pattern)：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。JdbcTemple等都是使用模板模式实现各种操作。
11. 访问者模式(Visitor pattern)：当想要为一个对象的组合增加新的能力，且封装并不重要时，就使用访问者模式。访问者模式是对迭代器模式的扩充，可以遍历不同的对象，然后执行不同的操作，也就是针对访问的对象不同，执行不同的操作。具体访问者、抽象元素 、具体元素visitor.visit(this)、结构对象。通过该模式可以方便实现拦截器。
    （访问者内部通过重载方式对不同对象的访问，访问者关注了其他类的内部细节；具体实现类accept()方法）
    主要角色：
    抽象访问者（Visitor）角色：定义一个访问具体元素的接口，为每个具体元素类对应一个访问操作 visit() ，该操作中的参数类型标识了被访问的具体元素。
    具体访问者（ConcreteVisitor）角色：实现抽象访问者角色中声明的各个访问操作，确定访问者访问一个元素时该做什么。
    抽象元素（Element）角色：声明一个包含接受操作 accept() 的接口，被接受的访问者对象作为 accept() 方法的参数。
    具体元素（ConcreteElement）角色：实现抽象元素角色提供的 accept() 操作，其方法体通常都是 visitor.visit(this) ，另外具体元素中可能还包含本身业务逻辑的相关操作。

观察者广播链式可以 1：N 的方式广播，而责任链则要求是的 1:1 的传递，必然有一个且只有一个类完成请求的处理；
请求内容不同：观察者广播链中的信息可以在传播中改变，但是责任链中的请求是不可改变的；
处理逻辑不同：观察者广播链主要用于触发联动动作，而责任链则是对一个类型的请求按照既定的规则进行处理。

 

设计模式的六大原则

1、开闭原则（Open Close Principle）

Software entities like classes, modules and functions should be open for extension but closed for modifications. 
一个软件实体应该对扩展开放，对修改关闭。

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，通过继承重写方法实现扩展，也不是修改实现类的方法。开闭原则是最基础的一个原则，后面（单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则）都是开闭原则的具体形态，也就是说前五个原则就是指导设计的工具和方法，而开闭原则才是其精神领袖，换一个角度来理解，依照 Java 语言的称谓，开闭原则是抽象类，其他五大原则则是具体的实现类。

2、里氏代换原则（Liskov Substitution Principle）

第一个定义，最正宗的定义：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

第二个定义，functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3、依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。 

4、接口隔离原则（Interface Segregation Principle）

第一种定义: Clients should not be forced to depend upon interfaces that they don't use.

客户端不应该依赖它不需用的接口。

第二种定义：The dependency of one class to another one should depend on the smallest possible interface.

类间的依赖关系应该建立在最小的接口上。

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

迪米特法则就要求类“小气”一点，尽量不要对外公布太多的 public 方法和非静态的 public 变量，尽量内敛，多使用private、package-private、 protected 等访问权限。

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，项目管理就复杂，大家在使用的时候做相互权衡吧。

6、单一职责原则（Single Responsibility Principle）

There should never be more than one reason for a class to change。

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

单一职责原则最难划分的就是职责，一个职责一个接口，但是问题是“职责”是一个没有量化的标准，一个类到底要负责那些职责？这些职责怎么细化？细化后是否都要有一个接口或类？