关于什么是设计模式
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。
设计模式的分类
1.创建型设计模式（提供了创建对象并隐藏创建方法的方式，而不是通过new直接创建）
工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
2.结构性模式（关注类和对象的组成）
适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
3.行为型模式（关注对象之间的通信）
策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式，中介者模式、解释器模式。
4.J2EE型设计模式（关注表示层）
MVC 模式、业务代表模式、组合实体模式、数据访问对象模式、前端控制器模式、拦截过滤器模式、服务定位器模式、传输对象模式。
设计模式的七大原则
单一职责原则
对类来说即一个类只负责一项职责，降低了类的复杂度，提高了可读性和可维护性。
开闭原则
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
里氏代换原则
任何基类可以出现的地方，子类一定可以出现。是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
依赖倒转原则
高层模块不应该依赖底层模块，两者都应该依赖其接口，抽象不应该依赖于细节，细节应该依赖抽象，依赖倒转的中心思想是面向接口编程，相对于细节的多变性，抽象更具有稳定性，在Java中抽象是指抽象类和接口，而细节就是指具体的实现类。
接口隔离原则
使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。
迪米特法则（最少知道原则）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
合成复用原则
原则是尽量使用合成/聚合的方式，而不是使用继承。
Java中的23种设计模式
创建型模式
工厂方法模式
定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

优点：

1、一个调用者想创建一个对象，只要知道其名称就可以了。

2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。

3、屏蔽产品的具体实现，调用者只关心产品的接口。

缺点：

每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。一般选用工厂模式中的静态工厂模式，将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。
抽象工厂模式
工厂方法模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？就用到抽象工厂模式，创建多个工厂类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。
单例模式
这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

优点：

1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。

2、避免对资源的多重占用（比如写文件操作）。

缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

注意事项：getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化。
建造者模式
工厂类模式提供的是创建单个类的模式，而建造者模式则是将各种产品集中起来进行管理，用来创建复合对象，所谓复合对象就是指某个类具有不同的属性。

优点：

1、建造者独立，易扩展。

2、便于控制细节风险。

缺点：

1、产品必须有共同点，范围有限制。

2、如内部变化复杂，会有很多的建造类。

使用场景：

1、需要生成的对象具有复杂的内部结构。

2、需要生成的对象内部属性本身相互依赖。

注意事项：与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
原型模式
该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。

优点：

1、性能提高。

2、逃避构造函数的约束。

缺点：

1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。

2、必须实现 Cloneable 接口。

注意事项：原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。
结构性模式
适配器模式
适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。

这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。

优点：

1、可以让任何两个没有关联的类一起运行。

2、提高了类的复用。

3、增加了类的透明度。

4、灵活性好。

缺点：

1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。

2、由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。
装饰模式
顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。

优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

缺点：多层装饰比较复杂。
代理模式
代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。

优点：

1、职责清晰。

2、高扩展性。

3、智能化。

缺点：

1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。

2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

注意事项：

1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。

2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
外观模式
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

优点：

1、减少系统相互依赖。

2、提高灵活性。

3、提高了安全性。

缺点：不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。
桥接模式
桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化，像我们常用的JDBC桥DriverManager一样，JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。

优点：

1、抽象和实现的分离。

2、优秀的扩展能力。

3、实现细节对客户透明。

缺点：桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。
组合模式
组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。

优点：

1、高层模块调用简单。

2、节点自由增加。

缺点：在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。
享元模式
主要用于减少创建对象的数量，以减少内存占用和提高性能。享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。

主要解决：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。

优点：大大减少对象的创建，降低系统的内存，使效率提高。

缺点：提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。
行为型模式
策略模式
在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。

使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。

注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。
模板模式
在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行

优点：

1、封装不变部分，扩展可变部分。

2、提取公共代码，便于维护。

3、行为由父类控制，子类实现。

缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
观察者模式
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。

优点：

1、观察者和被观察者是抽象耦合的。

2、建立一套触发机制。

缺点：

1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。

2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。

3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
迭代器模式
迭代器模式（Iterator Pattern）是 Java 和 .Net 编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。

优点：

1、它支持以不同的方式遍历一个聚合对象。

2、迭代器简化了聚合类。

3、在同一个聚合上可以有多个遍历。

