Java 23种设计模式

Java 23种设计模式

文 | 莫若吻

（注：以下内容是个人通过查找资料学习总结整理得出的概念性的知识，若有问题，请留言。谢谢！）

1. 设计模式

设计模式（Design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。

它是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式并不直接用来完成代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。面向对象设计模式通常以类或对象来描述其中的关系和相互作用，但不涉及用来完成应用程序的特定类或对象。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。并非所有的软件模式都是设计模式，设计模式特指软件“设计”层次上的问题。还有其它非设计模式的模式，如架构模式。同时，算法不能算是一种设计模式，因为算法主要是用来解决计算上的问题，而非设计上的问题。

2. 设计模式分类

设计模式分为创建型模式、结构型模式、行为型模式三大类，主要通过授权、聚合、诊断的概念来描述。

对象层面：处理对象之间的关系，决定于运行期。
类层面：处理类的关系，决定于在编译期。

1）创建模式：是关于如何创建实例的。用来构建对象以便能从实现系统解耦。

可以被划分为两组：类创建实例、对象创建实例。

类创建实例在实例化过程中有效的使用类之间的继承关系，对象创建实例则使用代理来完成其任务。

共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式/构造器模式、原型模式。

2）结构模式：关于类及对象复合关系的。用不同的对象组成大规模的对象结构。

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

3）行为模式：关于对象之间如何通讯的。用来在对象中管理算法、关系和责任。

共十一种：策略模式、模板方法模式、观察者模式、迭代器模式、

责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

其实还有两类：并发型模式和线程池模式（这里不作深入解析）。

3. 6大设计原则

单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则。

设计原则上需遵循这两点：第一，识别你的应用程序里不稳定的部分，并且把它们与稳定的部分隔离开。
第二，面向接口而不是面向实现编程。

Note：不要为了套用原则而做项目。

总结：

单一职责原则告诉我们实现类要职责单一；

里氏替换原则告诉我们不要破坏继承体系；

依赖倒置原则告诉我们要面向接口编程；

接口隔离原则告诉我们在设计接口的时候要精简单一；

迪米特法则告诉我们要降低耦合。

开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。

1）单一职责原则

单一职责原则：SRP（Single Responsibility Principle）。应该有且仅有一个原因引起类的变更。实际中比较不好把握，因为职责的划分没有一个统一的标准。

优点：

• 可以降低类的复杂性；
• 提高类的可读性，提高系统的可维护性；
• 降低了变更引起的风险。

Note：变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

Note：SRP适用于接口、类，也适用于方法。（即：一个接口一定要做到单一职责。一个类只负责一项职责，类的设计尽量做到只有一个原因引起变化。一个方法尽可能去做一件事。）

单一职责原则（SRP）提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异，在实际开发中可能会违背SRP。

2）里氏替换原则

里氏替换原则：LSP（Liskov Substitution Principle）。子类可以扩展父类的功能，但不能改变父类原有的功能。（简单地讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但反过来，有子类出现的地方，父类未必就能适应。）

定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义2：所有引用基类的地方必须能透明地使用其子类的对象。

LSP 优点：

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
• 提高代码的重用性；
• 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子和父的不同；
• 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，可以看到很多开源框架的扩展接口都是通过继承父类来完成的；
• 提高产品或项目的开放性；

继承的缺点：

• 继承是浸入性的。只要继承，就必须拥有父类的所有属性和方法；
• 降低代码的灵活性。子类必须拥有父类的所有属性和方法，让子类自由的世界中多了些约束；
• 增强了耦合性。当父类的常量、变量和方法被修改时，必须要考虑子类的修改，而且是在缺乏规范的环境下，这种修改可能带来非常糟糕的结果----大片代码需要重构。

Note：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。里氏替换原则可以正着用，但是不能反着用，在子类出现的地方，父类未必就可以胜任。

为了减少继承所带来的弊端，才出现了里氏替换原则。

里氏替换原则为良好的继承定义了一个规范：

• 子类必须完全实现父类的方法；（子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。）
• 子类中可以增加自己特有的方法。；
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

3）依赖倒置原则

依赖倒置原则：DIP（Dependence Inversion Principle）。高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

DIP的核心思想是面向接口编程。DIP是实现开闭原则的重要途径。

在Java语言中的表达就是，模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于实现类；实现类依赖接口或抽象类。

Note：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

传递依赖关系有三种方式：接口传递、构造方法传递和setter方法传递。（只要做到抽象依赖，即时是多层的依赖关系也无所畏惧。）

DIP在实际编程中，一般需要做到如下3点：

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 使用继承时遵循里氏替换原则。

DIP的优点：

依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

要遵循DIP，在项目开发中需要遵循的原则应该有：

• 每一个类尽量都有接口或抽象类，或者抽象类和接口两者都具备；
• 变量的表面类型尽量都是接口或是抽象类；
• 任何类都不应该从具体类派生（只要不超过两层的继承都是可以接受的，特别是负责项目维护的同志，基本上可以不考虑这个原则）；
• 尽量不要复写基类的方法
• 结合里氏替换原则使用；

Note：接口负责定义public属性和方法，并声明与其他对象的依赖关系；抽象类负责公共构造部分的实现；实现类实现业务逻辑，同时再适当时对父类进行细化。

4）接口隔离原则

