柴毛毛大话设计模式

写在最前

本文是柴毛毛的一点经验总结，主要介绍几种在开发中使用频率较高的设计模式。

本文篇幅较长，耗时两天完成，建议各位同学挑选感兴趣的设计模式阅读。

在阅读的同时，也麻烦各位大佬多多分享！有你们的肯定，才有我继续分享的动力

如需转载，请与我联系！

人工智能看面相

最近忙里偷闲，对人工智能看面相进行了一些优化，欢迎各位大佬体验！

体验后恳请各位大佬分享朋友圈！

长按体验

基础学习：UML四种关系耦合度大小关系

泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

依赖(Dependency)

一个人(Person)可以买车(car)和房子(House)，那么就可以称：Person类依赖于Car类和House类

这里注意与下面的关联关系区分：Person类里并没有使用Car和House类型的属性，Car和House的实例是以参量的方式传入到buy()方法中。

依赖关系在Java语言中体现为局域变量、方法的形参，或者对静态方法的调用。

关联(Association）

它使一个类知道另一个类的属性和方法。

关联可以是双向的，也可以是单向的。

在Java语言中，关联关系一般使用成员变量来实现。

聚合(Aggregation)

聚合是关联关系的一种，是强的关联关系。

聚合是整体和个体之间的关系，但个体可以脱离整体而存在。

例如，汽车类与引擎类、轮胎类，以及其它的零件类之间的关系便整体和个体的关系。

与关联关系一样，聚合关系也是通过成员变量实现的。但是关联关系所涉及的两个类是处在同一层次上的，而在聚合关系中，两个类是处在不平等层次上的，一个代表整体，另一个代表部分。

组合(Composition)

组合是关联关系的一种，是比聚合关系强的关系，也以成员变量的形式出现。

在某一个时刻，部分对象只能和一个整体对象发生组合关系，由后者排他地负责生命周期。

部分和整体的生命周期一样。

整体可以将部分传递给另一个对象，这时候该部分的生命周期由新整体控制，然后旧整体可以死亡。

策略模式什么是策略模式

一个类中的一些行为，可能会随着系统的迭代而发生变化。为了使得该类满足开放-封闭原则（即：具备可扩展性 或 弹性），我们需要将这些未来会发生动态变化的行为从该类中剥离出来，并通过预测未来业务发展的方式，为这些行为抽象出共有的特征，封装在抽象类或接口中，并通过它们的实现类提供具体的行为。原本类中需要持有该抽象类/接口的引用。在使用时，将某一个具体的实现类对象注入给该类所持有的接口/抽象类的引用。

类图描述

如果类A中有两个行为X和Y会随着业务的发展而变化，那么，我们需要将这两个行为从类A中剥离出来，并形成各自的继承体系(策略体系)。每个继承体系(策略体系)的顶层父类/接口中定义共有行为的抽象函数，每个子类/实现类中定义该策略体系具体的实现。

其中，每一个被抽象出来的继承体系被称为一个策略体系，每个具体的实现类被称为策略。

此时，策略体系已经构建完成，接下来需要改造类A。

在类A中增加所需策略体系的顶层父类/接口，并向外暴露一个共有的函数action给调用者使用。

在Spring项目中，策略类和类A之间的依赖关系可以通过依赖注入来完成。

到此为止，策略模式已经构建完成，下面我们来看优缺点分析。

策略模式的优点1. 满足开放封闭原则

如果类A需要更换一种策略的时候，只需修改Spring的XML配置文件即可，其余所有的代码均不需要修改。

比如，将类A的策略X_1更换成X_2的方法如下：

此外，如果需要新增一种策略，只需要为策略接口X添加一个新的实现类即可，并覆盖其中的commonAction函数。然后按照上面的方式修改XML文件即可。

在这个过程中，在保持原有Java代码不发生变化的前提下，扩展性了新的功能，从而满足开放封闭原则。

2. 可方便地创建具有不同策略的对象

如果我们需要根据不同的策略创建多种类A的对象，那么使用策略模式就能很容易地实现这一点。

比如，我们要创建三个A类的对象，a、b、c。其中，a使用策略X_1和Y_1，b使用策略X_2和Y_2，c使用策略X_3和Y_3。

要创建这三个对象，我们只需在XML中作如下配置即可：

答疑

问：如何实现部分继承？也就是类Son1只继承Father的一部分功能，Son2继承Father的另一部分功能。

这是设计上的缺陷，当出现这种情况时，应当将父类再次拆分成2个子类，保证任何一个父类的行为和特征均是该继承体系中共有的！

问：随着需求的变化，父类中需要增加共有行为时怎么办？这就破坏了“开放封闭原则”。

这并未破坏“开放封闭原则”！在系统迭代更新的过程中，修改原有的代码是在所难免的，这并不违背“开放封闭原则”。

“开放封闭原则”要求我们：当系统在迭代过程中，第一次出现某一类型的需求时，是允许修改的；在此时，应该对系统进行修改，并进行合理地设计，以保证对该类型需求的再次修改具备可扩展性。当再一次出现该类型的需求时，就不应该修改原有代码，只允许通过扩展来满足需求。

观察者模式观察者模式是什么

如果出现如下场景需求时，就需要使用观察者模式。

如果存在一系列类，他们都需要向指定类获取指定的数据，当获取到数据后需要触发相应的业务逻辑。这种场景就可以用观察者模式来实现。

在观察者模式中，存在两种角色，分别是：观察者和被观察者。被观察者即为数据提供者。他们呈多对一的关系。

类图描述

被观察者是数据提供方，观察者是数据获取方

一个普通的类，如果要成为观察者，获取指定的数据，一共需要如下几步：

Observable：被观察者对象（数据提供方）

Object：数据本身

首先，需要实现Observer接口，并实现update函数；

然后，在该函数中定义获取数据后的业务逻辑；

update(Observable, Object)一共有两个参数：

最后，通过调用 被观察者 的addObservable()或者通过Spring的XML配置文件完成观察者向被观察者的注入。此时，该观察者对象就会被添加进 被观察者 的List中。

调用者才是真正的数据提供方。当调用者需要广播最新数据时，只需调用 被观察者 的notidyObservers()函数，该函数会遍历List集合，并依次调用每个Observer的update函数，从而完成数据的发送，并触发每个Observer收到数据后的业务逻辑。

两种注册观察者的方式

将Observer注册进Observable中有如下两种方式：

1. 运行前，通过Spring XML

在系统运行前，如果观察者数量可以确定，并在运行过程中不会发生变化，那么就可以在XML中完成对象的注入，这种方式代码将会比较简洁。

配置好所有观察者 bean

配置好 被观察者 bean，并将所有观察者bean注入给被观察者bean

2. 运行中，通过addObserver()函数

在Spring初始化的时候，通过函数将注入的中。

建议使用第一种方式初始化所有的观察者，此外，被观察者仍然需要提供函数供系统在运行期间动态地添加、删除观察者对象。

JDK提供的观察者模式工具包

JDK已经提供了观察者模式的工具包，包括和。若要实现观察者模式，直接使用这两个工具包即可。

装饰模式何时使用

需要增强一个对象中某些函数的功能。

需要动态地给一个对象增加功能，这些功能可以再动态地撤销。

需要增加 由一些基本功能排列组合 而产生的大量功能，从而使继承体系大爆炸。

类图描述

在装饰模式中的各个角色有：

抽象构件（Component）角色：给出一个抽象接口，以规范准备接收附加责任的对象。

具体构件（Concrete Component）角色：定义一个将要接收附加责任的类。

装饰（Decorator）角色：持有一个构件（Component）对象的实例，并定义一个与抽象构件接口一致的接口。

具体装饰（Concrete Decorator）角色：负责给构件对象"贴上"附加的责任。

Decorator中包含Component的成员变量，每个Concrete Decorator实现类均需要实现operation()函数，该函数大致过程如下：

使用装饰类的过程如下：

执行过程如下：

优点

Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。继承通过覆盖的方式重写需要扩展的函数，当然也可以通过获取原本的功能，然后在该功能基础上扩展新功能，但它只能增加某一项功能；如果要通过继承实现增加多种功能，那么需要多层继承多个类来实现；而Decorator模式可以在原有功能的基础上通过组合来增加新功能，这些新功能已经被封装成一个个独立的装饰类，在运行期间通过搭积木的方式选择装饰类拼凑即可。

通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

缺点

这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。

装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。

装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

设计原则

多用组合，少用继承。

利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。

单例模式

Java中单例(Singleton)模式是一种广泛使用的设计模式。单例模式的主要作用是保证在Java程序中，某个类只有一个实例存在。一些管理器和控制器常被设计成单例模式。

单例模式有很多好处，它能够避免实例对象的重复创建，不仅可以减少每次创建对象的时间开销，还可以节约内存空间；能够避免由于操作多个实例导致的逻辑错误。如果一个对象有可能贯穿整个应用程序，而且起到了全局统一管理控制的作用，那么单例模式也许是一个值得考虑的选择。

单例模式有很多种写法，大部分写法都或多或少有一些不足。下面将分别对这几种写法进行介绍。

饿汉模式

类的构造函数定义为private，保证其他类不能实例化此类；

然后提供了一个静态实例并返回给调用者；

饿汉模式在类加载的时候就对实例进行创建，实例在整个程序周期都存在

优点：只在类加载的时候创建一次实例，不会存在多个线程创建多个实例的情况，避免了多线程同步的问题。

缺点：即使这个单例没有用到也会被创建，而且在类加载之后就被创建，内存就被浪费了。

适用场景：这种实现方式适合单例占用内存比较小，在初始化时就会被用到的情况。但是，如果单例占用的内存比较大，或单例只是在某个特定场景下才会用到，使用饿汉模式就不合适了，这时候就需要用到懒汉模式进行延迟加载。

懒汉模式(存在线程安全性问题)

懒汉模式中单例是在需要的时候才去创建的，如果单例已经创建，再次调用获取接口将不会重新创建新的对象，而是直接返回之前创建的对象。

如果某个单例使用的次数少，并且创建单例消耗的资源较多，那么就需要实现单例的按需创建，这个时候使用懒汉模式就是一个不错的选择。

但是这里的懒汉模式并没有考虑线程安全问题，在多个线程可能会并发调用它的getInstance()方法，导致创建多个实例，因此需要加锁解决线程同步问题，实现如下。

懒汉模式(线程安全，但效率低)

加锁的懒汉模式看起来即解决了线程并发问题，又实现了延迟加载，然而它存在着性能问题，依然不够完美。synchronized修饰的同步方法比一般方法要慢很多，如果多次调用getInstance()，累积的性能损耗就比较大了。

懒汉模式(线程安全，效率高)

这种方式比上一种方式只多加了一行代码，那就是在synchronized之上又加了一层判断。这样当单例创建完毕后，不用每次都进入同步代码块，从而能提升效率。当然，除了初始化单例对象的线程ThreadA外，可能还存在少数线程，在ThreadA创建完单例后，刚释放锁的时候进入同步代码块，但此时有第二道判断，因此也就避免了创建多个对象。而且进入同步代码块的线程相对较少。

静态内部类(懒汉+无锁)

这种方式同样利用了类加载机制来保证只创建一个instance实例。它与饿汉模式一样，也是利用了类加载机制，因此不存在多线程并发的问题。不一样的是，它是在内部类里面去创建对象实例。这样的话，只要应用中不使用内部类，JVM就不会去加载这个单例类，也就不会创建单例对象，从而实现懒汉式的延迟加载。也就是说这种方式可以同时保证延迟加载和线程安全。

枚举

上面提到的四种实现单例的方式都有共同的缺点：

需要额外的工作来实现序列化，否则每次反序列化一个序列化的对象时都会创建一个新的实例。

可以使用反射强行调用私有构造器（如果要避免这种情况，可以修改构造器，让它在创建第二个实例的时候抛异常）。

而枚举类很好的解决了这两个问题，使用枚举除了线程安全和防止反射调用构造器之外，还提供了自动序列化机制，防止反序列化的时候创建新的对象。因此，《Effective Java》作者推荐使用的方法。不过，在实际工作中，很少看见有人这么写。

模板方法模式定义

在父类中定义算法的流程，而算法的某些无法确定的细节，通过抽象函数的形式，在子类中去实现。

也可以理解为，一套算法的某些步骤可能随着业务的发展而改变，那么我们可以将确定的步骤在父类中实现，而可变的步骤作为抽象函数让其在子类中实现。

类图描述

在模板方法模式中，父类是一个抽象类，算法的每一步都被封装成一个函数，函数将所有算法步骤串联起来。

对于不变的步骤，用修饰，防止子类重写；

对于可变的步骤，用修饰，必须要求子类重写；

子类重写完所有抽象函数后，调用即可执行算法。

外观模式

外观模式这种思想在项目中普遍存在，也极其容易理解，大家一定用过，只是没有上升到理论的层面。这里对这种思想进行介绍。

外观模式他屏蔽了系统功能实现的复杂性，向客户端提供一套极其简单的接口。客户端只需要知道接口提供什么功能，如何调用就行了，不需要管这些接口背后是如何实现的。从而使得客户端和系统之间的耦合度大大降低，客户端只需跟一套简单的Facade接口打交道即可。

适配器模式定义

作为一个基金交易平台，需要提供一套接口规范，供各个基金公司接入。然而，各个基金公司的接口各不相同，没有办法直接和平台接口对接。此时，各个基金公司需要自行实现一个适配器，适配器完成不同接口的转换工作，使得基金公司的接口和平台提供的接口对接上。

三种适配器

适配器模式有三种实现方式，下面都以基金交易平台的例子来解释。

基金公司的交易接口：

基金交易平台的交易接口

基金交易平台均通过如下代码调用各个基金公司的交易接口：

方式1：类适配器

通过继承来实现接口的转换。

基金交易适配器：

适配器继承了，因此拥有了买入和卖出的能力；适配器又实现了，因此需要实现其中的买入和卖出接口，这个过程便完成了基金公司交易接口向基金平台交易接口的转换。

使用时，只需将通过Spring注入给的即可：

方式2：对象适配器

通过组合来实现接口的转换。

基金交易适配器：

这种方式中，适配器并未继承，而是将该对象作为成员变量注入进来，一样可以达到同样的效果。

方式3：接口适配器

当存在这样一个接口，其中定义了N多的方法，而我们现在却只想使用其中的一个到几个方法，如果我们直接实现接口，那么我们要对所有的方法进行实现，哪怕我们仅仅是对不需要的方法进行置空（只写一对大括号，不做具体方法实现）也会导致这个类变得臃肿，调用也不方便，这时我们可以使用一个抽象类作为中间件，即适配器，用这个抽象类实现接口，而在抽象类中所有的方法都进行置空，那么我们在创建抽象类的继承类，而且重写我们需要使用的那几个方法即可。

目标接口：A

适配器：Adapter

实现所有函数，将所有函数先置空。

实现类：Ashili

继承适配器类，选择性地重写相应函数。

迭代器模式定义

迭代器模式用于在无需了解容器内部细节的情况下，实现容器的迭代。

容器用于存储数据，而容器的存储结构种类繁多。在不使用适配器模式的情况下，如果要迭代容器中的元素，就需要充分理解容器的存储结构。存储结构不同，导致了不同容器的迭代方式都不一样。这无疑增加了我们使用容器的成本。

而迭代器模式提出了一种迭代容器元素的新思路，迭代器规定了一组迭代容器的接口，作为容器使用者，只需会用这套迭代器即可。容器本身需要实现这套迭代器接口，并实现其中的迭代函数。也就是容器提供方在提供容器的同时，还需要提供迭代器的实现。因为容器本身是了解自己的存储结构的，由它来实现迭代函数非常合适。而我们作为容器的使用者，只需知道怎么用迭代器即可，无需了解容器内部的存储结构。

类图描述

在迭代器模式中，一共有两种角色：迭代器 和 容器

迭代器 Iterator：封装了迭代容器的接口

容器 Container：存储元素的东西

容器若要具备迭代的能力，就必须拥有函数，该函数将会返回一个

每个容器都有属于自己的，该内部类实现了接口，并实现了其中用于迭代的两个函数和

：用于判断当前容器是否还有尚未迭代完的元素

：用于获取下一个元素

代码实现

迭代器接口：

容器接口：

具体的容器（必须实现Container接口）：

具体的容器实现了接口，并实现了其中的函数，该函数用于返回该容器的迭代器对象。

容器内部需要实现自己的迭代器内部类，该内部类实现接口，并实现了其中的和函数。

当容器和容器的迭代器创建完毕后，接下来就轮到用户使用了，使用就非常简单了：

对于使用者而言，只要知道接口，就能够迭代所有不同种类的容器了。

组合模式定义

组合模式定义了树形结构的物理存储方式。

现实世界中树形结构的东西，在代码实现中，都可以用组合模式来表示。

比如：多级菜单、公司的组织结构等等。

下面就以多级菜单为例，介绍组合模式。

例子

假设我们要实现一个多级菜单，并实现多级菜单的增删改查操作。菜单如下：

菜单的特点如下：

深度不限，可以有无限级菜单

每层菜单数量不限

类图描述

表示树中的节点；

中包含两个成员变量：

：指向当前节点的父节点

：当前节点的子节点列表

这种中又包含的关系就构成了组合模式。

注意：循环引用

在构建树的过程中，可能会出现循环引用，从而在遍历树的时候可能就会出现死循环。因此，我们需要在添加节点的时候避免循环引用的出现。

我们可以在中再添加一个成员变量，用于记录根节点到当前节点的路径。该路径可以用每个节点的ID表示。一旦新加入的节点ID已经出现在当前路径中的时候，就说明出现了循环引用，此时应该给出提示。

状态模式使用场景

如果一个函数中出现大量的、复杂的if-else判断，这时候就要考虑使用状态模式了。

因为大量的if-else中往往包含了大量的业务逻辑，很有可能会随着业务的发展而变化。如果将这些业务逻辑都写死在一个类中，那么当业务逻辑发生变化的时候就需要修改这个类，从而违反了开放封闭原则。而状态模式就能很好地解决这一问题。

状态模式将每一个判断分支都封装成一个独立的类，每一个判断分支成为一种“状态”，因此每一个独立的类就成为一个“状态类”。并且由一个全局状态管理者来维护当前的状态。

类图描述

在状态模式中，每一个判断分支被成为一种状态，每一种状态，都会被封装成一个单独的状态类；

所有的状态类都有一个共同的接口——

接口中有一个，每个状态类的状态处理逻辑均在该函数中完成；必须将对象作为的参数传入。该函数的结构如下：

每个状态类的中都有且仅有一对if-else，if中填写满足条件时的业务逻辑，而else中填写不满足条件时的业务逻辑。

else中的代码都一样，有且仅有这两步：

首先将context的state设为下一个状态对象；

然后调用context的执行；

其实就是原本包含那个巨大、复杂的if-else的类。该类中持有了State对象，表示当前要执行的状态对象。

必须要有一个函数，该函数的代码都一样：

开启状态判断过程的代码如下：

优点

状态模式将原本在一个类中的庞大的if-else拆分成一个个独立的状态类。原本这个包含庞大if-else的类成为，包含了当前的状态。只需要知道起始状态类即可，不需要知道其他状态类的存在。也就是只与第一个状态类发生耦合。而每一个状态类只和下一个状态类发生耦合，从而形成一条状态判断链。状态类之间的耦合通过Spring XML文件配置。这样，当判断逻辑发生变化的时候，只需要新增状态类，并通过修改XML的方式将新的状态类插入到判断逻辑中。从而满足了开放封闭原则。

代理模式代理模式

代理模式是在不改变目标类和使用者的前提下，扩展该类的功能。

代理模式中存在『目标对象』和『代理对象』，它们必须实现相同的接口。用户直接使用代理对象，而代理对象会将用户的请求交给目标对象处理。代理对象可以对用户的请求增加额外的处理。

Java动态代理的使用

首先你得拥有一个目标对象，该对象必须要实现一个接口：

其次，为目标对象增加额外的逻辑：

自定义一个类，并实现InvocationHandler接口；

实现invoke函数，并将需要增加的逻辑写在该函数中；

创建代理对象，调用者直接使用该对象即可：