4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。

缺点：由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
责任链模式
避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。

优点：

1、降低耦合度。它将请求的发送者和接收者解耦。

2、简化了对象。使得对象不需要知道链的结构。

3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。

4、增加新的请求处理类很方便。

缺点：

1、不能保证请求一定被接收。

2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。

3、可能不容易观察运行时的特征，有碍于除错。
命令模式
是一种数据驱动的设计模式，请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开

举个例子，司令员下令让士兵去干件事情，从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，传到了士兵耳朵里，士兵去执行。这个过程好在，三者相互解耦，任何一方都不用去依赖其他人，只需要做好自己的事儿就行，司令员要的是结果，不会去关注到底士兵是怎么实现的。
备忘录模式
保存一个对象的某个状态，以便在适当的时候恢复对象。所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
应用实例： 1、后悔药。 2、打游戏时的存档。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、数据库的事务管理。
状态模式
类的行为是基于它的状态改变的。允许对象在内部状态发生改变时改变它的行为，对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。
访问者模式
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。

优点：

1、符合单一职责原则。

2、优秀的扩展性。

3、灵活性。

缺点：

1、具体元素对访问者公布细节，违反了迪米特原则。

2、具体元素变更比较困难。

3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
中介者模式
中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

使用场景：

1、系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。

2、想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。
解释器模式
解释器模式（Interpreter Pattern）提供了评估语言的语法或表达式的方式，这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在 SQL 解析、符号处理引擎等。

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

注意事项：可利用场景比较少，JAVA 中如果碰到可以用 expression4J 代替。

前言
说起设计模式，我总会想起一张网络调侃图：“一个蓬头垢面、长发齐肩的男子，手持一本破书，上面赫然写着四个字——武功秘籍”。是的，设计模式就是 IT 从业者的编程秘籍，看似高深，却不神秘。
学习设计模式的过程，跟小时候背诵诗词差不多，对我们产生的影响也是润物无声的。单纯的学习某种设计模式，可能就是学一遍、忘一遍，更谈不上自如运用了。而当我们多次在 JDK 源码或者其他框架中看到它们的身影时，也许就能在某个时刻顿悟、领略其精要了。时间越久，这种顿悟的次数就越多，带给我们的心理体验也越强烈。
从 JDK 源码到主流开源框架，设计模式的应用俯拾皆是，本场 Chat 就来聊聊那些开发中常见的设计模式。
Spring 框架中的单例模式
1. 单例模式类图
艾迪生维斯理 1994 年对单例模式的描述为：
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
单例模式的静态类图如下(引自百度百科)：
2. 自定义单例模式的要点
构造函数私有化；
实例获取方法是线程安全的；
根据创建实例的时间不同，区分懒汉模式和饿汉模式。
3. Spring 作为 IOC 容器，控制着实例的创建过程
Bean 配置时，需要提供一个名为作用域的属性 scope，它决定了 Bean 的实例个数；另一个属性 lazy-init 则影响 Bean 创建的时间。每种 scope 默认的 lazy-init 也不同，概况如下：
4. 从上表可知，Spring 的单例默认是饿汉模式
实际上 Spring 实现单例的方式不是通过单例类本身来保证的，即它不需要类的构造函数为私有。Spring 通过控制实例的获取过程来保证单例对象在容器中的唯一，就是我们常见的内存缓存方案。
AbstractBeanFactory——Spring Bean 工厂的顶层抽象，它间接继承了 DefaultSingletonBeanRegistry 实现了对单例对象的管理：
单例创建的基本流程：
容器调用 Bean 工厂的 doCreateBean 获取实例；
doCreateBean 判断 beanName 的 scope 是否是单例，if(ex1.isSingleton())；
为真，则调用   DefaultSingletonBeanRegistry 类的
getSingleton(beanName,singletonFactory) 方法获取单例对象，它先判断 singletonObjects 缓存中是否有该 beanName 的实例，如果有，则返回；没有，则新建一个实例后返回，同时缓存该实例。
getSingleton 的源码为：
这里蕴含着一种内存缓存的实现思路：
将已经创建的实例缓存起来，等到需要使用的时候，直接从缓存中获取，这也是数据库连接池和线程池的基本原理。

2009 年，我在 Java 选修课上第一次听老师说起设计模式，由于当时理解能力有限，对四人帮（GOF）的入门教程也只是浅尝辄止。如今接触 Java 已经整整十年了，回头来看设计模式，发现它没其实那么神秘。从 JDK 源码，到主流开源框架，设计模式的应用俯拾皆是，“设计模式为我所用”或多或少已经成为程序员编码思维的本能了。
本文就来理一理开发中常见的设计模式：
Spring 框架中的单例模式；
单例模式在某些场景下的重要性，如：使用 Sqlite 数据库的应用；
IO 体系中的装饰模式；
随处可见的工厂模式；
Tomcat 源码中的责任链模式和模板方法模式；
AOP 编程中的代理模式；
slf4j 日志框架中的门面模式；
我的编程启示录。
阅读全文: http://gitbook.cn/gitchat/activity/5cd3f7896c7a6854ba3bdff6
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。

持续更新中…

参考：

（Java_GOF23设计模式全解） 尚学堂 百战程序员 2018 Java300集教学视频！
1. 单例模式
1.1.  静态内部类方式
public class ThreadPoolUtil {

    private ThreadPoolUtil() {
    }

    private static class Singleton {
        private static final String threadNamePrefix = "global-unique-thread-";
        private static final ThreadPoolExecutor INSTANCE = new ThreadPoolExecutor(
                Integer.parseInt(PropsUtil.sysProps.get(Constants.CORE_POOL_SIZE)),
                "0".equals(PropsUtil.sysProps.get(Constants.MAXIMUM_POOL_SIZE)) ?
                        (Runtime.getRuntime().availableProcessors() << 1) :
                        Integer.parseInt(PropsUtil.sysProps.get(Constants.MAXIMUM_POOL_SIZE)),
                Long.valueOf(PropsUtil.sysProps.get(Constants.KEEP_ALIVE_TIME)),
                TimeUnit.MILLISECONDS,
                new ArrayBlockingQueue<>(Integer.parseInt(PropsUtil.sysProps.get(Constants.ARRBLOCK_QUEUE_SIZE))),
                r -> {
                    Thread thread = new Thread(r);
                    thread.setName(threadNamePrefix + thread.getId());
                    return thread;
                });
    }

    public static ThreadPoolExecutor getInstance() {
        return Singleton.INSTANCE;
    }
}

2. 工厂模式

核心本质/思想：

实例化对象不需要new，用工厂方法代替
将选择实现类、创建对象统一管理和控制，从而将调用者和我们的实现类解耦。


2.1. 简单/静态工厂（不符合开闭原则，但常用）


思想：


实现：

公共部分的接口和类：

// 实现类对应的接口
public interface IBike {
    void name();
}

// 实例1
public class Mobai implements IBike {
    @Override
    public void name() {
        System.out.println("Mobai");
    }
}

// 实例2
public class Ofo implements IBike {
    @Override
    public void name() {
        System.out.println("ofo");
    }
}


简单工厂模式核心类：

public class BikeFactory {
    public IBike getBike(String name){
        if ("Mobai".equalsIgnoreCase(name)) {
            return new Mobai();
        } else if ("Ofo".equalsIgnoreCase(name)) {
            return new Ofo();
        } else {
            return null;
        }
    }
}


测试类：

public class Test {
    public static void main(String[] args) {
        // 简单/静态工厂模式.
        System.out.println("简单工厂：");
        BikeFactory bikeFactory = new BikeFactory();
        IBike mobai = bikeFactory.getBike("Mobai");
        mobai.name();
        IBike ofo = bikeFactory.getBike("Ofo");
        ofo.name();
        // 工厂方法模式
        System.out.println("工厂方法：");
        MobaiFactory mobaiFactory = new MobaiFactory();
        mobaiFactory.getBike().name();
        OfoFactory ofoFactory = new OfoFactory();
        ofoFactory.getBike().name();
    }
}



2.2. 工厂方法（符合开闭原则，但是会创建许多工厂类）


思想：


实现：


2.3. 抽象工厂（符合开闭原则，但是会创建许多工厂类）

思想：
实现：

3. 适配器模式

核心本质/思想：

3.1. 对象适配器
3.2. 类适配器
4. 责任链模式

核心本质/思想：