接口隔离原则：ISP(Interface Segregation Principle)。

接口隔离原则是对接口进行规范约束。建立单一接口，不要建立臃肿庞大的接口，接口尽量细化，同时接口中的方法尽量少。客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 

ISP与SRP的区别：

其一，单一职责原则原注重的是职责，这是业务逻辑上的划分；而接口隔离原则注重对接口依赖的隔离，要求接口的方法尽量少。

其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。

eg：一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。

接口隔离原则是对接口进行规范约束，注意保证接口的纯洁性，如下：

• 接口要尽量小，根据接口隔离原则拆分接口时，首先必须满足单一职责原则；
• 接口要高内聚，高内聚就是提高接口、类、模块的处理能力，减少对外的交互，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本；
• 定制服务，即单独为一个个体提供优良的服务，要求只提供访问者需要的方法；
• 接口的设计是有限度的；

Note：运用接口隔离原则，一定要适度。

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。

如何划分原子？

• 一个接口只服务于一个子模块或业务逻辑。
• 通过业务逻辑压缩接口中的public方法（尽量使接口简洁）。
• 已经被污染的接口尽量去修改，若变更风险较大，则采用适配器模式进行转化处理。
• 了解环境，拒绝盲从。（尽量不copy他人代码，毕竟实际应用环境不同，逻辑不同）

5）迪米特法则

迪米特法则:LoD(Law of Demeter)，也是最小知识原则(Least Knowledge Principle)LKP。一个对象应该对其他对象有最少的了解。

迪米特法则的核心观念就是类间解耦、弱耦合，但解耦是有限度的。

理解：一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

当类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大时，尽量降低类与类之间的耦合。

LoD对类的低耦合提出了明确要求：

• 只和“朋友”交流。即：出现在成员变量、方法的输入输出参数中的类为“朋友”，而出现在方法体内部的类不属于“朋友”。
• “朋友”间也是有距离的。

一个public属性或方法越多，修改涉及面越大，变更风险扩散越大。因此在设计时需反复衡量：

是否还可以再减少public方法和属性。

是否可修改private、package-private、protected等访问权限。（package-private：包类型，在类、方法、变量前不加访问权限，则默认为包类型）

是否可加final关键字等

Note：迪米特法则要求类尽量不对外公布太多public方法和非晶态的public变量，多使用private、package-private、protected等访问权限。

• 自己就是自己的。

在实际开发中，一个方法可放在本类中，也可放在其他类中。此时坚持一个原则：如果方法放在本类中既不增加类间关系，也对本类不产生负面影响，就放在本类中。

• 谨慎使用Serializable。（情况比较少见）

eg：客户端与服务器连接，需写接口，把网络传输的对象进行序列化，否则会报NotSerializableException异常。若有一天，客户端修改了一个接口参数的访问权限，从private变为public，访问权限变大，而服务器段并没有作相应更新，就会报序列化失败。

6）开闭原则

开闭原则:OCP(Open Closed Principle)。软件实体（eg:类、模块、函数）应该对扩展开放，对修改关闭。

（即：一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。）

软件实体包括：1--项目或软件产品中按照一定的逻辑规划的模块。2--抽象和类。3--方法。

开闭原则是Java中最基础的设计原则。

解析：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

开闭原则是一个非常虚的原则，前5个原则是对开闭原则的具体解释，但开闭原则并不局限这么多。

我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则。

Note：开闭原则并不意味着不做任何修改，低层模块的变化，必然有高层模块进行耦合，否则就是一段孤立无意义的代码。

将变化归纳为三种：

• 逻辑变化。只变化一个逻辑而不涉及其他模块。
• 子模块变化。一个模块变化，会对其他模块产生影响，
• 可见视图变化。提供给客户使用的视图界面。

开闭原则的重要性：

• 开闭原则对测试有很大的影响（注：若不理解，此处可以参考《设计模式之禅》一书）。
• 提高复用性。
• 提高可维护性。
• 开闭原则是面向对象开发的要求。

开闭原则的使用：

• 抽象约束。通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放。

通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法。

参数类型、引用对象尽量使用接口或者抽象类，而不是实现类。

抽象层尽量保持稳定，一旦确定不允许修改。

• 元数据控制模块行为。

元数据：用来描述环境和数据的数据，即：配置参数。

• 制定项目章程。（即项目成员统一遵守的代码规范和约定）
• 封装变化。

将相同变化封装到一个接口或抽象类中。

将不同的变化封装到不同接口或抽象类中，不应有两个不同的变化出现在同一接口或抽象类中。

4. 23种设计模式

（注：欲知详情请点击进去查看，未贴出地址的后续都会补充完整。）

1）创建型模式

单例模式：http://blog.csdn.net/sun_promise/article/details/25536547

工厂方法模式：

抽象工厂模式：

建造者模式：

原型模式：

2）结构模式

适配器模式：

装饰模式：http://blog.csdn.net/sun_promise/article/details/33329671

代理模式：

外观模式：

桥接模式：

组合模式：

享元模式：

3）行为模式

策略模式：

模板方法模式：http://blog.csdn.net/sun_promise/article/details/25659527

观察者模式：

迭代子模式：

责任链模式：

命令模式：

备忘录模式：

状态模式：

访问者模式:

中介者模式:

解释器模式: