Java设计模式

一、设计模式遵循的原则及说明

好的设计模式能解决代码重用性、提高可读性、可扩展性、可靠性、使程序高内聚低耦合

1.1、单一职责原则

单一职责原则的定义是：应该有且仅有一个原因引起类的变更。

对类来说：A类有两个方法 a1和a2，当a1变化时有可能引起a2出现问题，单一职责原则是将A的粒度分为A1和A2两个来做、

我们以打电话为例，电话通话的时候有 4 个过程发生：拨号、通话、回应、挂机。那我们写一个接口，类图如下：

代码为：

我们看这个接口有没有问题？相信大部分同学会觉得没问题，因为平常我们就是这么写的。没错，这个接口接近于完美，注意，是“接近”。单一职责原则要求一个接口或一个类只能有一个原因引起变化，也就是一个接口或者类只能有一个职责，它就负责一件事情，看看上面的接口只负责一件事情吗？明显不是。

IPhone这个接口包含了两个职责：协议管理和数据传送。dial 和 hangup 这两个方法实现的是协议管理，分别负责拨号接通和挂机，chat 方法实现的是数据传送。不管是协议接通的变化还是输出传送的变化，都会引起这个接口的变化。所以，IPhone这个接口并不符合单一职责原则。若要让IPhone满足单一职责原则，我们就要对其进行拆分，拆分后的类图如下：

这样设计就完美了，一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化了啊，是的，但是别忘了我们是面向接口编程，我们对外公布的是接口而不是实现类。

另外，单一职责原则不仅适用于接口和类，也适用于方法。一个方法尽可能只做一件事，比如一个修改用户密码的方法，不要把这个方法放到“修改用户信息”方法中。

单一职责的好处

1. 类的复杂性降低，实现什么职责都有清晰明确的定义；

2. 可读性高，复杂性降低，可读性自然就提高了；

3. 可维护性提高，可读性提高了，那自然更容易维护了；

4. 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

1.2、接口隔离原则

客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。

使用场合,提供调用者需要的方法,屏蔽不需要的方法.满足接口隔离原则.比如说电子商务的系统,有订单这个类,有三个地方会使用到,

一个是用户,只能有查询方法,

一个是外部系统,有添加订单的方法,

一个是管理后台,添加删除修改查询都要用到.

根据接口隔离原则(ISP),一个类对另外一个类的依赖性应当是建立在最小的接口上.

也就是说,对于用户,它只能依赖有一个查询方法的接口.

UML结构如下:

接口隔离原则

下面是实现的代码.

//--这儿不用接口继承,因为可能出现修改了父接口影响了子接口

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

interface IOrderForPortal{     String getOrder(); } interface IOrderForOtherSys{     String insertOrder();     String getOrder(); } interface IOrderForAdmin{ //extendsIOrderForPortal,IOrderForOtherSys     String deleteOrder();     String updateOrder();     String insertOrder();     String getOrder(); } /* interface IOrderForPortal{     String getOrder(); } interface IOrderForOtherSys{     String insertOrder(); } interface IOrderForAdmin extendsIOrderForPortal,IOrderForOtherSys{     String updateOrder();     String deleteOrder(); } */ class Order implements IOrderForPortal,IOrderForOtherSys,IOrderForAdmin{     private Order(){         //--什么都不干,就是为了不让直接 new,防止客户端直接New,然后访问它不需要的方法.     }     //返回给Portal     public static IOrderForPortal getOrderForPortal(){         return (IOrderForPortal)new Order();     }     //返回给OtherSys     public static IOrderForOtherSys getOrderForOtherSys(){         return (IOrderForOtherSys)new Order();     }     //返回给Admin     public static IOrderForAdmin getOrderForAdmin(){         return (IOrderForAdmin)new Order();     }     //--下面是接口方法的实现.只是返回了一个String用于演示     public String getOrder(){         return "implemented getOrder";     }     public String insertOrder(){         return "implemented insertOrder";     }     public String updateOrder(){         return "implemented updateOrder";     }     public String deleteOrder(){         return "implemented deleteOrder";     } } public class TestCreateLimit{     public static void main(String[] args){         IOrderForPortal orderForPortal =Order.getOrderForPortal();         IOrderForOtherSys orderForOtherSys =Order.getOrderForOtherSys();         IOrderForAdmin orderForAdmin = Order.getOrderForAdmin();         System.out.println("Portal门户调用方法:"+orderForPortal.getOrder());         System.out.println("OtherSys外部系统调用方法:"+orderForOtherSys.insertOrder());         System.out.println("Admin管理后台调用方法:"+orderForAdmin.getOrder()+";"+orderForAdmin.insertOrder()+";"+orderForAdmin.updateOrder()+";"+orderForAdmin.deleteOrder());     } }

这样就能很好的满足接口隔离原则了,调用者只能访问它自己的方法,不能访问到不应该访问的方法. 

1.3、依赖倒转原则

依赖倒置原则在Java语言中的表现是：

1. 模块间的依赖通过抽象发生，实现类之间不直接发生依赖关系，其依赖关系是通过接口或抽象类产生的；

2. 接口或抽象类不依赖于实现类；

3. 实现类依赖接口或抽象类。

说白了，就是“面向接口编程”。

依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

我们以汽车和司机举例，画出类图：

奔驰车源代码：

司机源代码：

客户端源代码：

通过以上的代码，完成了司机开动奔驰车的场景。可以看到，这个场景并没有引用依赖倒置原则，司机Driver类直接依赖奔驰车Benz类，这样会有什么隐患呢？试想，后期业务变动，司机又买了一辆宝马车，源代码如下：

由于司机现在只有开奔驰的方法，所以他是开不了宝马的。一个拿有C驾照的司机能开奔驰，不能开宝马？太不合理了。所以，这就暴露出上面的设计问题了。我们对上面的功能重新设计，首先新建两个接口。

汽车接口ICar：

司机接口IDriver：

IDriver中，通过传入ICar接口实现了抽象之间的依赖关系。

接下来创建汽车实现类：奔驰和宝马。

然后创建司机实现类：

最后是场景类调用：

Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，driver的表面类型是IDriver，benz的表面类型是ICar。

依赖倒置原则的使用建议：

（1）每个类尽量都有接口或抽象类，或者接口和抽象类两者都具备。

（2）变量的表面类型尽量是接口或抽象类。

（3）任何类都不应该从具体类派生。

（4）尽量不要重写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要重写。

（5）结合里氏替换原则使用。

1.4、里氏替换原则

在面向对象的语言中，继承是必不可少的、非常优秀的语言机制，它有如下优点：

代码共享，减少创建类的工作量，每个子类都拥有父类的属性和方法；提高代码的重用性；子类可以形似父类，但又异于父类；提高代码的可扩展性；提高产品或项目的开放性。有优点就必然存在缺点：

继承是侵入性的。只要继承，就必须拥有父类的属性和方法。降低代码的灵活性。子类会多一些父类的约束。增强了耦合性。当父类的常量、变量、方法被修改时，需要考虑子类的修改。为了让“利”的因素发挥最大的作用，同时减少“弊”带来的麻烦，引入了里氏替换原则（LSP）。

如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代替o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。

通俗点讲，就是只要父类能出现的地方，子类就可以出现，而且替换为子类也不会产生任何错误或异常。

里氏替换原则为良好的继承定义了一个规范，一句简单的定义包含了4层含义。

1. 子类必须完全实现父类的方法。

我们在做系统设计的时候，经常会定义一个接口或抽象类，然后编码实现，调用类则直接传入接口或抽象类，其实这里就已经使用了里氏替换原则。我们以打CS举例，来描述一下里面用到的枪。类图如下：

枪的主要职责是射击，如何射击在各个具体的子类中实现，在士兵类Soldier中定义了一个方法 killEnemy，使用枪来kill敌人，具体用什么枪，调用的时候才知道。

AbstractGun类源码如下：

手枪、步枪、机枪的实现类代码如下：

士兵类的源码为：

注意，士兵类的killEnemy方法中使用的gun是抽象的，具体时间什么枪需要由客户端（Client）调用Soldier的构造方法传参确定。

客户端Client源码如下：

注意：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。

2. 孩子类可以有自己的个性。

孩子类当然可以有自己的属性和方法了，也正因如此，在子类出现的地方，父类未必就可以代替。

还是以上面的关于枪支的例子为例，步枪有 AK47、SKS狙击步枪等型号，把这两个型号的枪引入后的Rifle的子类图如下：

SKS狙击步枪可以配一个8倍镜进行远程瞄准，相对于父类步枪，这就是SKS的个性。源码如下：

狙击手Spinner类的源码如下：

狙击手因为只能使用狙击枪，所以，狙击手类中持有的枪只能是狙击类型的，如果换成父类步枪Rifle，则传递进来的可能就不是狙击枪，而是AK47了，而AK47是没有zoomOut方法的，所以肯定是不行的。这也验证了里氏替换原则的那一句话：有子类出现的地方，父类未必就可以代替。

3. 覆盖或实现父类的方法时，输入参数可以被放大。

来看一个例子，我们先定义一个Father类：

然后定义一个子类：

子类方法与父类方法同名，但又不是覆写父类的方法。你加个@Override看看，会报错的。像这种方法名相同，方法参数不同，叫做方法的重载。你可能会有疑问：重载不是只能在当前类内部重载吗？因为Son继承了Father，Son就有了Father的所有属性和方法，自然就有了Father的doSomething这个方法，所以，这里就构成了重载。

接下来看场景类：

根据里氏替换原则，父类出现的地方子类就可以出现，我们把上面的父类替换为子类：

我们发现运行结果是一样的。为什么会这样呢？因为子类Son继承了Father，就拥有了doSomething(HashMap map)这个方法，不过由于Son没有重写这个方法，当调用Son的这个方法的时候，就会自动调用其父类的这个方法。所以两次的结果是一致的。

举个反例，如果父类的输入参数类型大于子类的输入参数类型，会出现什么问题呢？我们直接看代码执行结果即可轻松看出问题：

扩大父类方法入参：

缩小子类方法入参：

场景类：

根据里氏替换原则，有父类的地方就可以有子类，我们把Father替换为Son看看结果：

两次运行结果不一致，违反了里氏替换原则，所以子类中方法的入参类型必须与父类中被覆写的方法的入参类型相同或更宽松。

4. 覆盖或实现父类的方法时，输出结果可以被缩小。

这句话的意思就是，父类的一个方法的返回值是类型T，子类的相同方法（重载或重写）的返回值为类型S，那么里氏替换原则就要求S必须小于等于T。为什么呢？因为重写父类方法，父类和子类的同名方法的输入参数是相同的，两个方法的范围值S小于等于T，这时重写父类方法的要求。

1.5、开闭原则

开闭原则是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。也就是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。我们以书店销售书籍为例来说明什么是开闭原则。

其类图如下：

书籍及其实现类代码如下：

书店类代码：

项目开发完了，开始正常卖书了。假如到了双十一，要搞打折活动，上面的功能是不支持的，所以需要修改程序。有三种方法可以解决这个问题：

（1）修改接口

在IBook接口里新增getOffPrice()方法，专门用于进行打折，所有的实现类都实现该方法。但这样修改的后果就是，实现类NovelBook要修改，书店类BookStore中的main方法也要修改，同时，IBook作为接口应该是稳定且可靠的，不应该经常发生变化，因此，该方案被否定。

（2）修改实现类

修改NovelBook类中的方法，直接在getPrice()方法中实现打折处理，这个方法可以是可以，但如果采购书籍的人员要看价格怎么办，由于该方法已经进行了打折处理，因此采购人员看到的也是打折后的价格，会因信息不对称出现决策失误的情况。因此，该方案也不是一个最优的方案。

（3）通过扩展实现变化

增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是BookStore中static静态块中）通过OffNovelBook类产生新的对象，完成业务变化对系统的最小开发。这样修改也少，风险也小，修改后的类图如下：

OffNovelBook源码如下：

然后修改BookStore中的书籍类为OffNovelBook：

为什么要用开闭原则

1. 开闭原则非常著名，只要是做面向对象编程的，在开发时都会提及开闭原则。

2. 开闭原则是最基础的一个原则，前面介绍的5个原则都是开闭原则的具体形态，而开闭原则才是其精神领袖。

3. 开闭原则提高了复用性，以及可维护性。

1.6、迪米特法则

迪米特法则（LoD）也叫最少知道法则：一个对象应该对其他对象有最少的了解。

1.只和朋友交流

迪米特法则还有一个英文解释是：Only talk to your immediate friends(只和直接的朋友交流)。每个对象都必然会与其他对象耦合，两个对象的耦合就成为朋友关系。下面我们通过体育课老师让班长清点女生人数为例讲解。

首先设计程序的类图：

编码实现：

程序开发完了，我们首先看下Teacher类有几个朋友类，首先要知道朋友类的定义：出现在成员变量、方法的输入输出参数中的类称为成员朋友类。所以Teacher类只有一个GroupLeader朋友类。根据迪米特法则，一个类只能和朋友类交流，上面的Teacher类内部却与非朋友类Girl发生了交流，这就不符合迪米特法则，破坏了程序的健壮性。

我们对类图做下修改：

修改后的代码：

再看场景类调用：

总之，就是类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象。

2.朋友间也是有距离的

我们在开发中经常有这种场景：调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果再看是否执行第三个方法。我们以安装某个软件为例，其类图为：

代码如下：

程序很简单，但也存在一些问题：Wizard类把太多方法暴露给InstallSoftware类了，两者的朋友关系太亲密了，耦合关系变的异常牢固，如果要把Wizard中first方法的返回值改为Boolean类型，则要同时修改InstallSoftware类，增加了风险。因此，这种耦合是不合适的，我们需要对其优化。重构后的类图如下：

代码如下。导向类：

我们把安装步骤改为私有方法，只向外暴露一个安装方法，这样，即使修改步骤的逻辑，也只是对Wizard自己有影响，只需要修改自己的安装方法逻辑即可，其他类不会受到影响。

安装类：

一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。所以，我们开发中尽量不要对外公布太多public方法和非静态的public变量，尽量内敛。

3.是自己的就是自己的

在实际开发中经常会出现这样一种情况：一个方法放在吧本类中也可以，放在其他类中也没有错。那这时，我们只需要坚持一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

总之，迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提升上去。

1.7、合成复用原则

合成复用原则又称为组合/聚合复用原则(Composition/Aggregate Reuse Principle, CARP)，其定 义如下：

合成复用原则(Composite Reuse Principle, CRP)：尽量使用对象组合，而不是继承来达到复 用的目的。

合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些 已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能 的目的。简言之：复用时要尽量使用组合/聚合关系（关联关系），少用继承。

在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合/ 聚合关系或通过继承，但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低 类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使 用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂 度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继 承复用。

通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实 现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白 箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是 静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用 （如类没有声明为不能被继承）。

一般而言，如果两个类之间是“Has-A”的关系应使用组合或聚合，如果是“Is-A”关系可使用继 承。"Is-A"是严格的分类学意义上的定义，意思是一个类是另一个类的"一种"；而"Has-A"则不 同，它表示某一个角色具有某一项责任。

下面通过一个简单实例来加深对合成复用原则的理解：

Sunny软件公司开发人员在初期的CRM系统设计中，考虑到客户数量不多，系统采用MySQL 作为数据库，与数据库操作有关的类如CustomerDAO类等都需要连接数据库，连接数据库的 方法getConnection()封装在DBUtil类中，由于需要重用DBUtil类的getConnection()方法，设计人 员将CustomerDAO作为DBUtil类的子类，初始设计方案结构如图1所示：

 

图1 初始设计方案结构图

 

随着客户数量的增加，系统决定升级为Oracle数据库，因此需要增加一个新的OracleDBUtil类 来连接Oracle数据库，由于在初始设计方案中CustomerDAO和DBUtil之间是继承关系，因此在 更换数据库连接方式时需要修改CustomerDAO类的源代码，将CustomerDAO作为OracleDBUtil 的子类，这将违反开闭原则。【当然也可以修改DBUtil类的源代码，同样会违反开闭原 则。】

现使用合成复用原则对其进行重构。

根据合成复用原则，我们在实现复用时应该多用关联，少用继承。因此在本实例中我们可以 使用关联复用来取代继承复用，重构后的结构如图2所示：

图2 重构后的结构图

在图2中，CustomerDAO和DBUtil之间的关系由继承关系变为关联关系，采用依赖注入的方式 将DBUtil对象注入到CustomerDAO中，可以使用构造注入，也可以使用Setter注入。如果需要 对DBUtil的功能进行扩展，可以通过其子类来实现，如通过子类OracleDBUtil来连接Oracle数 据库。由于CustomerDAO针对DBUtil编程，根据里氏代换原则，DBUtil子类的对象可以覆盖 DBUtil对象，只需在CustomerDAO中注入子类对象即可使用子类所扩展的方法。例如在 CustomerDAO中注入OracleDBUtil对象，即可实现Oracle数据库连接，原有代码无须进行修改，而且还可以很灵活地增加新的数据库连接方式。

以汽车分类管理程序为例：

分析:汽车按“动力源"划分可分为汽油汽车、电动汽车等;按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这这两种分类，其组合就很多。

具体代码：

package CRP;

public interface Color {
    public String color();
}

package CRP;

public class White implements Color {
    @Override
    public String color() {
        return "白色";
    }
}

package CRP;

public class Black implements Color {
    @Override
    public String color() {
        return "黑色";
    }
}

package CRP;

public class Red implements Color {
    @Override
    public String color() {
        return "红色";
    }
}

package CRP;

//汽车
public class Car {
    protected Color color;

    public Car(Color color){
        this.color = color;
    }

    public void move(){
        System.out.println(color.color() + "汽车移动");
    }
}

package CRP;

public class GasolineCar extends Car{
    protected Color color;

    public GasolineCar(Color color) {
        super(color);
    }

    @Override
    public void move() {
        System.out.println(color.color() + "汽油汽车移动");
    }
}

package CRP;

public class ElectricCar extends Car {

    public ElectricCar(Color color) {
        super(color);
    }

    @Override
    public void move() {
        System.out.println(color.color() + "电动汽车移动");
    }
}

package CRP;

public class CRPTest {
    public static void main(String[] args) {
        White white = new White();
        Black black = new Black();
        Red red = new Red();

        Car car1 = new GasolineCar(white);
        Car car2 = new GasolineCar(black);
        Car car3 = new GasolineCar(red);
        Car car4 = new ElectricCar(white);
        Car car5 = new ElectricCar(black);
        Car car6 = new ElectricCar(red);
        car1.move();
        car2.move();
        car3.move();
        car4.move();
        car5.move();
        car6.move();

    }
}

运行结果：

 UML

统一建模语言（Unified Modeling Language，UML）是用来设计软件的可视化建模语言。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。

UML 从目标系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图、部署图等 9 种图。

一、类图概述

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。

二、类图的作用

在软件工程中，类图是一种静态的结构图，描述了系统的类的集合，类的属性和类之间的关系，可以简化了人们对系统的理解；

类图是系统分析和设计阶段的重要产物，是系统编码和测试的重要模型。

三、类图表示法

1.类的表示方式

在UML类图中，类使用包含类名、属性(field) 和方法(method) 且带有分割线的矩形来表示，比如下图表示一个Employee类，它包含name,age和address这3个属性，以及work()方法。

属性/方法名称前加的加号和减号表示了这个属性/方法的可见性，UML类图中表示可见性的符号有三种：

+：表示public

-：表示private

：表示protected
属性的完整表示方式是： 可见性 名称 ：类型 [ = 缺省值]

方法的完整表示方式是： 可见性 名称(参数列表) [ ： 返回类型]

注意：

​ 1，中括号中的内容表示是可选的

​ 2，也有将类型放在变量名前面，返回值类型放在方法名前面

举个栗子：

上图Demo类定义了三个方法：

method()方法：修饰符为public，没有参数，没有返回值。

method1()方法：修饰符为private，没有参数，返回值类型为String。

method2()方法：修饰符为protected，接收两个参数，第一个参数类型为int，第二个参数类型为String，返回值类型是int。

2.类与类之间关系的表示方式

关联关系
关联关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。

关联又可以分为单向关联，双向关联，自关联。

1.单向关联

 

在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址，这通过让Customer类持有一个类型为Address的成员变量类实现。

2.双向关联

从上图中我们很容易看出，所谓的双向关联就是双方各自持有对方类型的成员变量。

在UML类图中，双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个List，表示一个顾客可以购买多个商品；在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。

3.自关联

自关联在UML类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node类包含类型为Node的成员变量，也就是“自己包含自己”。

4、聚合关系

聚合关系是关联关系的一种，是强关联关系，是整体和部分之间的关系。

聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。

在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。下图所示是大学和教师的关系图：

5、组合关系

组合表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系。

在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了。

在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。下图所示是头和嘴的关系图：
 

 

6、依赖关系

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图，司机驾驶汽车：
 

 

7、继承关系

继承关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系。

在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如，Student 类和 Teacher 类都是 Person 类的子类，其类图如下图所示：

 

8、实现关系

实现关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。

在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具，其类图如图 9 所示。

工厂模式可以细分为：简单工厂、工厂方法和抽象工厂三种模式

 四、设计模式

 1、单例模式

对单例模式不做介绍

2、工厂模式

工厂模式可以细分为：简单工厂、工厂方法和抽象工厂三种模式。

使用场景：

1：单个对象的创建过程比较复杂，如需要做复杂初始化操作的对象
2：需要根据不同的类型创建不同的对象

针对细分的三种模式，使用场景又可以区分：

1、当对象的创建逻辑简单，通常只需要new一下就可以，此时可以考虑简单工厂模式

2、当对象的创建逻辑很复杂，需要做各种初始化操作，此时可以考虑使用工厂方法模式，将对象创建的复杂逻辑拆分到各个工厂类中，让每个工厂类都不至于过于复杂

3、当系统中有多于一个产品族，而每次只使用其中某一产品族，此时使用抽象工厂模式

简单工厂模式

示例：
ProcuctA和ProductB继承Product抽象类，ProductFactory根据传入的type来返回不同的Product实例

Product 抽象类：

public abstract class Product {
    public abstract void use();
}

ProductA类：

public class ProductA extends Product {
    @Override
    public void use() {
        System.out.println("You are using ProductA...");
    }
}

ProductB类;

public class ProductB extends Product {
    @Override
    public void use() {
        System.out.println("You are using ProductB...");
    }
}

ProductFactory：

public class ProductFactory {
    public Product createProduct(String type) {
        Product product = null;
        if ("A".equals(type)) {
            product = new ProductA();
        } else if ("B".equals(type)) {
            product = new ProductB();
        }
        return product;
    }
}

调用：

public class Main {
    public static void main(String[] args) {
        ProductFactory factory = new ProductFactory();
        Product product;

        product = factory.createProduct("A");
        product.use();

        product = factory.createProduct("B");
        product.use();
    }
}

缺点、当频繁的新增不同产品时，需要频繁的修改ProductFactory中的if/else逻辑

工具及jdk中的应用：

java.text.DateFormat#getDateInstance()
java.text.DateFormat#getDateInstance(int)
java.text.DateFormat#getDateInstance(int, java.util.Locale)

KeyGenerator keyGen=KeyGenerator.getInstance("DESede");

工厂方法模式

示例：

相比简单工厂，这种方式将ProductFactory定义为抽象类，然后创建不同的具体ProductAFactory和ProductBFactory，在使用时决定创建那种工厂和对象，避免了if/else判断

Product

public abstract class Product {
    public abstract void use();
}

