积木成林，聚沙成塔

中介者模式（Mediator Pattern）是一种行为型设计模式，它用于解决对象间复杂、过度耦合的问题。当多个对象（一般是两个以上的对象）之间存在复杂的相互关联和直接通信时，中介者模式通过引入一个新的中介对象来封装和集中处理这些对象间的交互逻辑，从而降低对象之间直接耦合。说的再具体一点，就是原本相互依赖的对象（通常称为同事类或者参与者）不直接相互引用，而是通过中介者对象进行交互。每个对象都将请求委托给中介者，由中介者决定如何分发这些请求以及如何协调各个对象的行为。

装饰器模式（Decorator Pattern）是一种结构型的设计模式，使用组合的方式来替代了继承，它的核心作用是在不修改对象本身的基础上动态地给一个对象添加新的职责或功能，装饰器类一般与被装饰的类有同一个父类（或父接口），其后缀名一般Decorator或者Wrapper。讲到这里，如果熟悉设计模式的同学肯定能发现，这个定义与上一篇设计模式的文章《代理模式的实现方式与使用场景》中提到了代理模式是高度类似的，事实上也确实如此，都在一定程度上对原始对象的行为进行某种形式的包裹或扩展。

享元模式（Flyweight Pattern）是一种非常常用的结构型设计模式，通过共享对象的方式，减少系统中的重复对象，提高内存使用效率。本文主要讲了享元模式的概念、使用场景以及与其他技术的对比。在使用方式上，与缓存、池化技术是高度类似的，都是创建好对象并存储起来，在后续想要使用的时候直接从存储的数据结构中获取，而不用重新创建。它与缓存、池化技术之间的区别，更多的是在于使用目的上的区别，只要能判断出，当前的对象是在通过共享对象的方式，减少系统中的重复对象，提高内存使用效率。

门面模式（Facade Pattern）又叫做外观模式，它通过为子系统提供一个统一的高层入口的方式，达到简化复杂系统的使用以及降低客户端与子系统之间的耦合度的效果，是一种很常用的设计模式。看一下门面模式的官方定义：翻译过来就是说，门面模式提供一个上层的接口，对子系统中的多个接口做一个统一的入口，让子系统能够更容易被使用。也就是说，如果你曾经对复杂的方法做过一定的封装，对客户端提供一个调用更简单的高层接口（或方法），那么你就已经使用过门面模式了。门面模式是迪米特法则。

适配器模式是一种结构型设计模式，它提供了一个中间层，通过这个中间层，客户端可以使用统一的接口与具有不同接口的类进行交互，也就是说，将一个接口转换成客户期望的另一个接口，使得原本不兼容的接口能够协同工作。举个现实中的例子，我们现在的很多轻薄笔记本为了减少厚度，一般不会设计网线的接口，或者说在笔记本上的可以插线的接口很少，这时候使用到的拓展坞就可以视为是一种适配器。值得一提的是，与其他模式有点不同的是，适配器模式是一种补偿模式，主要用于解决现有的设计或实现与需求不匹配的问题，是在系统。

本篇主要讲述的是代理模式的实现方式与使用场景，先介绍了代理模式的概念和作用，然后从静态代理开始讲述了代理模式的实现方式，其中静态代理的使用频率并不高，动态代理则相反，使用频率非常高，需要重点掌握。之所以花了一部分篇幅讲解静态代理，主要是能够直观的感受到代理模式的类结构，后续动态代理生成的代码与静态代理的也大同小异。我们在鉴权、监控、统计、日志、事务等多种场景中都可以使用动态代理模式。在使用代理模式的时候需要注意接口实现与继承实现实现方式支持代理public支持protected支持default。

简单工厂模式封装对象创建过程： 将对象的创建过程封装工厂类中，使用者无需了解具体产品的创建细节，只需调用工厂类提供的静态方法即可得到所需的产品对象。这样可以隐藏产品类的具体实现，降低耦合度。控制逻辑集中： 将复杂对象的创建对象逻辑集中在工厂类中，如果需要修改或扩展产品类型时，只需要修改工厂类中的代码。这使得添加新产品或者调整产品创建逻辑更加方便、集中管理，也有利于系统的维护和版本升级组合其他模式满足特定的需求： 在某些应用场景中，如根据参数动态选择不同类型的对象实例化，简单工厂+单例。

单例模式是设计模式中最简单的一种，对于很多人来说，单例模式也是其接触的第一种设计模式，当然，我也不例外。这种设计模式在学习、面试、工作的过程中广泛传播，相信不少人在面试时遇到过这样的问题：“说说你最熟悉的集中设计模式”，第一个脱口而出的就是单例模式。所谓的单例模式，就是在一定的作用范围内保证只有一个实例单例模式的代码如何编写？是否需要严格的禁止单例被破坏？饿汉式和懒汉式应该如何选择？单例模式存在什么问题？线程内单例和进程间单例如何实现？什么叫做“多例模式”？单例模式的编写方式。

