简简单单一段话描述设计模式

设计模式定义

设计模式的概念由著名建筑师Alexander提出：每个模式都描述了一个在我们周围不断发生的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次的重用那些已有的解决方案而不必再做重复性的工作。这一概念同样适用于软件开发领域。
设计模式并不是一种技术，而是特定场景下解决问题的一种方案。
在软件开发领域，设计模式（Design Pattern）是一套被反复使用，多数人知晓的，经过分类编目的，代码设计经验的总结。使用设计模式是为了可重用代码（重用性），让代码更易理解（可读性），保证代码的可靠性。

设计模式分类

根据目的，设计模式可以分为创建型(Creational)，结构型(Structural)和行为型(Behavioral):

• 创建型模式：用于创建对象
• 结构型模式：用于处理类或对象的结合
• 行为型模式：用于描述类和对象怎样交互和怎样分配职责

根据范围，设计模式可以分为类模式和对象模式：

• 类模式：处理类和子类的关系，这些关系通过继承建立，在编译时间就确定了，因此是静态的
• 对象模式：处理对象之间的关系，这些关系在运行时的可变化的，是动态的

创建型

简单工厂

就是传入一个参数，你要什么new什么

工厂模式

工厂类里面维护各个工厂，传入一个参数，根据这个参数再去找对应工厂就获取

抽象工厂

适用与产品族，有一个工厂的抽象类，定义这种工厂可以生产哪种产品，然后实现这个抽象工厂类来定义一个实际的工厂。

建造模式

和StringBuilder一样，就是应对多可选参数的场景，避免一次次指定对象set, 直接定义一个内部类Builder，这个builder内部也设置set方法，不过返回的是Builder，这样就可以链式设置了。也能不破坏原类的POJO。 就好像要建房子只要一直告诉这个工人参数就行了，不用一次次次指定房子，在修改。

单例模式：

（1）饿汉式的静态常量，（2）懒汉式的单null检查，但是有并发问题（3） 懒汉式的双null检查，这个关键点在于要对实例设置为volatile （4） 静态内部类，弄个静态内部类，实例是这个内部类的静态变量，这种也是懒汉式。（5）枚举，也能解决 （1-4）方法存在反射修改的风险。

原型模式

其实就是先弄一个初始的，这个初始的可能很耗时或者很复杂，或者是基础。然后后面的都copy这个对象，然后作为一个新对象，避免同样的初始化步骤多次进行。

使用场景

• 当一个对象的构建代价过高时。例如某个对象里面的数据需要访问数据库才能拿到，而我们却要多次构建这样的对象。
• 当构建的多个对象，均需要处于某种原始状态时，就可以先构建一个拥有此状态的原型对象，其他对象基于原型对象来修改。

结构型

适配器模式

使用场景

• 当需要使用一个现存的类，但它提供的接口与我们系统的接口不兼容，而我们还不能修改它时
• 当多个团队独立开发系统的各功能模块，然后组合在一起，但由于某些原因事先不能确定接口时。（别和我说这不可能，这太tm可能了）

哈哈，没有什么问题是加一层不能解决的。我的入参是InterfaceA, 但是人家的入参是ClassB， 或者我现在用的InterfaceA, 但是我现在想换成ClassB， 要是直接改就很复杂，此时可以用到适配器模式， 我创建一个实现了InterfaceA的适配器类ClassA， 这个ClassA里面维护了一个我要用的ClassB的对象(无论是构造时传入还是后面赋值)，然后ClassA的实现就是调用ClassB的相关内容，这样我改所有InterfaceA的地方时，只需要将原来的实例类型换成ClassB的类型就完事了。

桥接模式

一个最终产品有多重变化维度。如果每种规格都建立一个类的话，那就会有 xyz个类，此时我们可以选择一个作为最终产品维度，然后这个最终产品构造时需要穿越其他规格维度的抽象类，如我选择x作为最终产品类，然后x的构造函数包括y和z规格的抽象类，这样我只需要x+y+z个类就能实现多个维度规格的最终产品，后面某个维度扩展新的规格，也只需要在对应维度增加一个类就行。

组合模式

组合模式主要应对层级关系，设计一个接口代表层级和层级应该有的方法属性，然后叶子节点实现这个接口， 非叶子节点在实现这个接口的同时，新增一个其拥有的子节点属性。 这时我们拿到任意一个这个接口的实现，就能获得他和他所有的子节点的信息。类似递归的概念。

装饰者模式

我定义一个接口，然后实现初始类， 然后装饰者类也实现这个接口，装饰者类的构造方法需要传入这个接口的实例，这样一层层的装饰下去，每一层因为实现了初始接口，所以提供的功能都一致，然后可以通过不断的叠加不同的装饰者类来不断的增强功能。

代理模式