 ProductA

public class ProductA extends Product {
    @Override
    public void use() {
        System.out.println("You are using ProductA...");
    }
}

ProductB

public class ProductB extends Product {
    @Override
    public void use() {
        System.out.println("You are using ProductB...");
    }
}

ProductFactory

public abstract class ProductFactory {
    public abstract Product createProduct();
}

ProductAFactory

public class ProductAFactory extends ProductFactory {
    @Override
    public Product createProduct() {
        return new ProductA();
    }
}

ProductBFactory

public class ProductBFactory extends ProductFactory {
    @Override
    public Product createProduct() {
        return new ProductB();
    }
}

调用

public class Main {

    public static void main(String[] args) {
        ProductFactory factory;
        Product product;

        factory = new ProductAFactory();
        product = factory.createProduct();
        product.use();

        factory = new ProductBFactory();
        product = factory.createProduct();
        product.use();
    }

}

抽象工厂模式

抽象工厂模式在工厂方法模式的基础上进行进一步抽象。设想下面这种场景：

现有两种具体产品（具体产品）：篮球，足球（在此基础上的抽象产品可看成球）。同时，对于足球和篮球来说，他们都有两种品牌安踏、李宁。

如果采用工厂方法模式解决上述场景中创建产品的问题，需要在抽象工厂中定义创建产品的方法，并新建四个用于创建具体产品的具体工厂类：用于创建“李宁篮球”的具体工厂，用于创建“李宁足球”的具体工厂，用于创建“安踏篮球”的具体工厂，用于创建“安踏足球”的具体工厂。

从上面的解决方式可以看出：使用工厂方法模式，创建了很多具体工厂类，而没有利用产品的“商品族”的概念。

由此引出，抽象工厂模式是用于解决“一类产品”的创建问题（在上述场景中，可以把“李宁篮球”，“李宁足球”，“安踏篮球”，“安踏足球”归纳为：“篮球”，“足球”这两类商品）
 

抽象工厂模式的角色

 抽象工厂模式的通用写法

抽象工厂：

/**
 * 抽象工厂
 */
public interface AbstractFactory {
    Basketball makeBasketball();
    Football makeFootball();
}

抽象产品族篮球：

/**
 * 抽象产品族；篮球
 */
public interface Basketball {
    void sayBasketball();
}

抽象产品族足球：

/**
 * 抽象产品族：足球
 */
public interface Football {
    void sayFootball();
}

四个具体产品：李宁篮球、李宁足球、安踏篮球、安踏足球

/**
 * 具体产品：李宁篮球
 */
@Slf4j
public class LiningBasketball implements Basketball {
    @Override
    public void sayBasketball() {
        log.info("我是李宁篮球");
    }
}
 
 
/**
 * 具体产品：李宁足球
 */
@Slf4j
public class LiningFootball implements Football {
    @Override
    public void sayFootball() {
        log.info("我是李宁足球");
    }
}
 
 
/**
 * 具体产品：安踏篮球
 */
@Slf4j
public class AntaBasketball implements Basketball {
    @Override
    public void sayBasketball() {
        log.info("我是安踏篮球");
    }
}
 
 
/**
 * 具体产品：安踏足球
 */
@Slf4j
public class AntaFootball implements Football {
    @Override
    public void sayFootball() {
        log.info("我是安踏足球");
    }
}

具体工厂：

/**
 * 具体工厂，负责生产李宁篮球，李宁足球
 */
public class LiningFactoy implements AbstractFactory {
    @Override
    public Basketball makeBasketball() {
        return new LiningBasketball();
    }
 
    @Override
    public Football makeFootball() {
        return new LiningFootball();
    }
}
 
/**
 * 具体工厂，负责生产安踏篮球，安踏足球
 */
public class AntaFactory implements AbstractFactory {
    @Override
    public Basketball makeBasketball() {
        return new AntaBasketball();
    }
 
    @Override
    public Football makeFootball() {
        return new AntaFootball();
    }
}

调用

public class Client {
    public static void main(String[] args){
        // 生产李宁篮球和安踏足球
        LiningFactoy liningFactoy = new LiningFactoy();
        AntaFactory antaFactory = new AntaFactory();
 
        liningFactoy.makeBasketball().sayBasketball();
        antaFactory.makeFootball().sayFootball();
    }
}

参照文档：工厂模式 | 菜鸟教程

原型模式 

原型模式 | 菜鸟教程

违背ocp原则，应用度也不是很高，不做详细介绍，参照原型模式熟悉上手

建造者模式

建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。

可以简单的理解为两层含义。

1、构建与表示分离：构建代表对象创建，表示代表对象行为，方法。也就是将对象的创建与行为进行分离（对应到java代码，其实就是使用接口规定行为，然后由具体的实体类进行构建）

2、创建不同表示：也就是具备同样的行为，但是却由于构建的行为顺序不同或其他原因可以创建出不同的表示

应用场景：

       从定义来看，建造者模式和工厂模式是非常相似的，和工厂模式一样，具备创建与表示分离的特性。建造者模式唯一区别与工厂模式的是针对复杂对象的创建，也就是说，如果创建简单对象，通常使用工厂模式进行创建，而如果复杂的对象，就可以考虑使用建造者模式。

当需要创建产品具备复杂创建过程时，可以抽取出共性创建过程，然后交由具体实现类自定义创建流程，使得同样的创建行为可以生产出不同的产品，分离了创建与表示，是创建产品的灵活性大大增加，建造者模式主要用于以下场景

1、相同的方法，不同的执行顺序，产生不同的结果

2、多个部件或零件，都可以装配到一个对象中，但是产生的结果有不相同

3、产品类非常复杂，或者产品类中不同的调用顺序产生不同的作用

4、初始化一个对象特别复杂，参数多，而且很多参数都具有默认值

建造者模式的四个角色

1.Product（产品角色）： 一个具体的产品对象。
2.Builder（抽象建造者）： 创建一个Product对象的各个部件指定的 接口/抽象类。
3.ConcreteBuilder（具体建造者）： 实现接口，构建和装配各个部件。
4.Director（指挥者）： 构建一个使用Builder接口的对象。它主要是用于创建一个复杂的对象。它主要有两个作用，一是：隔离了客户与对象的生产过程，二是：负责控制产品对象的生产过程。

示例：

定义产品：

//产品->Product
public class House {

   //地基
	private String baise;
   //砌墙
	private String wall;
   //封顶
	private String roofed;
	public String getBaise() {
		return baise;
	}
	public void setBaise(String baise) {
		this.baise = baise;
	}
	public String getWall() {
		return wall;
	}
	public void setWall(String wall) {
		this.wall = wall;
	}
	public String getRoofed() {
		return roofed;
	}
	public void setRoofed(String roofed) {
		this.roofed = roofed;
	}
	
}

抽象建造者

// 抽象的建造者
public abstract class HouseBuilder {

	protected House house = new House();
	
	//将建造的流程写好, 抽象的方法
	public abstract void buildBasic();
	public abstract void buildWalls();
	public abstract void roofed();
	
	//建造房子好， 将产品(房子) 返回
	public House buildHouse() {
		return house;
	}

}

 具体建造者：

//具体建造者
public class HighBuilding extends HouseBuilder {

	@Override
	public void buildBasic() {
		// TODO Auto-generated method stub
		System.out.println(" 高楼的打地基100米 ");
	}

	@Override
	public void buildWalls() {
		// TODO Auto-generated method stub
		System.out.println(" 高楼的砌墙20cm ");
	}

	@Override
	public void roofed() {
		// TODO Auto-generated method stub
		System.out.println(" 高楼的透明屋顶 ");
	}

}
//具体建造者
public class CommonHouse extends HouseBuilder {

	@Override
	public void buildBasic() {
		// TODO Auto-generated method stub
		System.out.println(" 普通房子打地基5米 ");
	}

	@Override
	public void buildWalls() {
		// TODO Auto-generated method stub
		System.out.println(" 普通房子砌墙10cm ");
	}

	@Override
	public void roofed() {
		// TODO Auto-generated method stub
		System.out.println(" 普通房子屋顶 ");
	}

}

 指挥者:

//指挥者，这里去指定制作流程，返回产品（指挥者就是分离产品和生厂对象的关系交给指挥者去处理）
public class HouseDirector {
	
	HouseBuilder houseBuilder = null;

	//构造器传入 houseBuilder
	public HouseDirector(HouseBuilder houseBuilder) {
		this.houseBuilder = houseBuilder;
	}

	//通过setter 传入 houseBuilder
	public void setHouseBuilder(HouseBuilder houseBuilder) {
		this.houseBuilder = houseBuilder;
	}
	
	//如何处理建造房子的流程，交给指挥者
	public House constructHouse() {
		houseBuilder.buildBasic();
		houseBuilder.buildWalls();
		houseBuilder.roofed();
		return houseBuilder.buildHouse();
	}
}

调用示例：

public static void main(String[] args) {
		//盖普通房子
		CommonHouse commonHouse = new CommonHouse();
		//准备创建房子的指挥者
		HouseDirector houseDirector = new HouseDirector(commonHouse);
		
		//完成盖房子，返回产品(普通房子)
		House house = houseDirector.constructHouse();
		
		//盖高楼
		HighBuilding highBuilding = new HighBuilding();
		//重置建造者
		houseDirector.setHouseBuilder(highBuilding);
		//完成盖房子，返回产品(高楼)
		houseDirector.constructHouse();
	}

实际开发中常见的用法

lombok插件中的@Builder注解

适配器模式

       适配器模式（Adapter Pattern）：结构型模式之一，将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的哪些类可以一起工作。

 角色职责

1、目标角色（Target）：该角色定义把其他类转换为何种接口，也就是我们的期望接口。
2、源角色（Adaptee）：你想把谁转换成目标角色，这个“谁”就是源角色，它是已经存在的、运行良好的类或对象。
3、适配器角色（Adapter）：适配器模式的核心角色，其他两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单：通过继承或是类关联的方式把源角色转换为目标角色。

代码实现
前言：举个栗子，我今天买了机票，飞到香港迪士尼去游玩，晚上回到了酒店，想给我的笔记本电脑充电，但这时我发现，香港的插座是英式三角插座，我的充电器插不进去。这时我们就可以使用适配器模式，进行适配。

类适配器：适配器通过类来实现，以类来继承和实现接口的方式，来获取被适配类的信息并转换输出重写到适配接口。

中式插座（源角色 Adaptee）
 

@AllArgsConstructor
@Data
public class ChineseStandard {
    public String getChineseStandard() {
        return "中式插座";
    }
}

英式插座（目标角色 Target）

public interface BritishStandard {
    String getBritishStandard();
}

插座适配器（适配器角色 Adapter）

public class StandardAdapter extends ChineseStandard implements BritishStandard {
    @Override
    public String getBritishStandard() {
        return this.getChineseStandard();
    }
}

笔记本电脑（客户端 Client）

public class Notebook {
    public void charge(BritishStandard britishStandard) {
        if ("中式插座".equals(britishStandard.getBritishStandard())) {
            System.out.println("充电成功！");
        } else {
            System.out.println("充电失败！");
        }
    }
}

测试类

public class AdapterTest {
    public static void main(String[] args) {
        // 充电成功！
        new Notebook().charge(new StandardAdapter());
    }
}

对象适配器：通过实例对象（构造器传递）来实现适配器，而不是再用继承，其余基本同类适配器。

我么们将插座适配器就行修改即可

@AllArgsConstructor
public class StandardAdapter implements BritishStandard {
    private ChineseStandard chineseStandard;

    @Override
    public String getBritishStandard() {
        return chineseStandard.getChineseStandard();
    }
}

测试类

public class AdapterTest {
    public static void main(String[] args) {
        // 充电成功！
        new Notebook().charge(new StandardAdapter(new ChineseStandard()));
    }
}

接口适配器：当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求。

英式插座（目标角色 Target）

public interface BritishStandard {
    String getBritishStandard();