在我刚入行不久的时候就听说过建造者模式这种设计模式，当时只知道是用来组装对象，使用起来和先new出对象再一个一个的set字段值也差不多，没有去深究这种设计模式。后来随着在业务中写的代码越来越多，同时也去查阅了一些资料，慢慢的对这两者的区别有了一点理解。于是对为什么要用建造者模式，以及相对于直接set的优劣势做一个简单的梳理。本篇描述了如何实践建造者模式，同时也聊到了为什么要使用建造者模式。简单的说，就是建造者模式提供了一种能力，让我们在自由的组装构建对象的同时，给到一定的约束。

原型模式是一种非常简单易懂的模型，在书上的定义是这样的：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。通俗的讲，就是有一个现成的对象，我们通过复制或拷贝这个对象的方式来创建一个新的对象，这就是原型模式。那么，我们为什么需要通过拷贝来创建对象呢？程序运行效率和开发效率程序运行效率：如果对象的创建和初始化的代价比较大，创建比较繁琐，例如需要从数据库、RPC、网络等获取一些数据才能完成创建，这时候使用原型模式拷贝出一个对象无疑是效率更高的做法。开发效率。

桥接模式的主流定义有两种，第一种是GoF的定义：将抽象和实现解耦，使得两者可以独立地变化。通过这句话，我们能够得到的信息是需要降低抽象和实现和依赖紧密程度，以达到两者之间可以独立扩展，互不影响的效果。在大多数情况下，抽象一般指的是接口和抽象类，实现就是实现类。在桥接模式中的抽象和实现，无所谓接口、抽象类还是实现类的差异。桥接模式抽象更多的是提供一定的约束，比如一个固定的执行流程，在这个流程中会定义出一些可以自由替换的口子，而实现就是去适配这些口子，让一个固定的执行流程可以得到不同的执行结果。

几乎在每一个系统的开发过程中，都会遇到一些**树状**结构的开发需求，例如：组织机构树，部门树，菜单树等。只要是需要开发这种树状结构的需求，我们都可以使用组合模式来完成。本篇将结合组合模式与`Mysql`实现一个部门树，完成其增删改和树形结构的组装。

状态模式一般是用在对象内部的状态流转场景中，用来实现状态机。什么是状态机呢？状态机是对状态转移的抽象，由事件状态动作组成，事件有时候也被称为转移事件或者转移，当事件触发时，可以将状态由一个状态变更为另一个状态，并执行动作。其中，事件和状态是必须存在的，动作可以不要。下面是一张状态图，表达的就是一个状态机的模型。通俗来讲，就是对状态的变更做了一定的限制，不能随意的修改状态，而是只有处于某个特定的状态时，才能变更到另一个特定的状态。

在最近的开发中遇到了这么一个需求，需要对业务流程中的各个参数做前置校验，校验通过才能执行后续的流程。经过一番需求分析后发现，有大量的业务入口需要做的校验是相同的，同时在业务迭代的过程中涉及到的校验规则也会有所增减。所以就必须考虑到代码的复用性和拓展性，决定使用责任链模式来剥离变化。本篇先简单的讲解了责任链模式的概念，通过一个简单的注册用户需求代入了责任链的实现方式，并提出了用责任链是实现校验时灵活的地方。然后针对这种不灵活，通过Java8中的Predicate。

观察者模式（Observer Pattern）是一种应用广泛的设计模式，有时候也被叫做发布/订阅模式或者监听器模式，如果你用过消息队列或者写过原生JS和JQuery中的Listener的话，对这种模式一定不陌生，接下来你会非常容易理解这种模式，如果没有使用过也没关系可以通过本文来了解一下这种模式的运用。本文中会通过大量的类图来描述观察者模式中的不同角色，对类型不太熟悉的同学可以参考者这篇文章一起看《【UML建模】类图（Class Diagram）》

模板方法是一种非常简单的设计模式，只要能够理解面向对象中的继承与多态就能够理解这种设计模式，我们可以在很多的框架源码中找到它的身影。同时在我们的日常开发中，它一般是用在同类型且不同实现方式的业务逻辑中，抽取公共逻辑，简单的说就是，模板方法经常和策略模式结合使用。《SpringBoot优雅使用策略模式》本篇文章介绍了什么是模板方法、模板方法的简单实现与在SpringBoot中的实现的。然后对比了模板方法与策略模式的类图，发现两者天然就可以结合在一起使用。最后，通过代码实现验证了两者结合使用的可行性。

本篇文章主要会描述SpringBoot与策略模式的结合使用，因为不涉及到理论部分，所以在阅读本篇之前，需要对策略模式的理论已经有了一个基本的了解。通过Spring获取接口的实现，并解析实现类上的注解的方式，可以在程序启动时动态的将策略注入到一个Map中，作为策略的容器。使用时传入标识符就可以获取到对应的策略执行了。