Java-23种设计模式汇总+6种面向对象设计原则（SOLID）+9种职责分配原则（GRASP）（终）

前言

归纳总结是一个非常好的习惯，老话说“温故而知新”，无论是对于工作还是学习，在写了这一系列博文后确实深有感触。作为一名开发者，设计模式每天都在我们的工作中出现，但真正完整的总结一遍，才能知道自己到底理解到了什么程度。

---

一、23种设计模式

设计模式总的来说可以分为以下三类，共二十三种。之前已经陆续把每种模式单独写了一篇简单的文章，点击下面的模式可以直接访问对应的文章。

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

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

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

---

二、6种设计原则（SOLID）

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

定义：就一个类而言，应该有且仅有一个引起它的变化的原因。

软件设计真正要做的许多内容，就是发现职责并把这些职责互相分离。
如果你能想到多于一个动机去改变一个类，那这个类就具有多于一个的职责。

单一职责原则的优点：

• 类的复杂性降低，实现什么职责都有明确的定义；
• 逻辑变得简单，类的可读性提高了，而且，因为逻辑简单，代码的可维护性也提高了；
• 变更的风险降低，因为只会在单一的类中的修改。

2、开闭原则（Open Closed Principle）

定义：一个软件实体如类、模块和函数应该可以扩展，但不可以修改。

面对新需求，对程序的改动应该是通过增加代码实现的，而不是修改现有代码来实现。

开闭原则是面向对象设计的核心所在，遵循开闭原则的最好手段就是抽象。但开发人员应该仅对程序中频繁出现变化的那些部分做出抽象，如果对于应用程序中每个部分都做刻意的抽象并不是个好主意。拒绝不成熟的抽象和抽象本身一样重要。

3、里氏替换原则（Liskov Substitution Principle）

定义：子类型必须能够替换掉它们的父类型。

只有当子类可以替换掉父类，并且程序功能不受影响时，父类才可以真正的被复用，而子类也可以在父类的基础上增加新行为。

面向对象的三大特征是封装、继承和多态，三者之间却并不 “和谐“。因为继承有很多缺点，当子类继承父类时，虽然可以复用父类的代码，但是父类的属性和方法对子类都是透明的，子类可以随意修改父类的成员。如果需求变更，子类对父类的方法进行了一些复写的时候，其他的子类可能就需要随之改变，这在一定程度上就违反了封