    String getTypeC();

    String getUSB();
}

插座适配器（适配器角色 Adapter）

@AllArgsConstructor
public abstract class StandardAdapter extends ChineseStandard implements BritishStandard {

    @Override
    public String getBritishStandard() {
        return null;
    }

    @Override
    public String getTypeC() {
        return null;
    }

    @Override
    public String getUSB() {
        return null;
    }
}

测试类

public class AdapterTest {
    public static void main(String[] args) {
        StandardAdapter standardAdapter= new StandardAdapter() {
            @Override
            public String getBritishStandard() {
                return new ChineseStandard().getChineseStandard();
            }
        };
        // 充电成功！
        new Notebook().charge(standardAdapter);
    }
}

桥接模式

桥接(Bridge)模式属于结构型设计模式。通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。把抽象(abstraction)与行为实现(implementation)分离开来，从而可以保持各部分的独立性以及应对它们的功能扩展

主要角色：

（1）Abstraction：抽象类。

（2）RefinedAbstraction：扩充抽象类。

（3）Implementor：实现类接口。

（4）ConcreteImplementor：具体实现类 。

适用场景

• 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时
• 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时
• 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时

代码示例 

场景： 一个甜品店，售卖的食品有蛋糕、奶茶和牛奶，但是每个商品都有各种口味：草莓味、芒果味、香蕉味。

 那如果这时候食品又新增了拿铁，口味又新增了青提，难道要把商品和口味再全部绑定一套吗？

 显然这种两个维度扩展的情况不适合这种方案。那我们另辟蹊径，创建两个父类，一个食品类一个水果类。两个父类各自包含了相应的子类，然后根据需要将食品和水果进行组合。如下：

创建食品类，该类为抽象类，主要提供添加add的方法；

public abstract class Food {
    //水果
    Fruit fruit;
    
    public void setFruit(Fruit fruit) {
        this.fruit = fruit;
    }
    /**
     * 制作时添加
     */
    public abstract void add();
}

食品类的子类一：蛋糕

public class Cake extends Food {
 
    @Override
    public void add() {
        fruit.beAdd("蛋糕");
    }
}

 食品类的子类二：牛奶

public class Milk extends Food {
    @Override
    public void add() {
        fruit.beAdd("牛奶");
    }
}

 食品类的子类三：奶茶

public class MilkTea extends Food {
    @Override
    public void add() {
        fruit.beAdd("奶茶");
    }
}

创建水果接口类

public interface Fruit {
    /**
     * 被添加
     * @param food
     */
    public void beAdd(String food);
}

水果接口实现类一：香蕉

public class Banana implements Fruit {
    @Override
    public void beAdd(String food) {
        System.out.println("香蕉" + food);
    }
}

水果接口实现类二：草莓

public class Strawberry implements Fruit {
    @Override
    public void beAdd(String food) {
        System.out.println("草莓" + food);
    }
}

水果接口实现类三：芒果

public class Mango implements Fruit {
    @Override
    public void beAdd(String food) {
        System.out.println("芒果" + food);
    }
}

主方法测试

public class TestMain {
 
    public static void main(String[] args) {
 
        //蛋糕
        Fruit mango = new Mango();
        Food cake = new Cake();
        cake.setFruit(mango);
        cake.add();
        //牛奶
        Food milk = new Milk();
        milk.setFruit(mango);
        milk.add();
    }
}

装饰者模式

1.定义

装饰者模式(Decorator Pattern)是指在不改变原有对象的基础上，将功能附加到对象上，提供了比继承更有弹性的替代方案(扩展原有对象的功能，它通过创建一个包装对象，也就是装饰来包裹真实的对象)。

2.装饰者模式角色

**(1).抽象构件(Component)：**通常是一个抽象类或者一个接口，定义了一系列方法，方法的实现可以由子类实现或者自己实现。通常不会直接使用该类，而是通过继承或者实现接口来实现特定的功能。
**(2).具体构件(Concrete Component)：**是抽象构件(Component)的子类，实现了对应的方法，它就是那个被装饰的类。
**(3).抽象装饰者(Decorator)：**是Component的子类，它是具体装饰者角色共同实现的类(可以是接口、抽象类、类)，并且持有一个Comonent类型的对象引用，它的主要作用就是把客户端的调用委派到被装饰类。
**(4).具体装饰角色(Concrete Component)：**它是具体的装饰类，是Decorator的子类，当然也是Component的子类。它主要就是定义具体的装饰功能。

3.代码实现方式

(1).创建一个抽象构件接口，定义一些方法。
(2).创建具体构件实现抽象构件，重写抽象构件中的方法(实现具体功能)，这个具体构件就是基础构件了，也就是被装饰的类。
(3).创建抽象装饰者实现抽象构件，重写抽象构件中的方法，组合依赖一个抽象构件类型对象。
(4).创建具体构件继承(或实现)抽象装饰者，重写抽象装饰者中的方法，在重写的方法中调用组合的抽象构件类型角色的方法，然后再加上需要修饰的方法。

4.代码实现

(1).场景
比如我们做一个蛋糕，里面可以加一些水果啊，巧克力啥的。
(2).具体代码
 

/**
 * 抽象构件
 */
public interface Cake {

    String getCakeDesc();

    BigDecimal getPrice();
}

/**
 * 具体构件(基础构件)
 */
public class CommonCake implements Cake{

    @Override
    public String getCakeDesc() {
        return "这是一个普通蛋糕！";
    }

    @Override
    public BigDecimal getPrice()  {
        return new BigDecimal("100");
    }
}

/**
 * 抽象装饰者
 */
public class Decorator implements Cake{

    private Cake cake;

    public Decorator(Cake cake){
        this.cake = cake;
    }

    @Override
    public String getCakeDesc() {
        return this.cake.getCakeDesc();
    }

    @Override
    public BigDecimal getPrice() {
        return this.cake.getPrice();
    }
}

/**
 * 具体装饰者
 */
public class MangoCakeDecorator extends Decorator{

    public MangoCakeDecorator(Cake cake) {
        super(cake);
    }

    @Override
    public String getCakeDesc(){
        return super.getCakeDesc() + "加一个芒果！";
    }

    @Override
    public BigDecimal getPrice(){
        return super.getPrice().add(new BigDecimal("25"));
    }
}

/**
 * 具体装饰者
 */
public class GrapesCakeDecorator extends Decorator{

    public GrapesCakeDecorator(Cake cake) {
        super(cake);
    }

    @Override
    public String getCakeDesc(){
        return super.getCakeDesc() + "加一个葡萄！";
    }

    @Override
    public BigDecimal getPrice(){
        return super.getPrice().add(new BigDecimal("30"));
    }
}

public class DecoratorTest {

    public static void main(String[] args) {
        Cake cake = new CommonCake();
        cake = new Decorator(cake);
        System.out.println(cake.getCakeDesc() + " 价格： " + cake.getPrice());
        cake = new MangoCakeDecorator(cake);
        System.out.println(cake.getCakeDesc() + " 价格： " + cake.getPrice());
        cake = new MangoCakeDecorator(cake);
        System.out.println(cake.getCakeDesc() + " 价格： " + cake.getPrice());
        cake = new GrapesCakeDecorator(cake);
        System.out.println(cake.getCakeDesc() + " 价格： " + cake.getPrice());
    }
}

这是一个普通蛋糕！ 价格： 100
这是一个普通蛋糕！加一个芒果！ 价格： 125
这是一个普通蛋糕！加一个芒果！加一个芒果！ 价格： 150
这是一个普通蛋糕！加一个芒果！加一个芒果！加一个葡萄！ 价格： 180

示例2：

//创建一个Person接口
public interface Person {
    void eat();
}




//声明Man类去实现Person接口，并且重写eat方法
public class Man implements Person{
    @Override
    public void eat() {
        System.out.println("男人在吃饭");
    }
}



//Decorator(这个类是关键，实现了接口并且有真实对象的引用)
//声明一个Decorator抽象类去实现Person接口
public abstract class Decorator implements Person {
    protected Person person;

    public Decorator(Person person) {
        this.person = person;
    }

    @Override
    public void eat() {
        person.eat();
    }
}



//声明ManDecoratorA类继承Decorator类
//下面的就是具体的添加额外功能的了具体子类，比如有些人吃饭前先洗手或者吃完饭后洗碗之类，当然具体什么事情根据业务决定
public class ManDecoratorA extends Decorator{

    public ManDecoratorA(Person person) {
        super(person);
    }

    @Override
    public void eat() {
        wash();
        super.eat();
    }

    private void wash() {
        System.out.println("吃饭前要洗手");
    }
}



//声明ManDecoratorB类继承Decorator类
//下面的就是具体的添加额外功能的了具体子类，比如有些人吃饭前先洗手或者吃完饭后洗碗之类，当然具体什么事情根据业务决定
public class ManDecoratorB extends Decorator{

    public ManDecoratorB (Person person){
        super(person);
    }

    @Override
    public void eat() {
        super.eat();
        washDishes();
    }

    private void washDishes() {
        System.out.println("吃饭后洗要碗");
    }
}




//测试函数
public class Test {
    public static void main(String[] args) {
        Person person = new Man();
        person.eat();
        System.out.println("-------");
        ManDecoratorA man1 = new ManDecoratorA(person);
        ManDecoratorB man2 = new ManDecoratorB(person);
        man1.eat();
        System.out.println("------");
        man2.eat();
    }
}

输出：

男人在吃饭
-------
吃饭前要洗手
男人在吃饭
------
男人在吃饭
吃饭后洗要碗

进程已结束,退出代码0

组合模式

定义
组合模式（Composite Pattern）属于结构型模式，将对象组合成树形结构以表示“部分”—“整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。

什么叫“部分”—“整体”的层次结构呢，举个例子：
假如我们在网上购物买了很多的东西，仓库收到订单后按照订单明细给我们的东西打包，由于东西很多他们用了很多的包装盒，并最终用一个巨大的盒子来包裹每一个订单的商品，如下图所示：

每一个盒子里面都可能包含许多的小盒子和商品，以此类推。因此“部分”—“整体”是一个相对的概念，假如在第三层的包装盒内部还有许多的小盒子和商品，那么这个第三层的包装盒对于整个订单的包裹来说他是“部分”，而对于他里面的盒子与商品来说，他又是“整体”。

再比如我们电脑中的文件夹里面，A文件夹里面包含了B、C、D文件夹以及一个demo.txt文件，B文件夹里面又包括了E、F文件夹和demo.ps和demo.word文件。这也是“部分”—“整体”的层次结构。

解析：

component ：一个接口或抽象类，描述了树中简单项目和复杂项目所共有的操作。
leaf：叶节点是树的基本结构， 它不包含子项目。一般情况下， 叶节点最终会完成大部分的实际工作， 因为它们无法将工作指派给其他部分。
composite：是包含叶节点或其他容器等子项目的单位。 容器接收到请求后会将工作分配给自己的子项目， 处理中间结果， 然后将最终结果返回给客户端。

实例

现在，假设我们要建立一个公司的销售部门层次结构。我们先把这个层次结构画一下：

 代码：
我们先建一个部门的接口Department：

public interface Department {
    void printDepartmentName();     //输出部门名称的方法
}

然后建立一个总的销售部门：SaleDepartment

public class SaleDepartment implements Department {

	//部门名称
    private  String name;  

	//相当于一个Composite，下面可以拥有其他的子部门，而不是一个叶子节点
    List departments = new ArrayList<>();  

	//用于增加子部门
    public void addDepartment(Department department){    
        departments.add(department);
    }

	//删除子部门
    public void remove(Department department){     
        departments.remove(department);
    }

    @Override
    public void printDepartmentName() {
    	//打印本部门的名称
        System.out.println(name);
        //打印本部门下的子部门的名称
        for (Department department:departments){
            department.printDepartmentName();
        }
    }