静态代理和适配器模式类似，代理类负责和外部交互，代理类内部维护一个别代理的对象，不同的是代理类和被代理类实现的同一个接口，也就是对外部来说，面向的接口并没有改变。适配器模式则不同，适配器模式是将目标类和适配器类不是同一接口，目的就是将一个接口转成另外一个接口对外输出功能。
动态代理的话是动态的实现代理模式，比如通过InvocationHandler接口，更灵活 ，更有通用性。可以在运行期间动态获得代理对象。

public class DynProxyLawyer implements InvocationHandler {
    private Object target;//被代理的对象
    public DynProxyLawyer(Object obj){
        this.target=obj;
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
	    System.out.println("案件进展："+method.getName());
        Object result=method.invoke(target,args);
        return result;
    }
}

• JDK动态代理是基于接口的实现（不能针对于类），实现接口中的方法 C
• GLIB动态代理是基于类的扩展，为目标类生成一个子类，重写父类的方法。唯一需要注意的是，CGLib不能对声明为final的方法进行代理，因为CGLib原理是动态生成被代理类的子类，这种比较常用

第一段说的是代理模式，侧重于不能直接访问一个对象，只能通过代理来间接访问，比如对象在另外一台机器上，或者对象被持久化了，对象是受保护的。对象在另外一台机器上，其实就是rpc，感兴趣的可以看看dubbo的源码本地反问的其实就是远程对象的代理，只不过代理帮你做了访问这个对象之前和之后的很多事情，但是对使用者是透明的了。对象被持久化了，比如mybatis的mapperProxy。通过mapper文件自动生成代理类。第三种，对内核对象的访问。
第二段说的是装饰器模式是因为没法在编译器就确定一个对象的功能，需要运行时动态的给对象添加职责，所以只能把对象的功能拆成一一个个的小部分，动态组装，感兴趣的可以看看dubbo的源码，里面的mock，cluster，failover都是通过装饰器来实现的。因为这些功能是由使用者动态配置的。但是代理模式在编译器其实就已经确定了和代理对象的关系。
第三段说的是，这个两个设计模式是为了解决不同的问题而抽象总结出来的。是可以混用的。可以在代理的基础上在加一个装饰，也可以在装饰器的基础上在加一个代理。感兴趣的去看看dubbo源码，里面就是这么实现的。
作者：海岸红杉 链接：https://www.zhihu.com/question/41988550/answer/567925484
来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

外观模式

就相当于市面上的支付SDK有很多，而你加了一层，做了一个通过的SDK供给外部调用，各个公司可以通过你这个SDK来完成任意一个支付SDK的调用。
移动广告最开始发展时，市面上做移动广告的少说也有几十上百家，关键是由于没有决出行业龙头，好多家实力差不多，用户就面临要一个一个接入这些广告sdk的尴尬，那如果此时有一家公司出个统一的SDK聚合一下这些商家，用户只需要与这一家对接多好。
或者是一个功能要调用N多个API，你就加一层，让他仅仅需要一个API就行。
这就是外观模式。提供一个统一的面板，来让外部调用外部无需关注内部复杂的逻辑或者多个API接口的调用。

享元模式

定义为允许使用共享对象来有效的支持大量细粒度对象。其实就是对象的重复使用，将对象内的属性分为内部和外部两个状态，仅仅提供修改外部状态的方法，同时针对每一种内部状态，我都创建一个对象(工厂懒模式)，用完之后缓存起来，下次用时直接取出缓存的这个对象，然后修改外部状态，就能作为一个新的对象用，而无需每次使用都需要重新创建一个对象。

行为型

责任链模式

依然是一个链式的反应，定义一个包含处理方法的接口，然后分别建立几个实现这个接口的处理类，这些处理类不仅包含自己的处理逻辑，还需要维护一个下一任处理类的实例，如果入参能自己处理，那就自己处理，否则交给下一任处理，这样就就构成了一个责任链，调用方仅需要和最外层的接口交互就能得到结果。类似于递归。要注意的是一定要注意不要搞成一个闭环，不然就是死循环了，同时在最后一个环节，如果依然不符合场景要做一个兜底的出口。

命令模式

命令模式就是建立一个命令调用类，这类里面维护着一个命令列表。然后调用者可以一次性执行所有的命令，类似于Redis的事务那样。命令列表的类型是一个接口，这样就可以放入多种命令，每种命令的构造方法可以传入命令执行方，这样只需定义n个命令，m个角色，就能有m*n种类型。要记得面向接口编程，所以命令列表是一个接口，可以容纳各种角色执行各种命令，而不是面向实现编程。

迭代器模式

迭代器模式就真的的迭代器，就是你创建了一个容器类，此时提供了一个方法来让调用方能迭代获取所有的元素，而不用暴露我容器内部的细节给外部自己做迭代，也避免了外部的修改。现在实现迭代器模式很简单，直接实现Iterator接口就行。

备忘录模式

备忘录模式顾名思义，就是将一个类的对象状态记录下来，并且这个类能够根据记录下来的对象恢复到存档点。 要记录状态，我们就需要一个纸张类，这类存着一个类的具体状态，备忘录嘛，自然不会只能存一个数据，因此备忘录类维护了一个容器，用来记录各种各样的纸张。存档时间就生成一个纸张，然后交给备忘录类存到容器内，读档之后就根据标识去备忘录类拿到目标纸张，然后传给实例类，实例类根据这个纸张复原状态。

策略模式

策略模式主要针对于一个操作有很多分支，如果单靠if-else就会很复杂，而且如果新增分支还要改动，不符合对修改关闭的原则，此时就可以使用策略模式，定义一个策略接口，然后不同的分支分别实现这个策略接口。此时这个多分支的操作方法入参就可以定义为策略接口和策略执行参数，执行时传入具体的策略实现类，方法内部调用策略的执行方法就行。此时如果需要新的分支，也仅仅需要新增一个策略实现。

状态模式

状态模式和策略模式几乎一样，定义一个状态动作接口，不同的状态都实现这个接口产生实现类，执行动作组件维护着当前状态，在执行动作时直接调用当前的动作组件就行了，改变动作状态时传给动作组件新的状态实现实例就行。和策略模式不同的是，策略模式做的都是同一件事，状态模式不同状态下做的事情不同。而且状态模式状态执行类会维护着当前状态，可重用，策略模式只是根据入参策略去执行一个动作。

模板方法模式

模板方法一般应用于一个动作有很多种实现，但是这些实现步骤都大同小异。
模板方法模式在日常开发中肯定常用，其做法就是定义一个abstract类，然后定义一个final方法定义完成某动作的流程避免被重写，流程的每一步都被定义为abstract方法，这样我要实现一个流程，只需要基础这个模板类，然后实现那些不同的步骤就行。为了避免实现上的细微差别，一般还会定义一个钩子方法，这个钩子方法是空方法体，如果哪个实现有不一样的，就可以Override这个方法来做这些差异化。abstractDisptcher就是这样的。

访问者模式

用于我有一个模块，这个模块内的成员一般不会改变，但是我这个模块所作的动作可能会成体系改变。就像有一个家庭，家庭成员一般不会改变，如果有人作为访问者来这一家走亲戚，每个人对于访问者的称呼随着访问者的不同整体的改变。怎么做到访问者呢？首先我得定义一个家庭成员的接口，这个接口定义了一个动作即接受访问accept方法，入参是访问者接口，然后各个家庭成员如父亲，母亲，儿女实现这个方法，但是方法实现内部不是一番if-else,而是访问者访问自己的动作即visitor.visit(this)。接下来我们创建一个家庭类，这个家庭类内部维护了父亲类，母亲类，儿女类的实现，然后定义一个访问方法，访问方法入参是访问者，内部实现就是家庭成员循环接受访问者访问，那么访问者接口是怎么样的呢？访问者接口定义了分别拜访不同人员时的动作，比如拜访父亲的动作，拜访母亲的动作，拜访儿女的动作。接下来就可以创建了一个具体的访问者，比如外婆类，那外部类就要实现拜访母亲的动作，母亲要喊外婆母亲，父亲要喊丈母娘，儿女要喊外婆，也就是具体的称呼实现放到了这个类里面统一管理了，而不是再家庭类各种if-else。此时我实例化一个家庭，然后再实例化一个外婆类，外婆类通过家庭的接受访问方法访问这个家庭，就能得到所有家庭成员的打招呼，如果有其它人访问，那么只需要实现访问者接口，然后维护各个家庭人员该叫自己什么，就能整体的改变一个家庭对新访问者的称呼。

解释器模式

一种设计模式。定义了一个解释器，来解释给定语言和文法的句子。其实质是把语言中的每个符号定义成一个（对象）类，从而把每个程序转换成一个具体的对象树。。。。。。。

中介模式

中介模式常用于多个对象之间相互关联的网状结构场景，如果每个对象都维护着关联对象势必会导致关系十分复杂，此时可以创建一个中介类，中介类持有关联对象，并定义关联关系，这样一个对象要做什么动作时，他自己不需要一一通知关联对象，只需要告诉中介就行了。

观察者模式

观察者用于一个对象改变状态，需要通知其它对象的场景。定义一个观察者对象，这个对象含有接收通知的方法，然后定义一个被观察者，被观察者维护着观察对象的实例，如果被观察对象发生变动，就循环通知观察者。和中介者不同的是，中介可以是多个，传入不同的不同的中介就有不同的效果，而观察者仅仅是一个通知。