    public SaleDepartment(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

创建一个国内销售部门：DomesticSaleDepartment

public class DomesticSaleDepartment implements Department {

    private String name;

	//相当于一个Composite，下面可以拥有其他各个省份的子部门
    List list = new ArrayList<>();

    public DomesticSaleDepartment(String name) {
        this.name = name;
    }
	//用于增加子部门
    public void add(Department department){
        list.add(department);
    }
	//用于删除子部门
    public void remove(Department department){
        list.remove(department);
    }

    @Override
    public void printDepartmentName() {
        System.out.println(name);
        for (Department department:list){
            department.printDepartmentName();
        }
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

建立一个国际销售部门：InternationalSaleDepartment ，我们假设国外业务不多，就不细分了，作为一个叶子节点

public class InternationalSaleDepartment implements Department {
    private String name;

    public InternationalSaleDepartment(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

	
    @Override
    public void printDepartmentName() {
        System.out.println(name);
    }
}

在建立一个浙江销售部门：ZheJiangSaleDepartment ，同样作为叶子节点

public class ZheJiangSaleDepartment implements Department {

    private String name;

    public ZheJiangSaleDepartment(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public void printDepartmentName() {
        System.out.println(name);
    }
}

测试类：CompositeDemo

public class CompositeDemo {

    public static void main(String[] args) {
    	//创建一个总的销售部门作为根节点
        Department saleDepartment = new SaleDepartment("销售部门");
        //创建国内销售部门
        DomesticSaleDepartment domesticSaleDepartment = new DomesticSaleDepartment("国内销售部门");
        //创建国内浙江销售部门
        ZheJiangSaleDepartment ZheJiangSaleDepartment = new ZheJiangSaleDepartment("浙江销售部门");
        //将浙江销售部门加入到国内销售部门
        domesticSaleDepartment.list.add(ZheJiangSaleDepartment);
        //创建国际销售部门
        InternationalSaleDepartment internationalSaleDepartment = new InternationalSaleDepartment("国际销售部门");
        //将国内销售部门和国外销售部门全部加入到总的销售部门去
        ((SaleDepartment) saleDepartment).departments.add(domesticSaleDepartment);
        ((SaleDepartment) saleDepartment).departments.add(internationalSaleDepartment);
        //打印部门名称
        saleDepartment.printDepartmentName();
    }
}

打印输出：

销售部门
国内销售部门
浙江销售部门
国际销售部门

使用场合

• 需求中体现的是部分与整体层次的结构时，如实现树状结构，可以使用组合模式
• 希望用户可以忽略组合对象与单个对象的不同，统一的使用组合结构中的所有对象时，就应该考虑用组合模式了

外观模式

概述
外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口，看下类图：（我们以一个计算机的启动过程为例）

外观模式的特点
外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点：
降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
外观（Facade）模式的主要缺点如下：
不能很好地限制客户使用子系统类，很容易带来未知风险。
增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
外观模式的应用场景
通常在以下情况下可以考虑使用外观模式。

对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。
外观模式的结构与实现
外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。

它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。

模式的结构
外观（Facade）模式包含以下主要角色。

1、外观（Facade）角色：为多个子系统对外提供一个共同的接口。
2、子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
3、客户（Client）角色：通过一个外观角色访问各个子系统的功能。
实现

public class CPU {
	
	public void startup(){
		System.out.println("cpu startup!");
	}
	
	public void shutdown(){
		System.out.println("cpu shutdown!");
	}
}

public class Memory {
	
	public void startup(){
		System.out.println("memory startup!");
	}
	
	public void shutdown(){
		System.out.println("memory shutdown!");
	}
}

public class Disk {
	
	public void startup(){
		System.out.println("disk startup!");
	}
	
	public void shutdown(){
		System.out.println("disk shutdown!");
	}
}

public class Computer {
	private CPU cpu;
	private Memory memory;
	private Disk disk;
	
	public Computer(){
		cpu = new CPU();
		memory = new Memory();
		disk = new Disk();
	}
	
	public void startup(){
		System.out.println("start the computer!");
		cpu.startup();
		memory.startup();
		disk.startup();
		System.out.println("start computer finished!");
	}
	
	public void shutdown(){
		System.out.println("begin to close the computer!");
		cpu.shutdown();
		memory.shutdown();
		disk.shutdown();
		System.out.println("computer closed!");
	}
}

//测试
public class User {
 
	public static void main(String[] args) {
		Computer computer = new Computer();
		computer.startup();
		computer.shutdown();
	}
}

享元模式

享元模式
享元模式，运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。

享元模式的优缺点
优点：

可以极大减少内存中对象的数量，使得相同或相似对象在内存中只保存一份，从而可以节约系统资源，提高系统性能。

享元模式的外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不同的环境中被共享。

缺点：

享元模式使得系统变得复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂化。

为了使对象可以共享，享元模式需要将享元对象的部分状态外部化，而读取外部状态将使得运行时间变长。
享元模式的结构

1、FlyWeight：抽象的享元角色，产品的抽象类，定义了对象的外部状态和内部状态的接口或实现

2、ConcreteFlyWeight：具体的享元角色，产品的实现类，实现了抽象角色定义的相关业务

3、FlyWeightFactory：享元工厂类，内部提供一个池容器，储存ConcreteFlyWeight，同时提供从池中存取数据的操作
 

实现流程

图书享元类(FlyWeight：抽象的享元角色)

public interface Book {
    void read();
}

 具体图书（ConcreteFlyWeight：具体的享元角色）

public class FairyBook implements Book {
    private String bookName;

    public FairyBook(String bookName) {
        this.bookName = bookName;
    }

    public void read() {
        System.out.println(bookName + hashCode());//用hashCode区分实例
    }

}

 图书享元工厂(FlyWeightFactory：享元工厂类)

public class BookFactory {
    private Map bookMap = new HashMap();

    public FairyBook getFairyBook(String bookName) {
        Book book = null;
        //根据书名来找书，如果有就直接取，没有就新建
        if (bookMap.containsKey(bookName)) {
            book = bookMap.get(bookName);
        } else {
            book = new FairyBook(bookName);
            bookMap.put(bookName, book);
        }

        return (FairyBook) book;
    }
}

客户端

BookFactory bookFactory = new BookFactory();
FairyBook fairyBook1 = bookFactory.getFairyBook("格林童话");
fairyBook1.read();
FairyBook fairyBook2 = bookFactory.getFairyBook("小王子");
fairyBook2.read();
FairyBook fairyBook3 = bookFactory.getFairyBook("格林童话");
fairyBook3.read();

输出

格林童话1704856573
小王子705927765
格林童话1704856573//与第一本是同个实例

代理模式

定义

     代理模式是常见的设计模式之一，顾名思义，代理模式就是代理对象具备真实对象的功能，并代替真实对象完成相应操作，并能够在操作执行的前后，对操作进行增强处理。（为真实对象提供代理，然后供其他对象通过代理访问真实对象）

静态代理

    以租房为例，租客找房东租房，然后中间经过房屋中介，以此为背景，它的UML图如下：

​ 

可以看出房东类（RentHouse）和代理类（IntermediaryProxy）都实现了租房接口，这就是一个静态代理的前提，那就是真实类和代理类要实现同一个接口，在代理类中实现真实类的方法同时可以进行真实类方法的增强处理，在一个代理类中就可以完成对多个真实对象的注入工作。

注意：代理对象和目标对象要实现相同的接口，让后通过调用相同的方法来调用目标对象的方法

代码如下：
IRentHouse 共同接口

public interface IRentHouse {
    void rentHouse();
}

 RentHouse 目标对象

public class RentHouse implements IRentHouse {

    @Override
    public void rentHouse() {
        System.out.println("实现租房");
    }
}

 IntermediaryProxy 代理对象

public class IntermediaryProxy implements IRentHouse {
    private IRentHouse iRent;
    public IntermediaryProxy(IRentHouse iRentHouse) {
        iRent=iRentHouse;
    }
    @Override
    public void rentHouse() {
        System.out.println("交中介费");
        iRent.rentHouse();
        System.out.println("中介负责维修管理");
    }
}

   测试

//client测试类
public class TestStaticProxy {
    public static void main(String[] args) {
        //定义租房
        IRentHouse iRentHouse = new RentHouse();
        //定义中介
        IRentHouse intermediaryProxy = new IntermediaryProxy(iRentHouse);
        //中介租房
        intermediaryProxy.rentHouse();
    }
}

动态代理

 从静态代理的代码中可以发现，静态代理的缺点显而易见，那就是当真实类的方法越来越多的时候，这样构建的代理类的代码量是非常大的，所以就引进动态代理.

动态代理允许使用一种方法的单个类（代理类）为具有任意数量方法的任意类（真实类）的多个方法调用提供服务，看到这句话，可以容易的联想到动态代理的实现与反射密不可分。
JAVA 反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为 java 语言的反射机制。

1.jdk动态代理（接口代理）
    Jdk代理涉及到java.lang.reflect包中的InvocationHandler接口和Proxy类，核心方法是
 

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable 

jdk动态代理过程中实际上代理的是接口，是因为在创建代理实例的时候，依赖的是java.lang.reflect包中Proxy类的newProxyInstance方法，该方法的生效就恰恰需要这个参数；

public static Object newProxyInstance(ClassLoader loader,
                                          Class[] interfaces,
                                          InvocationHandler h)
        throws IllegalArgumentException{
        ……
        }

下面以案例来说明jdk动态代理的完整过程：涉及两套接口及其实现类，一个代理类，以及一个测试类

//接口1
public interface Animal {
    void wakeup();
    void sleep();
}

//实现类1
public class Cat implements Animal {
    private String name;
    public Cat() {
    }
    public Cat(String name) {
        this.name = name;
    }
    @Override
    public void wakeup() {
        System.out.println("小猫"+name+"早晨醒来啦");
    }
    @Override
    public void sleep() {
        System.out.println("小猫"+name+"晚上睡觉啦");
    }
}

//实现类2
public class Dog implements Animal {
    private String name;
    public Dog() {
    }
    public Dog(String name) {
        this.name = name;
    }
    @Override
    public void wakeup() {
        System.out.println("小狗"+name+"早晨醒来啦");
    }
    @Override
    public void sleep() {
        System.out.println("小狗"+name+"晚上睡觉啦");
    }
}

//接口2
public interface Person {
    void wakeup();
    void sleep();
}
//实现类1
public class Student implements Person{
    private String name;
    public Student() {
    }
    public Student(String name) {
        this.name = name;
    }
    @Override
    public void wakeup() {
        System.out.println("学生"+name+"早晨醒来啦");
    }
    @Override
    public void sleep() {
        System.out.println("学生"+name+"晚上睡觉啦");
    }
}
//实现类2
public class Doctor implements Person {
    private String name;
    public Doctor() {
    }
    public Doctor(String name) {
        this.name = name;
    }
    @Override
    public void wakeup() {
        System.out.println("医生"+name+"早晨醒来啦");
    }
    @Override
    public void sleep() {
        System.out.println("医生"+name+"晚上睡觉啦");
    }
}

//代理类
public class JDKDynamicProxy implements InvocationHandler {
    private Object bean;
    public JDKDynamicProxy(Object bean) {
        this.bean=bean;
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        String methodname=method.getName();
        if (methodname.equals("wakeup")){
            System.out.println("早安~~~");
        }else if(methodname.equals("sleep")){
            System.out.println("晚安~~~");
        }
        return method.invoke(bean,args);
    }
}

//测试类
	public class TestJDKDynamicProxy {
    public static void main(String[] args) {
        JDKDynamicProxy proxy = new JDKDynamicProxy(new Student("张三"));
        //创建代理实例
        Person student = (Person) Proxy.newProxyInstance(proxy.getClass().getClassLoader(), new Class[]{Person.class}, proxy);
        student.wakeup();
        student.sleep();
        
        proxy = new JDKDynamicProxy(new Doctor("王教授"));
        Person doctor = (Person) Proxy.newProxyInstance(proxy.getClass().getClassLoader(), new Class[]{Person.class}, proxy);
        doctor.wakeup();
        doctor.sleep();
        
        proxy = new JDKDynamicProxy(new Dog("旺旺"));
        Animal dog = (Animal) Proxy.newProxyInstance(proxy.getClass().getClassLoader(), new Class[]{Animal.class}, proxy);
        dog.wakeup();
        dog.sleep();
  
        proxy = new JDKDynamicProxy(new Cat("咪咪"));
        Animal cat = (Animal) Proxy.newProxyInstance(proxy.getClass().getClassLoader(), new Class[]{Animal.class}, proxy);
        cat.wakeup();
        cat.sleep();
    }
}

在执行过程中，为两个接口分别生成了编译以后的虚拟代理类$Proxy0.class 和 $Proxy1.class，下面以接口1的动态代理过程，讲述jdk动态代理的来龙去脉

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

package com.sun.proxy;

import com.deer.test.com.deer.vo.Person;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.lang.reflect.UndeclaredThrowableException;

public final class $Proxy0 extends Proxy implements Person {
    private static Method m1;
    private static Method m4;
    private static Method m2;
    private static Method m3;
    private static Method m0;

    public $Proxy0(InvocationHandler var1) throws  {
        super(var1);
    }

    public final boolean equals(Object var1) throws  {
        try {
            return (Boolean)super.h.invoke(this, m1, new Object[]{var1});
        } catch (RuntimeException | Error var3) {
            throw var3;
        } catch (Throwable var4) {
            throw new UndeclaredThrowableException(var4);
        }
    }

    public final void wakeup() throws  {
        try {
            super.h.invoke(this, m4, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }

    public final String toString() throws  {
        try {
            return (String)super.h.invoke(this, m2, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }

    public final void sleep() throws  {
        try {
            super.h.invoke(this, m3, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }

    public final int hashCode() throws  {
        try {
            return (Integer)super.h.invoke(this, m0, (Object[])null);
        } catch (RuntimeException | Error var2) {
            throw var2;
        } catch (Throwable var3) {
            throw new UndeclaredThrowableException(var3);
        }
    }

    static {
        try {
            m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
            m4 = Class.forName("com.deer.test.com.deer.vo.Person").getMethod("wakeup");
            m2 = Class.forName("java.lang.Object").getMethod("toString");
            m3 = Class.forName("com.deer.test.com.deer.vo.Person").getMethod("sleep");
            m0 = Class.forName("java.lang.Object").getMethod("hashCode");
        } catch (NoSuchMethodException var2) {
            throw new NoSuchMethodError(var2.getMessage());
        } catch (ClassNotFoundException var3) {
            throw new NoClassDefFoundError(var3.getMessage());
        }
    }
}

整个调用过程如下（省去本人由于自身原因走的弯路，直接说梳理结果）：
从测试类中可以看出，一共创建了四个代理实例，然后每个代理实例对应接口的实现类，道理相同，这里只分析Student类的实现过程

 

总结对比：
1.静态代理中，代理类和真实类实现的是同一个接口，重写同样的方法；jdk动态代理中，代理类和真实类关系不大，代理类实现无侵入式的代码扩展。
2.静态代理中当接口中方法增加的时候，在代理类代码量也会增加，显然是不妥的；jdk动态代理解决了这个问题，当业务增加，代理类的代码不会增加。
3.jdk动态代理实现的是jdk自带InvocationHandler接口，实现了这个接口的类也叫拦截器类，也叫代理类。

2.cglib动态代理
    从上面可以看出，jdk动态代理的前提条件是，要有接口存在，那还有许多场景是没有接口的，这个时候就需要cglib动态代理了，CGLIB(Code Generation Library)是一个基于ASM的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成。CGLIB通过继承方式实现代理。
以下案例中所用到的**被代理类**和和上面jdk动态代理一样

cglib动态代理过程中生成的是实现类的子类，cglib是如何凭空创造的实现类的子类的，下面是测试代码
 

//所需的代理类
public class CglibProxy implements MethodInterceptor {
    private Enhancer enhancer=new Enhancer();
    private Object bean;

    public CglibProxy(Object bean) {
        this.bean = bean;
    }

    public Object getProxy(){
        //设置需要创建子类的类
        enhancer.setSuperclass(bean.getClass());
        enhancer.setCallback(this);
        return enhancer.create();

    }
    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        String methodName = method.getName();
        if (methodName.equals("wakeup")){
            System.out.println("早安~~~");
        }else if(methodName.equals("sleep")){
            System.out.println("晚安~~~");
        }
        return method.invoke(bean,objects);
    }
}

//测试类
public class TestCglibProxy {
    public static void main(String[] args) {
        //生成虚拟代理类的代码，本来虚拟代理子类是看不见的，
        //下面这句话的作用就是把执行过程中cglib增强后的class字节码文件
        System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "D:\\aop");
        CglibProxy proxy = new CglibProxy(new Student("张三"));
        Student student = (Student) proxy.getProxy();
        student.wakeup();
        student.sleep();

        proxy = new CglibProxy(new Doctor("王教授"));
        Doctor doctor = (Doctor) proxy.getProxy();
        doctor.wakeup();
        doctor.sleep();

        proxy = new CglibProxy(new Dog("旺旺"));
        Dog dog = (Dog) proxy.getProxy();
        dog.wakeup();
        dog.sleep();

        proxy = new CglibProxy(new Cat("咪咪"));
        Cat cat = (Cat) proxy.getProxy();
        cat.wakeup();
        cat.sleep();
    }
}

附上代理Cat类时候，生成的Cat的子类：

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//
public class Cat$$EnhancerByCGLIB$$8ca2de8b extends Cat implements Factory {
    private boolean CGLIB$BOUND;
    public static Object CGLIB$FACTORY_DATA;
    private static final ThreadLocal CGLIB$THREAD_CALLBACKS;
    private static final Callback[] CGLIB$STATIC_CALLBACKS;
    private MethodInterceptor CGLIB$CALLBACK_0;
    private static Object CGLIB$CALLBACK_FILTER;
    private static final Method CGLIB$sleep$0$Method;
    private static final MethodProxy CGLIB$sleep$0$Proxy;
    private static final Object[] CGLIB$emptyArgs;
    private static final Method CGLIB$wakeup$1$Method;
    private static final MethodProxy CGLIB$wakeup$1$Proxy;
    private static final Method CGLIB$equals$2$Method;
    private static final MethodProxy CGLIB$equals$2$Proxy;
    private static final Method CGLIB$toString$3$Method;
    private static final MethodProxy CGLIB$toString$3$Proxy;
    private static final Method CGLIB$hashCode$4$Method;
    private static final MethodProxy CGLIB$hashCode$4$Proxy;
    private static final Method CGLIB$clone$5$Method;
    private static final MethodProxy CGLIB$clone$5$Proxy;

    static void CGLIB$STATICHOOK4() {
        CGLIB$THREAD_CALLBACKS = new ThreadLocal();
        CGLIB$emptyArgs = new Object[0];
        Class var0 = Class.forName("com.example.demo.cglibproxy.vo.Cat$$EnhancerByCGLIB$$8ca2de8b");
        Class var1;
        Method[] var10000 = ReflectUtils.findMethods(new String[]{"equals", "(Ljava/lang/Object;)Z", "toString", "()Ljava/lang/String;", "hashCode", "()I", "clone", "()Ljava/lang/Object;"}, (var1 = Class.forName("java.lang.Object")).getDeclaredMethods());
        CGLIB$equals$2$Method = var10000[0];
        CGLIB$equals$2$Proxy = MethodProxy.create(var1, var0, "(Ljava/lang/Object;)Z", "equals", "CGLIB$equals$2");
        CGLIB$toString$3$Method = var10000[1];
        CGLIB$toString$3$Proxy = MethodProxy.create(var1, var0, "()Ljava/lang/String;", "toString", "CGLIB$toString$3");
        CGLIB$hashCode$4$Method = var10000[2];
        CGLIB$hashCode$4$Proxy = MethodProxy.create(var1, var0, "()I", "hashCode", "CGLIB$hashCode$4");
        CGLIB$clone$5$Method = var10000[3];
        CGLIB$clone$5$Proxy = MethodProxy.create(var1, var0, "()Ljava/lang/Object;", "clone", "CGLIB$clone$5");
        var10000 = ReflectUtils.findMethods(new String[]{"sleep", "()V", "wakeup", "()V"}, (var1 = Class.forName("com.example.demo.cglibproxy.vo.Cat")).getDeclaredMethods());
        CGLIB$sleep$0$Method = var10000[0];
        CGLIB$sleep$0$Proxy = MethodProxy.create(var1, var0, "()V", "sleep", "CGLIB$sleep$0");
        CGLIB$wakeup$1$Method = var10000[1];
        CGLIB$wakeup$1$Proxy = MethodProxy.create(var1, var0, "()V", "wakeup", "CGLIB$wakeup$1");
    }

    final void CGLIB$sleep$0() {
        super.sleep();
    }

    public final void sleep() {
        MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
        if (this.CGLIB$CALLBACK_0 == null) {
            CGLIB$BIND_CALLBACKS(this);
            var10000 = this.CGLIB$CALLBACK_0;
        }

        if (var10000 != null) {
            var10000.intercept(this, CGLIB$sleep$0$Method, CGLIB$emptyArgs, CGLIB$sleep$0$Proxy);
        } else {
            super.sleep();
        }
    }

    final void CGLIB$wakeup$1() {
        super.wakeup();
    }

    public final void wakeup() {
        MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
        if (this.CGLIB$CALLBACK_0 == null) {
            CGLIB$BIND_CALLBACKS(this);
            var10000 = this.CGLIB$CALLBACK_0;
        }

        if (var10000 != null) {
            var10000.intercept(this, CGLIB$wakeup$1$Method, CGLIB$emptyArgs, CGLIB$wakeup$1$Proxy);
        } else {
            super.wakeup();
        }
    }

    final boolean CGLIB$equals$2(Object var1) {
        return super.equals(var1);
    }

    public final boolean equals(Object var1) {
        MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
        if (this.CGLIB$CALLBACK_0 == null) {
            CGLIB$BIND_CALLBACKS(this);
            var10000 = this.CGLIB$CALLBACK_0;
        }

        if (var10000 != null) {
            Object var2 = var10000.intercept(this, CGLIB$equals$2$Method, new Object[]{var1}, CGLIB$equals$2$Proxy);
            return var2 == null ? false : (Boolean)var2;
        } else {
            return super.equals(var1);
        }
    }

    final String CGLIB$toString$3() {
        return super.toString();
    }

    public final String toString() {
        MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
        if (this.CGLIB$CALLBACK_0 == null) {
            CGLIB$BIND_CALLBACKS(this);
            var10000 = this.CGLIB$CALLBACK_0;
        }

        return var10000 != null ? (String)var10000.intercept(this, CGLIB$toString$3$Method, CGLIB$emptyArgs, CGLIB$toString$3$Proxy) : super.toString();
    }

    final int CGLIB$hashCode$4() {
        return super.hashCode();
    }

    public final int hashCode() {
        MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
        if (this.CGLIB$CALLBACK_0 == null) {
            CGLIB$BIND_CALLBACKS(this);
            var10000 = this.CGLIB$CALLBACK_0;
        }

        if (var10000 != null) {
            Object var1 = var10000.intercept(this, CGLIB$hashCode$4$Method, CGLIB$emptyArgs, CGLIB$hashCode$4$Proxy);
            return var1 == null ? 0 : ((Number)var1).intValue();
        } else {
            return super.hashCode();
        }
    }

    final Object CGLIB$clone$5() throws CloneNotSupportedException {
        return super.clone();
    }

    protected final Object clone() throws CloneNotSupportedException {
        MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
        if (this.CGLIB$CALLBACK_0 == null) {
            CGLIB$BIND_CALLBACKS(this);
            var10000 = this.CGLIB$CALLBACK_0;
        }

        return var10000 != null ? var10000.intercept(this, CGLIB$clone$5$Method, CGLIB$emptyArgs, CGLIB$clone$5$Proxy) : super.clone();
    }

    public static MethodProxy CGLIB$findMethodProxy(Signature var0) {
        String var10000 = var0.toString();
        switch(var10000.hashCode()) {
        case -1385928386:
            if (var10000.equals("sleep()V")) {
                return CGLIB$sleep$0$Proxy;
            }
            break;
        case -508378822:
            if (var10000.equals("clone()Ljava/lang/Object;")) {
                return CGLIB$clone$5$Proxy;
            }
            break;
        case 391780310:
            if (var10000.equals("wakeup()V")) {
                return CGLIB$wakeup$1$Proxy;
            }
            break;
        case 1826985398:
            if (var10000.equals("equals(Ljava/lang/Object;)Z")) {
                return CGLIB$equals$2$Proxy;
            }
            break;
        case 1913648695:
            if (var10000.equals("toString()Ljava/lang/String;")) {
                return CGLIB$toString$3$Proxy;
            }
            break;
        case 1984935277:
            if (var10000.equals("hashCode()I")) {
                return CGLIB$hashCode$4$Proxy;
            }
        }

        return null;
    }

    public Cat$$EnhancerByCGLIB$$8ca2de8b() {
        CGLIB$BIND_CALLBACKS(this);
    }

    public Cat$$EnhancerByCGLIB$$8ca2de8b(String var1) {
        super(var1);
        CGLIB$BIND_CALLBACKS(this);
    }

    public static void CGLIB$SET_THREAD_CALLBACKS(Callback[] var0) {
        CGLIB$THREAD_CALLBACKS.set(var0);
    }

    public static void CGLIB$SET_STATIC_CALLBACKS(Callback[] var0) {
        CGLIB$STATIC_CALLBACKS = var0;
    }

    private static final void CGLIB$BIND_CALLBACKS(Object var0) {
        Cat$$EnhancerByCGLIB$$8ca2de8b var1 = (Cat$$EnhancerByCGLIB$$8ca2de8b)var0;
        if (!var1.CGLIB$BOUND) {
            var1.CGLIB$BOUND = true;
            Object var10000 = CGLIB$THREAD_CALLBACKS.get();
            if (var10000 == null) {
                var10000 = CGLIB$STATIC_CALLBACKS;
                if (CGLIB$STATIC_CALLBACKS == null) {
                    return;
                }
            }

            var1.CGLIB$CALLBACK_0 = (MethodInterceptor)((Callback[])var10000)[0];
        }

    }

    public Object newInstance(Callback[] var1) {
        CGLIB$SET_THREAD_CALLBACKS(var1);
        Cat$$EnhancerByCGLIB$$8ca2de8b var10000 = new Cat$$EnhancerByCGLIB$$8ca2de8b();
        CGLIB$SET_THREAD_CALLBACKS((Callback[])null);
        return var10000;
    }

    public Object newInstance(Callback var1) {
        CGLIB$SET_THREAD_CALLBACKS(new Callback[]{var1});
        Cat$$EnhancerByCGLIB$$8ca2de8b var10000 = new Cat$$EnhancerByCGLIB$$8ca2de8b();
        CGLIB$SET_THREAD_CALLBACKS((Callback[])null);
        return var10000;
    }

    public Object newInstance(Class[] var1, Object[] var2, Callback[] var3) {
        CGLIB$SET_THREAD_CALLBACKS(var3);
        Cat$$EnhancerByCGLIB$$8ca2de8b var10000 = new Cat$$EnhancerByCGLIB$$8ca2de8b;
        switch(var1.length) {
        case 0:
            var10000.();
            break;
        case 1:
            if (var1[0].getName().equals("java.lang.String")) {
                var10000.((String)var2[0]);
                break;
            }

            throw new IllegalArgumentException("Constructor not found");
        default:
            throw new IllegalArgumentException("Constructor not found");
        }

        CGLIB$SET_THREAD_CALLBACKS((Callback[])null);
        return var10000;
    }

    public Callback getCallback(int var1) {
        CGLIB$BIND_CALLBACKS(this);
        MethodInterceptor var10000;
        switch(var1) {
        case 0:
            var10000 = this.CGLIB$CALLBACK_0;
            break;
        default:
            var10000 = null;
        }

        return var10000;
    }

    public void setCallback(int var1, Callback var2) {
        switch(var1) {
        case 0:
            this.CGLIB$CALLBACK_0 = (MethodInterceptor)var2;
        default:
        }
    }

    public Callback[] getCallbacks() {
        CGLIB$BIND_CALLBACKS(this);
        return new Callback[]{this.CGLIB$CALLBACK_0};
    }

    public void setCallbacks(Callback[] var1) {
        this.CGLIB$CALLBACK_0 = (MethodInterceptor)var1[0];
    }

    static {
        CGLIB$STATICHOOK4();
    }
}

不难发现，cglib生成的增强子类，比jdk生成的接口代理类默认多实现了clone();而创建这种子类的核心代码就是：

 public Object getProxy(){
        //设置需要创建子类的类
        enhancer.setSuperclass(bean.getClass());
        enhancer.setCallback(this);
        return enhancer.create();

    }

该案例下，cglib的代理实现过程如下：

总结：cglib动态代理和jdk动态代理的区别显而易见，但是实现逻辑差不多，cglib代理类是通过实现MethodInterceptor，重写intercept方法，通过生成被代理类的子类来达到代理增强代码的目的；而Jdk代理是通过实现InvocationHandler，重写invoke方法，通过生成接口的代理类来达到代码增强的目的，所以jdk动态代理的实现需要接口，cglib则不需要，spring5.0以上以及springboot2.0以上默认采用cglib动态来实现AOP。

模版方法模式 

我们平时办理入职的流程是：填写入职登记表->打印简历->复印学历->复印身份证->签订劳动合同->建立花名册->办理工牌->安排工位。我平时在家里炒菜的流程是：洗锅->点火->热锅->上油->下原料->翻炒->放调料->出锅。以上这些都是模板模式的体现。

模板模式又叫模版方法模式(Template Method Pattern)，是指定义一个算法的骨架，并允许子类为一个或多个步骤提供实现。模板模式使得子类可以在不改变算法结构的情况下，重新定义算法的某些步骤，属于行为型设计模式。模版模式适用于以下场景：

（1）一次性实现算法的不变部分，并将可变的行为留给子类来实现。

（2）各子类中公共的行为被提取出来并集中到一个公共的父类中，从而避免代码重复。

下面我们写一个汽车类，来看代码实现：

 抽象模型：

public abstract class HummerModel {
    //能发动
    public abstract void start();
 
    //能停下来
    public abstract void stop();
 
    //喇叭会出声音
    public abstract void alarm();
 
    //引擎会轰隆隆地响
    public abstract void engineBoom();
    
    //会跑吧
    public final void run() {
        //先发动汽车
        this.start();
        //引擎开始轰鸣
        this.engineBoom();
        //然后就开始跑了，跑的过程中遇到一条狗挡路，就按喇叭 
        this.alarm();
        //到达目的地就停车 
        this.stop();
    }
}

在抽象类中，我们定义了悍马模型都必须具有的特质:能够发动、停止，喇叭会响，引擎可以轰鸣，而且还可以停止。每个型号的悍马实现是不同的，H1型号的悍马如代码:

public class HummerH1Model extends HummerModel{
 
    @Override
    public void start() {
        System.out.println("悍马H1启动.....");
    }
 
    @Override
    public void stop() {
        System.out.println("悍马H1停车.....");
    }
 
    @Override
    public void alarm() {
        System.out.println("悍马H1鸣笛.....");
    }
 
    @Override
    public void engineBoom() {
        System.out.println("悍马H1引擎Boom.....");
    }
    
}

 H2型号实现： 

public class HummerH2Model extends HummerModel{
 
    @Override
    public void start() {
        System.out.println("悍马H2启动.....");
    }
 
    @Override
    public void stop() {
        System.out.println("悍马H2停车.....");
    }
 
    @Override
    public void alarm() {
        System.out.println("悍马H2鸣笛.....");
    }
 
    @Override
    public void engineBoom() {
        System.out.println("悍马H2引擎Boom.....");
    }
 
}

场景类：

class Client{
    public static void main(String[] args) {
        HummerModel hummerH2Model = new HummerH2Model();
        //H2模型演示
        hummerH2Model.run();
    }
}

结果如下：

  模版方法通用类图

模板方法模式非常简单，仅仅使用了Java的继承机制，但它是一个应用非常广泛的模式。其中，AbstractClass叫做抽象模板。

注意 ：为了防止恶意的操作，一般模板方法都加上final关键字，不允许被覆写。

到目前为止，两个模型都运行的很好，但是突然有一天老大给我说车子不行了，一启动就滴滴滴响，客户说H1模型的汽车想让他响再响，那怎么解决呢？我们来看类图：

抽象类实现 ：

public abstract class HummerModel {
 
    //钩子方法，默认是回响的
    protected boolean isAlarm() {
        return true;
    }
 
    //能发动
    protected abstract void start();
 
    //能停下来
    protected abstract void stop();
 
    //喇叭会出声音
    protected abstract void alarm();
 
    //引擎会轰隆隆地响
    protected abstract void engineBoom();
 
    //会跑吧
    protected final void run() {
        //先发动汽车
        this.start();
        //引擎开始轰鸣
        this.engineBoom();
        //想叫再叫
        if (isAlarm()) {
            this.alarm();
        }
        //到达目的地就停车
        this.stop();
    }
}

 在抽象类中，isAlarm()是一个实现方法。其作用是模板方法根据其返回值决定是否要响喇叭，子类可以覆写该返回值，由于H1型号的喇叭是想让它响就响，不想让它响就不响， 由人控制，来看代码：

public class HummerH1Model extends HummerModel{
    private boolean isAlarm = true;
    @Override
    public void start() {
        System.out.println("悍马H1启动.....");
    }
 
    @Override
    public void stop() {
        System.out.println("悍马H1停车.....");
    }
 
    @Override
    public void alarm() {
        System.out.println("悍马H1鸣笛.....");
    }
 
    @Override
    public void engineBoom() {
        System.out.println("悍马H1引擎Boom.....");
    }
 
    @Override
    public boolean isAlarm() {
        return this.isAlarm;
    }
    public void setAlarm(boolean isAlarm){
        this.isAlarm = isAlarm;
    }
}

场景类：

class Client{
    public static void main(String[] args) {
        System.out.println("-------H1型号悍马--------");
        System.out.println("H1型号的悍马是否需要喇叭声响?0-不需要 1-需要");
        String type = new Scanner(System.in).next();
        HummerH1Model hummerH1Model = new HummerH1Model();
        if (type.equals("0")){
            hummerH1Model.setAlarm(false);
        }
        hummerH1Model.run();
    }
}

结果如下：

看到没，H1型号的悍马是由客户自己控制是否要响喇叭，也就是说外界条件改变，影响到模板方法的执行。在我们的抽象类中isAlarm()的返回值就是影响了模板方法的执行结果,该方法就叫做钩子方法(Hook Method)。有了钩子方法模板方法模式才算完美，大家可以想想,由子类的一个方法返回值决定公共部分的执行结果，是不是很有吸引力呀!

模板方法模式就是在模板方法中按照一定的规则和顺序调用基本方法，具体到前面那个例子，就是run()方法按照规定的顺序(先调用start()，然后再调用engineBoom()，再调用 alarm()，最后调用stop() )调用本类的其他方法，并且由isAlarm()方法的返回值确定run()中的执行顺序变更。
 

 命令模式

一、什么是命令式
命令(Command)模式又叫作动作(Action)模式或事务(Transaction)模式，是一种对象的行为模式。将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。

命令模式的本质：封装请求

设计意图：命令模式通过将请求封装到一个命令(Command)对象中，实现了请求调用者和具体实现者之间的解耦。 

二、命令模式的适用性
在以下条件下可以考虑使用命令模式：
           • 如果需要抽象出需要执行的动作，并参数化这些对象，可以选用命令模式。将这些需要执行的动作抽象成为命令，然后实现命令的参数化配置。
           • 如果需要在不同的时刻指定、排列和执行请求，可以选用命令模式。将这些请求封装成为命令对象，然后实现将请求队列化。
           • 如果需要支持取消操作，可以选用命令模式，通过管理命令对象，能很容易地实现命令的恢复和重做功能。
           • 如果需要支持当系统崩溃时，能将系统的操作功能重新执行一遍，可以选用命令模式。将这些操作功能的请求封装成命令对象，然后实现日志命令，就可以在系统恢复以后，通过日志获取命令列表，从而重新执行一遍功能。
           • 在需要事务的系统中，可以选用命令模式。命令模式提供了对事务进行建模的方法。命令模式有一个别名就是Transaction。  

三、命令模式的结构

命令模式涉及的角色及其职责如下：

抽象命令(Command)角色：一般定义为接口，用来定义执行命令的接口。
具体命令(ConcreteCommand)角色：通常会持有接收者对象，并调用接收者对象的相应功能来完成命令要执行的操作。
接收者(Receiver)角色：真正执行命令的对象。任何类都可能成为接收者，只要它能够实现命令要求实现的相应功能。
调用者(Invoker)角色：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
客户端(Client)角色：创建具体的命令对象，并且设置命令对象的接收者。

Demo 实现

先来看看抽象命令接口的定义。示例代码如下：

/**
 * 命令接口
 */
public interface Command {
 
	/**
	 * 执行命令
	 */
	public void execute();
}

接下来看看具体命令是如何实现的。示例代码如下：

public class ConcreteCommand implements Command{
    /**
     * 持有相应的接收者对象
     */
    private Receiver receiver = null;
 
    /**
     * 构造方法，传入相应的接收者对象
     *
     * @param receiver 相应的接收者对象
     */
    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }
 
    /**
     * 执行命令
     */
    @Override
    public void execute() {
        // 通常会转调接收者对象的相应方法，让接收者来真正执行功能
        receiver.action();
    }
 
}

再来看看接收者的定义。示例代码如下： 

/**
 * 命令的接收者
 */
public class Receiver {
	/**
	 * 示意方法，真正执行命令相应的操作
	 */
	public void action() {
		System.out.println("接收者开始行动。。。");
	}
}

下面该来看看调用者如何实现的了。示例代码如下

/**
 * 命令的调用者
 */
public class Invoker {
 
	/**
	 * 持有命令对象
	 */
	private Command command = null;
 
	/**
	 * 设置调用者持有的命令对象
	 * 
	 * @param command 命令对象
	 */
	public void setCommand(Command command) {
		this.command = command;
	}
 
	/**
	 * 示意方法，调用命令执行请求
	 */
	public void invoke() {
		command.execute();
	}
}

再来看看客户端的实现

public class Client {
	public static void main(String[] args) {
		// 创建接收者
		Receiver receiver = new Receiver();
		// 创建命令对象，设定它的接收者
		Command command = new ConcreteCommand(receiver);
		// 创建调用者，把命令对象设置进去
		Invoker invoker = new Invoker();
		invoker.setCommand(command);
		// 调用者调用命令
		invoker.invoke();
	}
}

四、命令模式的优点
更松散的耦合： 命令模式使得发起命令的对象——客户端，和具体实现命令的对象——接收者对象完全解耦，也就是说发起命令的对象完全不知道具体实现对象是谁，也不知道如何实现。
更动态的控制：命令模式把请求封装起来，可以动态地对它进行参数化、队列化和日志化等操作，从而使得系统更灵活。
很自然的复合命令：命令模式中的命令对象能够很容易地组合成复合命令，如宏命令，从而使系统操作更简单，功能更强大。
更好的扩展性： 由于发起命令的对象和具体的实现完全解耦，因此扩展新的命令就很容易，只需要实现新的命令对象，然后在装配的时候，把具体的实现对象设置到命令对象中，然后就可以使用这个命令对象，已有的实现完全不用变化。 

五、总结
命令模式是对命令的封装。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。
每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。  

访问者模式

概念理解

访问者模式概念：封装作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

通俗的解释就是，系统中有一些固定结构的对象(元素)，在其内部提供一个accept()方法用来接受访问者对象的访问，不同的访问者对同一元素的访问内容不同，所以使得相同的元素可以产生不同的元素结果。

比如在一个人事管理系统中，有多个工种的员工和多个老板，不同的老板对同一个员工的关注点是不同的，CTO可能关注的就是技术，CEO可能更注重绩效。

员工就是一个稳定的元素，老板就是变化的，对应概念就是：封装员工的一些操作，可以在不改变员工类的前提下，增加新的老板访问同一个员工。

在访问者模式中包含五个角色，抽象元素、具体元素、抽象访问者、具体访问者、结构元素。

抽象元素：定义一个接受访问的方法accept，参数为访问者对象。

具体元素：提供接受访问者访问的具体实现调用访问者的访问visit，并定义额外的数据操作方法。

抽象访问者：这个角色主要是定义对具体元素的访问方法visit，理论上来说方法数等于元素(固定类型的对象，也就是被访问者)个数。

具体访问者：实现对具体元素的访问visit方法，参数就是具体元素。

结构对象：创建一个数组用来维护元素，并提供一个方法访问所有的元素。

案例实现 

 在一个公司有干活的工程师和管理者，也有抓技术的CTO和管绩效的CEO，CTO和CEO都会访问管理员和工程师，当公司来了新的老板，只需要增加访问者即可。工程师和管理者就是元素、公司就是结构体、CEO、CTO就是访问者。

抽象元素： 

public interface ElementAbstract {
    void accept(VisitorAbstract visitor);
}

具体元素-工程师： 

public class ElementEngineer implements ElementAbstract {

    private String name;

    private int kpi;

    ElementEngineer(String name){
        this.name = name;
        this.kpi = new Random().nextInt(10);
    }

    public String getName() {
        return name;
    }

    public int getKpi() {
        return kpi;
    }


    @Override
    public void accept(VisitorAbstract visitor) {
        visitor.visit(this);
    }

    public int getCodeLineTotal(){
        return this.kpi * 1000000;
    }
}

 具体元素-管理者：

public class ElementManager implements ElementAbstract {
    private String name;

    private int kpi;

    ElementManager(String name){
        this.name = name;
        this.kpi = new Random().nextInt(10);
    }

    public String getName() {
        return name;
    }

    public int getKpi() {
        return kpi;
    }

    @Override
    public void accept(VisitorAbstract visitor) {
        visitor.visit(this);
    }

    public int getProductNum(){
        return this.kpi * 10;
    }

}

 抽象访问者：

public interface VisitorAbstract {
    void visit(ElementEngineer engineer);

    void visit(ElementManager manager);
}

具体访问者-CEO

public class VisitorCEO implements VisitorAbstract {
    @Override
    public void visit(ElementEngineer engineer) {
        System.out.println("工程师：" + engineer.getName() + "KPI:" + engineer.getKpi());
    }

    @Override
    public void visit(ElementManager manager) {
        System.out.println("经理：" + manager.getName() + "KPI:" + manager.getKpi() + " 今年共完成项目：" + manager.getProductNum() + "个");
    }
}

具体访问者-CTO

public class VisitorCTO implements VisitorAbstract {
    @Override
    public void visit(ElementEngineer engineer) {
        System.out.println("工程师：" + engineer.getName() + " 今年代码量" + engineer.getCodeLineTotal() + "行");
    }

    @Override
    public void visit(ElementManager manager) {
        System.out.println("经理：" + manager.getName() + " 今年共完成项目：" + manager.getProductNum() + "个");
    }
}

结构体：

public class Structure {
    List list = new ArrayList<>();

    public Structure addEmployee(ElementAbstract employee){
        list.add(employee);
        return this;
    }

    public void report(VisitorAbstract visitor){
        list.forEach(employee -> {
            employee.accept(visitor);
        });
    }

}

客户端：

public class Client {
    public static void main(String[] args) {
        //元素对象
        ElementEngineer engineerZ = new ElementEngineer("小张");
        ElementEngineer engineerW = new ElementEngineer("小王");
        ElementEngineer engineerL = new ElementEngineer("小李");

        ElementManager managerZ = new ElementManager("张总");
        ElementManager managerW = new ElementManager("王总");
        ElementManager managerL = new ElementManager("李总");

        //结构体对象
        Structure structure = new Structure();
        structure.addEmployee(engineerZ).addEmployee(engineerW).addEmployee(engineerL).addEmployee(managerZ).addEmployee(managerW).addEmployee(managerL);
        structure.report(new VisitorCTO());
        System.out.println("---------------------------------------");
        structure.report(new VisitorCEO());


    }
}

访问者模式中的伪动态双分派

访问者模式中有一个重要的概念叫：伪动态双分派。

我们一步一步解读它的含义，什么叫分派？根据对象的类型而对方法进行的选择,就是分派(Dispatch)。

发生在编译时的分派叫静态分派，例如重载（overload），发生在运行时的分派叫动态分派，例如重写（overwrite）。

其中分派又分为单分派和多分派。

单分派:依据单个变量进行方法的选择就叫单分派，Java 动态分派（重写）只根据方法的接收者一个变量进行分配，所以其是单分派。

多分派:依据多个变量进行方法的选择就叫多分派，Java 静态分派（重载）要根据方法的接收者与参数这两个变量进行分配，所以其是多分派。

理解了概念我们接着看我们的案例：

 @Override
    public void accept(VisitorAbstract visitor) {
        visitor.visit(this);
    }

 我们案例中的accept方法，是由元素的运行时类型决定的，应该是属于动态单分派。我们接着看 visitor.visit(this)又是一次动态单分派，两次动态单分派实现了双分派的效果，所以称为伪动态双分派。这个概念理解就好，实际应用中知不知道这玩意都不影响。

迭代器模式 

概念理解 

迭代器模式官方解释就是提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。何为聚合对象呢？最典型的就是集合类。

大白话也就是，集合中的数据是私有的，集合中不应该提供直接遍历的方法，要定义一个新的对象用于访问这个集合。

既然是一个专门用来遍历的对象，一个被遍历的聚合对象，很显然至少有两个对象，迭代器对象、聚合对象，由于遵循面向接口编程的原则，迭代器对象和聚合对象应该抽象出来接口，那自然而然就是应该有四个角色：

抽象聚合（InterfaceAggregate）角色：定义存储、添加、删除聚合元素以及创建迭代器对象的接口。

具体聚合（ConcreteAggregate）角色：实现抽象聚合类，返回一个具体迭代器的实例。

抽象迭代器（Iterator）角色：定义访问和遍历聚合元素的接口，通常包含 hasNext()、next() 等方法。

具体迭代器（Concretelterator）角色：实现抽象迭代器接口中所定义的方法，完成对聚合对象的遍历，记录遍历的当前位置。

基于四个角色我们举一个典型案例。

案例实现

应该是有四个类

抽象聚合角色，用于定义增删改查元素的统一规范接口，和创建迭代器对象的方法

具体聚合角色，实现抽象聚合角色方法

抽象迭代器角色，定义遍历元素的统一规范接口

具体迭代器，实现抽象迭代器角色的方法。

抽象聚合角色：

public interface InterfaceAggregate {
    /**
     * 增加对象
     * @param obj 对象
     */
    void add(Object obj);

    /**
     * 移除对象
     * @param obj 对象
     */
    void remove(Object obj);

    /**
     * 调用迭代器
     * @return 迭代器
     */
    Iterator getIterator();
}

 具体聚合角色：

public class ConcreteAggregate implements InterfaceAggregate{
    private List