如果有兴趣了解更多相关内容，欢迎来我的个人网站看看：瞳孔空间

结构型模式(Structural Pattern)描述如何将类或对象按某种布局组成更大的结构。就像搭积木，可以通过简单积木的组合形成复杂的、功能更为强大的结构

结构型模式可以分为类结构型模式和对象结构型模式

• 类结构型模式关心类的组合，由多个类可以组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系
• 对象结构型模式关心类与对象的组合，通过关联关系使得在一个类中定义另一个类的实例对象，然后通过该对象调用其方法。根据“合成复用原则”，在系统中尽量使用关联关系来替代继承关系，因此大部分结构型模式都是对象结构型模式

结构型模式分为以下7种：

• 代理模式
• 适配器模式
• 装饰者模式
• 桥接模式
• 外观模式
• 组合模式
• 享元模式

一：代理模式

有时候客户端不能直接操作到某个对象,但又必须和那个对象有所互动，比如以下两种情况：

• 如果对象是一个大图片，需要花费很长时间才能显示出来，此时需要做个图片Proxy来代替真正的图片
• 如果对象在某远端服务器上，直接操作这个对象因为网络速度原因可能比较慢，那我们可以先用Proxy来代替那个对象

如何应对这种变化？如何提供一种机制让原本交互起来比较困难的两个对象实现畅通无阻地交流呢？如何保持系统的结构不随着需求改变而轻易改变？这就是代理模式。

代理模式：为其他对象提供一种代理以控制对这个对象的访问。

代理模式分为三种角色：

• 抽象主题类：通过接口或抽象类声明真实主题和代理对象实现的业务方法。
• 真实主题类：实现了抽象主题中的具体业务，是代理对象所代表的真实对象，是最终要引用的对象。
• 代理类：提供了与真实主题相同的接口，其内部含有对真实主题的引用，他可以访问、控制或扩展真实主题的功能。

Java中的代理按照代理类生成时机不同又分为：

• 静态代理：静态代理代理类在编译期生成
• 动态代理：而动态代理代理类在Java运行时动态生成。动态代理又有两种：
  • JDK代理
  • CGLib代理

1.1：静态代理

以下是火车站卖票的案例：

public class ProxyDemo1 {
    public static void main(String[] args) {
        ProxyPoint1 proxyPoint = new ProxyPoint1();
        proxyPoint.sell();
    }
}

// 售票接口
interface SellTickets1 {
    void sell();
}

// 火车站
class TrainStation1 implements SellTickets1 {
    @Override
    public void sell() {
        System.out.println("火车站卖票");
    }
}

// 代售点卖票
class ProxyPoint1 implements SellTickets1 {
    // 声明火车站类对象
    private TrainStation1 trainStation = new TrainStation1();

    @Override
    public void sell() {
        System.out.println("收取服务费");
        trainStation.sell();
    }
}

从上面代码中可以看出主类(充当测试类)直接访问的是ProxyPoint类对象，也就是说ProxyPoint作为访问对象和目标对象的中介。同时也对sell方法进行了增强（代理点收取了服务费用)。

1.2：动态代理

1.2.1：JDK代理

Java中提供了一个动态代理类Proxy，该类提供了一个创建代理对象的静态方法(newProxyInstance方法)来获取代理对象。

改进火车站售票代码如下：

public class ProxyDemo2 {
    public static void main(String[] args) {
        ProxyFactory2 proxyFactory = new ProxyFactory2();
        SellTickets2 proxyObject = proxyFactory.getProxyObject();
        proxyObject.sell();
    }
}

// 售票接口
interface SellTickets2 {
    void sell();
}

// 火车站
class TrainStation2 implements SellTickets2 {
    @Override
    public void sell() {
        System.out.println("火车站卖票");
    }
}

// 代理工厂，用于创建代理对象
class ProxyFactory2 {
    private TrainStation2 station = new TrainStation2();

    public SellTickets2 getProxyObject() {
        return (SellTickets2)Proxy.newProxyInstance(
                station.getClass().getClassLoader(),
                station.getClass().getInterfaces(),
                (proxy, method, args) -> {
                    /*
                     * proxy：与Proxy.newProxyInstance返回值为同一对象
                     * method：对接口中的方法进行封装的method对象
                     * args：调用方法的实际参数
                     */
                    System.out.println("收取服务费");
                    return method.invoke(station, args);
                }
        );
    }
}

1.2.2：CGLIB代理

如果没有定义SellTickets接口，只定义了TrainStation (火车站类)。很显然JDK代理是无法使用了，因为JDk动态代理要求必须定义接口，对接口进行代理。

CGLIB是一个功能强大，高性能的代码生成包。它为没有实现接口的类提供代理，为JDK的动态代理提供了很好的补充。

CGLIB是第三方提供的包，所以需要引入jar包的坐标:

<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>2.2.2</version>
</dependency>

改进火车站售票代码如下：

public class ProxyDemo3 {
    public static void main(String[] args) {
        ProxyFactory3 proxyFactory3 = new ProxyFactory3();
        TrainStation3 proxyObject = proxyFactory3.getProxyObject();
        proxyObject.sell();
    }
}

// 火车站
class TrainStation3 {
    public void sell() {
        System.out.println("火车站卖票");
    }
}

// 代理对象工厂
class ProxyFactory3 implements MethodInterceptor {
    private TrainStation3 station = new TrainStation3();

    public TrainStation3 getProxyObject() {
        // 创建Enhancer对象，类似于JDK代理中的Proxy类
        Enhancer enhancer = new Enhancer();
        // 设置父类的字节码对象
        enhancer.setSuperClass(TrainStation3.class);
        // 设置回调函数
        enhancer.setCallback(this);
        // 创建代理对象
        return (proxyObject)enhancer.create();
    }

    @Override
    public Object intercept(Object o, Method method, Object[] objects. MethodProxy methodProxy) {
        System.out.println("收取服务费");
        return method.invoke(station, objects);
    }
}

1.3：总结

三种代理的对比：

• JDK代理和CGLIB代理：使用CGLIB实现动态代理，CGLIB底层采用ASM字节码生成框架，使用字节码技术生成代理类，在JDK1.6之前比使用Java反射效率要高。唯一需要注意的是，CGLIB不能对声明为final的类或者方法进行代理，因为CGLIB原理是动态生成被代理类的子类。在JDK1.6、JDK1.7、JDK1.8逐步对JDK动态代理优化之后，在调用次数较少的情况下，JDK代理效率高于CGLIB代理效率，只有当进行大量调用的时候，JDK1.6和JDK1.7比CGLIB代理效率低一点，但是到JDK1.8的时候，JDK代理效率高于CGLib代理。所以如果有接口使用JDK动态代理，如果没有接口使用CGLIB代理。
• 动态代理和静态代理：动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理(InvocationHandler.invoke)。这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。如果接口增加一个方法，静态代理模式除了所有实现类需要实现这个方法外，所有代理类也需要实现此方法。增加了代码维护的复杂度。而动态代理不会出现该问题。

代理模式的优点：

• 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用
• 代理对象可以扩展目标对象的功能
• 代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度

代理模式的缺点：

• 增加了系统的复杂度

使用场景：

• 远程代理（Remote Proxy）：本地服务通过网络请求远程服务。为了实现本地到远程的通信，我们需要实现网络通信，处理其中可能的异常。为良好的代码设计和可维护性，我们将网络通信部分隐藏起来，只暴露给本地服务一个接口，通过该接口即可访问远程服务提供的功能，而不必过多关心通信部分的细节。
• 虚拟代理（Virtual Proxy）：在需要创建开销很大对象时缓存对象信息
• 保护代理（Protection Proxy）：控制对原始对象的访问。如果需要，可以给不同的用户提供不同级别的使用权限。
• 智能引用代理（Smart Reference Proxy）：当一个对象被引用时，提供一些额外的操作，例如记录访问的流量和次数等
• 防火墙代理（Firewall Proxy）：当你将浏览器配置成使用代理功能时，防火墙就将你的浏览器的请求转给互联网;当互联网返回响应时，代理服务器再把它转给你的浏览器。

二：适配器模式

如果去欧洲国家去旅游的话，他们的插座如下图最左边，是欧洲标准。而我们使用的插头如下图最右边的。因此我们的笔记本电脑，手机在当地不能直接充电。所以就需要一个插座转换器，转换器第1面插入当地的插座，第2面供我们充电，这样使得我们的插头在当地能使用。生活中这样的例子很多，手机充电器（将220x转换为5x的电压)，读卡器等，其实就是使用到了适配器模式。

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

适用场合：

• 使用一个已存在的类，而它的接口不符合要求
• 创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作
• 使用一些已经存在的子类，但不可能通过子类化以匹配各自接口。对象适配器可以适配它的父类接口

适配器模式包含以下主要角色：

• 目标接口：当前系统业务所期待的接口，它可以是抽象类或接口
• 适配者类：它是被访问和适配的现存组件库中的组件接口
• 适配器类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者

适配器模式分为类适配器模式和对象适配器模式，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

2.1：类适配器

实现方式：定义一个适配器类来实现当前系统的业务接口，同时又继承现有组件库中已经存在的组件。

例如，现有一台电脑只能读取SD卡，而要读取TF卡中的内容的话就需要使用到适配器模式。创建一个读卡器，将TF卡中的内容读取出来。代码如下：

public class AdapterDemo1 {
    public static void main(String[] args) {
        Computer computer = new Computer();
        String msg = computer.readSD(new SDAdapterTF());
        System.out.println(msg);
    }
}

interface TFCard {
    String readTF();

    void writeTF(String msg);
}

// 具体TF卡
class TFCardImpl implements TFCard {
    @Override
    public String readTF() {
        return "hello TFCard";
    }

    @Override
    public void writeTF(String msg) {
        System.out.println("TFCard write msg：" + msg);
    }
}

// 目标接口
interface SDCard {
    String readSD();

    void writeSD(String msg);
}

// 具体SD卡
class SDCardImpl implements SDCard {

    @Override
    public String readSD() {
        return "hello SDCard";
    }

    @Override
    public void writeSD(String msg) {
        System.out.println("SDCard write msg：" + msg);
    }
}

// 计算机类
class Computer {
    // 从SD卡中读取数据
    public String readSD(SDCard sdCard) {
        return sdCard.readSD();
    }
}

// 适配器类
class SDAdapterTF extends TFCardImpl implements SDCard {
    @Override
    public String readSD() {
        return readTF();
    }

    @Override
    public void writeSD(String msg) {
        writeTF(msg);
    }
}

类适配器模式违背了合成复用原则。类适配器是客户类有一个接口规范的情况下可用，反之不可用。

2.2：对象适配器

实现方式：对象适配器模式可采用将现有组件库中已经实现的组件引入适配器类中，该类同时实现当前系统的业务接口。

改进上述读卡器案例，代码如下：

public class AdapterDemo2 {
    public static void main(String[] args) {
        Computer2 computer = new Computer2();
        String msg = computer.readSD(new SDAdapterTF2(new TFCardImpl2()));
        System.out.println(msg);
    }
}

interface TFCard2 {
    String readTF();

    void writeTF(String msg);
}

// 具体TF卡
class TFCardImpl2 implements TFCard2 {
    @Override
    public String readTF() {
        return "hello TFCard";
    }

    @Override
    public void writeTF(String msg) {
        System.out.println("TFCard write msg：" + msg);
    }
}

// 目标接口
interface SDCard2 {
    String readSD();

    void writeSD(String msg);
}

// 具体SD卡
class SDCardImpl2 implements SDCard2 {

    @Override
    public String readSD() {
        return "hello SDCard";
    }

    @Override
    public void writeSD(String msg) {
        System.out.println("SDCard write msg：" + msg);
    }
}

// 计算机类
class Computer2 {
    // 从SD卡中读取数据
    public String readSD(SDCard2 sdCard) {
        return sdCard.readSD();
    }
}

// 适配器类
class SDAdapterTF2 implements SDCard2 {
    // 声明适配者类
    private final TFCard2 tfCard;

    public SDAdapterTF2(TFCard2 tfCard) {
        this.tfCard = tfCard;
    }

    @Override
    public String readSD() {
        return tfCard.readTF();
    }

    @Override
    public void writeSD(String msg) {
        tfCard.writeTF(msg);
    }
}

三：装饰者模式

我们先来看一个快餐店的例子。快餐店有炒面、炒饭这些快餐，可以额外附加鸡蛋、火腿、培根这些配菜，当然加配菜需要额外加钱，每个配菜的价钱通常不太一样，那么计算总价就会显得比较麻烦。

而装饰者模式(Decorator Pattern)，就是在不改变对象结构的情况下，动态地给该对象增加一些职责(即增加其额外功能)的模式。

装饰者模式中的角色

• 抽象构件角色：定义一个抽象接口以规范准备接收附加职责的对象
• 具体构件角色：实现抽象构件，通过装饰角色为其添加一些职责
• 抽象装饰角色：继承或实现抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能
• 具体装饰角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任

示例代码如下：

public class DecoratorDemo1 {
    public static void main(String[] args) {
        // 点一份炒饭
        FastFood food = new FriedRice();
        System.out.println(food.getDesc() + "的价格：" + food.cost());

        // 再加一份鸡蛋
        food = new Egg(food);
        System.out.println(food.getDesc() + "的价格：" + food.cost());

        // 再加一份培根
        food = new Bacon(food);
        System.out.println(food.getDesc() + "的价格：" + food.cost());
    }
}

abstract class FastFood {
    private float price;
    private String desc;

    public FastFood() {}

    public FastFood(float price, String desc) {
        this.price = price;
        this.desc = desc;
    }

    public float getPrice() {
        return price;
    }

    public void setPrice(float price) {
        this.price = price;
    }

    public String getDesc() {
        return desc;
    }

    public void setDesc(String desc) {
        this.desc = desc;
    }

    public abstract float cost();
}

// 炒饭
class FriedRice extends FastFood {
    public FriedRice() {
        super(10, "炒饭");
    }

    @Override
    public float cost() {
        return getPrice();
    }
}

// 炒面
class FriedNoodles extends FastFood {
    public FriedNoodles() {
        super(12, "炒面");
    }

    @Override
    public float cost() {
        return getPrice();
    }
}

// 装饰类
abstract class Garnish extends FastFood {
    // 声明快餐类的变量
    private FastFood fastFood;

    public FastFood getFastFood() {
        return fastFood;
    }

    public void setFastFood(FastFood fastFood) {
        this.fastFood = fastFood;
    }

    public Garnish(FastFood fastFood, float price, String desc) {
        super(price, desc);
        this.fastFood = fastFood;
    }
}

// 配料类（鸡蛋）
class Egg extends Garnish {

    public Egg(FastFood fastFood) {
        super(fastFood, 1, "鸡蛋");
    }

    @Override
    public float cost() {
        // 计算价格
        return getPrice() + getFastFood().cost();
    }

    @Override
    public String getDesc() {
        return super.getDesc() + getFastFood().getDesc();
    }
}

// 配料类（培根）
class Bacon extends Garnish {

    public Bacon(FastFood fastFood) {
        super(fastFood, 2, "培根");
    }

    @Override
    public float cost() {
        // 计算价格
        return getPrice() + getFastFood().cost();
    }

    @Override
    public String getDesc() {
        return super.getDesc() + getFastFood().getDesc();
    }
}

装饰者模式的好处：

• 装饰者模式可以带来比继承更加灵活性的扩展功能，使用更加方便，可以通过组合不同的装饰者对象来获取具有不同行为状态的多样化的结果。装饰者模式比继承更具良好的扩展性，完美的遵循开闭原则，继承是静态的附加责任，装饰者则是动态的附加责任。
• 装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

使用场景：

• 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时使用。不能采用继承的情况主要有两类：
  • 第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长
  • 第二类是因为类定义不能继承(如final类)
• 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
• 当对象的功能要求可以动态地添加，也可以再动态地撤销时。

四：桥接模式

现在有一个需求，需要创建不同的图形，并且每个图形都有可能会有不同的颜色。我们可以利用继承的方式来设计类的关系：

我们可以发现有很多的类，假如我们再增加一个形状或再增加一种颜色，就需要创建更多的类。

试想，在一个有多种可能会变化的维度的系统中，用继承方式会造成类爆炸，扩展起来不灵活。每次在一个维度上新增一个具体实现都要增加多个子类。为了更加灵活的设计系统，我们此时可以考虑使用桥接模式。

桥接(Bridge)模式的定义：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

桥接模式包含以下主要角色：

• 抽象化(Abstraction)角色：定义抽象类，并包含一个对实现化对象的引用。
• 扩展抽象化(Refined Abstraction)角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
• 实现化(Implementor)角色：定义实现化角色的接口，供扩展抽象化角色调用。具体实现化(concrete Implementor)角色：给出实现化角色接口的具体实现。

以下是一个案例。需要开发一个跨平台视频播放器，可以在不同操作系统平台(如windows、Mac、Linux等)上播放多种格式的视频文件，常见的视频格式包括RMVB、AVI、WMV等。该播放器包含了两个维度，适合使用桥接模式。

public class BridgeDemo {
    public static void main(String[] args) {
        // 创建Mac系统对象
        OperatingSystem system = new Mac(new AviFile());
        system.play("三体");
    }
}

// 视频文件接口
interface VideoFile {
    // 解码内容
    void decode(String fileName);
}

// Avi格式视频文件类
class AviFile implements VideoFile {
    @Override
    public void decode(String fileName) {
        System.out.println("avi视频文件：" + fileName);
    }
}

// Rmvb格式视频文件类
class RmvbFile implements VideoFile {
    @Override
    public void decode(String fileName) {
        System.out.println("Rmvb视频文件：" + fileName);
    }
}

// 抽象操作系统类
abstract class OperatingSystem {
    // 声明videoFile变量
    protected VideoFile videoFile;

    public OperatingSystem(VideoFile videoFile) {
        this.videoFile = videoFile;
    }

    public abstract void play(String fileName);
}

// Windows操作系统
class Windows extends OperatingSystem {
    public Windows(VideoFile videoFile) {
        super(videoFile);
    }

    @Override
    public void play(String fileName) {
        videoFile.decode(fileName);
    }
}

// Mac操作系统
class Mac extends OperatingSystem {
    public Mac(VideoFile videoFile) {
        super(videoFile);
    }

    @Override
    public void play(String fileName) {
        videoFile.decode(fileName);
    }
}

桥接模式的优点：

• 提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。如：如果现在还有一种视频文件类型wmv，我们只需要再定义一个类实现videoFile接口即可，其他类不需要发生变化。
• 实现细节对客户透明

使用场景：

• 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。
• 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
• 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。

五：外观模式

有些人可能炒过股票，但其实大部分人都不太懂，这种没有足够了解证券知识的情况下做股票是很容易亏钱的，刚开始炒股肯定都会想，如果有个懂行的帮帮手就好，其实基金就是个好帮手，支付宝里就有许多的基金，它将投资者分散的资金集中起来，交由专业的经理人进行管理，投资于股票、债券、外汇等领域，而基金投资的收益归持有者所有，管理机构收取一定比例的托管管理费用。

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

外观(Facade)模式主要包含以下主要角色：

• 外观(Facade)角色：为多个子系统对外提供一个共同的接口。
• 子系统(Sub System)角色：实现系统的部分功能，客户可以通过外观角色访问它。

以下是一个例题：小明的爷爷已经60岁了，一个人在家生活：每次都需要打开灯、打开电视、打开空调；睡觉时关闭灯、关闭电视、关闭空调；操作起来都比较麻烦。所以小明给爷爷买了智能音箱，可以通过语音直接控制这些智能家电的开启和关闭。

代码如下：

public class FacadeDemo {
    public static void main(String[] args) {
        SmartApplicationFacade facade = new SmartApplicationFacade();
        facade.say("打开家电");
        System.out.println("-----------------");
        facade.say("关闭家电");
    }
}

// 家具——灯
class Light {
    public void on() {
        System.out.println("打开灯。。。");
    }

    public void off() {
        System.out.println("关闭灯。。。");
    }
}

// 家具——电视
class TV {
    public void on() {
        System.out.println("打开电视。。。");
    }

    public void off() {
        System.out.println("关闭电视。。。");
    }
}

// 外观角色——智能音箱
class SmartApplicationFacade {
    private Light light;
    private TV tv;

    public SmartApplicationFacade() {
        light = new Light();
        tv = new TV();
    }

    private void on() {
        light.on();
        tv.on();
    }

    private void off() {
        light.off();
        light.off();
    }

    public void say(String msg) {
        if (msg.contains("打开")) {
            on();
        } else if (msg.contains("关闭")) {
            off();
        } else {
            System.out.println("我还听不懂");
        }
    }
}

外观模式的优点：

• 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
• 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。

外观模式的缺点：

• 不符合开闭原则，修改很麻烦

使用场景：

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

六：组合模式

下图我们可以看做是一个文件系统，对于这样的结构我们称之为树形结构。在树形结构中可以通过调用某个方法来遍历整个树，当我们找到某个叶子节点后，就可以对叶子节点进行相关的操作。可以将这颗树理解成一个大的容器，容器里面包含很多的成员对象，这些成员对象即可是容器对象也可以是叶子对象。但是由于容器对象和叶子对象在功能上面的区别，使得我们在使用的过程中必须要区分容器对象和叶子对象，但是这样就会给客户带来不必要的麻烦，作为客户而已，它始终希望能够一致的对待容器对象和叶子对象。

组合模式又名部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。

组合模式主要包含三种角色：

• 抽象根节点(Component)：定义系统各层次对象的共有方法和属性，可以预先定义一些默认行为和属性。
• 树枝节点(Composite)：定义树枝节点的行为，存储子节点，组合树枝节点和叶子节点形成一个树形结构。
• 叶子节点(Leaf)：叶子节点对象，其下再无分支，是系统层次遍历的最小单位。

以下是一个案例：如下图，我们在访问别的一些管理系统时，经常可以看到类似的菜单。一个菜单可以包含菜单项(菜单项是指不再包含其他内容的菜单条目)，也可以包含带有其他菜单项的菜单，因此使用组合模式描述菜单就很恰当，我们的需求是针对一个菜单，打印出其包含的所有菜单!及菜单项的名称。

代码如下：

public class CombinationDemo {
    public static void main(String[] args) {
        MenuComponent menu00 = new Menu("系统管理", 0);
        MenuComponent menu10 = new Menu("菜单管理", 1);
        MenuComponent menu11 = new Menu("权限配置", 1);
        MenuComponent menu12 = new Menu("角色管理", 1);
        menu00.add(menu10);
        menu00.add(menu11);
        menu00.add(menu12);

        menu10.add(new MenuItem("页面访问", 2));
        menu10.add(new MenuItem("展开菜单", 2));
        menu10.add(new MenuItem("编辑菜单", 2));
        menu10.add(new MenuItem("删除菜单", 2));
        menu10.add(new MenuItem("新增菜单", 2));

        menu11.add(new MenuItem("页面访问", 2));
        menu11.add(new MenuItem("保存提交", 2));

        menu12.add(new MenuItem("页面访问", 2));
        menu12.add(new MenuItem("新增角色", 2));
        menu12.add(new MenuItem("修改角色", 2));

        menu00.print();
    }
}

// 菜单组件：属于抽象根节点
abstract class MenuComponent {
    // 菜单组件的名称
    protected String name;
    // 菜单组件的层级
    protected int level;

    // 添加子菜单
    public void add(MenuComponent menuComponent) {
        throw new UnsupportedOperationException();
    }

    // 移除子菜单
    public void remove(MenuComponent menuComponent) {
        throw new UnsupportedOperationException();
    }

    // 获取指定的子菜单
    public MenuComponent getChild(int index) {
        throw new UnsupportedOperationException();
    }

    // 获取菜单或者菜单项的名称
    public String getName() {
        return name;
    }

    // 打印菜单名称的方法(包含子菜单和子菜单项)
    public abstract void print();
}

// 菜单类：属于树枝节点
class Menu extends MenuComponent {
    // 菜单可以有多个子菜单或者子菜单项
    private final List<MenuComponent> menuComponentList = new ArrayList<>();

    public Menu(String name, int level) {
        this.name = name;
        this.level = level;
    }

    @Override
    public void add(MenuComponent menuComponent) {
        menuComponentList.add(menuComponent);
    }

    @Override
    public void remove(MenuComponent menuComponent) {
        menuComponentList.remove(menuComponent);
    }

    @Override
    public MenuComponent getChild(int index) {
        return menuComponentList.get(index);
    }

    @Override
    public void print() {
        for (int i = 0; i < level; i++) {
            System.out.print("--");
        }

        // 打印菜单名称
        System.out.println(name);

        // 打印子菜单或者子菜单项名称
        for (MenuComponent component : menuComponentList) {
            component.print();
        }
    }
}

// 菜单项类：属于叶子节点
class MenuItem extends MenuComponent {
    public MenuItem(String name, int level) {
        this.name = name;
        this.level = level;
    }

    @Override
    public void print() {
        for (int i = 0; i < level; i++) {
            System.out.print("--");
        }

        System.out.println(name);
    }
}

在使用组合模式时，根据抽象构件类的定义形式，我们可将组合模式分为透明组合模式和安全组合模式两种形式。

• 透明组合模式
  • 抽象根节点角色中声明了所有用于管理成员对象的方法，比如在示例中Menucomponent声明了add、remove、getChild方法，这样做的好处是确保所有的构件类都有相同的接口。透明组合模式也是组合模式的标准形式。
  • 缺点是不够安全，因为叶子对象和容器对象在本质上是有区别的，叶子对象不可能有下一个层次的对象，即不可能包含成员对象，因此为其提供add()、remove()等方法是没有意义的，这在编译阶段不会出错，但在运行阶段如果调用这些方法可能会出错(如果没有提供相应的错误处理代码)
• 安全组合模式
  • 在抽象构件角色中没有声明任何用于管理成员对象的方法，而是在树枝节点Menu类中声明并实现这些方法。
  • 缺点是不够透明，因为叶子构件和容器构件具有不同的方法，且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义，因此客户端不能完全针对抽象编程，必须有区别地对待叶子构件和容器构件。

组合模式的优点：

• 组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，它让客户端忽略了层次的差异，方便对整个层次结构进行控制。
• 客户端可以一致地使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了客户端代码。
• 在组合模式中增加新的树枝节点和叶子节点都很方便，无须对现有类库进行任何修改，符合"开闭原则”。
• 组合模式为树形结构的面向对象实现提供了一种灵活的解决方案，通过叶子节点和树枝节点的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。

使用场景：组合模式正是应树形结构而生，所以组合模式的使用场景就是出现树形结构的地方。比如：文件目录显示，多级目录呈现等树形结构数据的操作。

七：享元模式

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

享元(Flyweight)模式存在以下两种状态，享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。

• 内部状态，不会随着环境的改变而改变的可共享部分。
• 外部状态，指随环境改变而改变的不可以共享的部分。

享元模式主要有以下角色：

• 抽象享元角色(Flyweight)：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态)，同时也可以通过这些方法来设置外部数据（外部状态)。
• 具体享元(Concrete Flyweight)角色：它实现了抽象享元类，称为享元对象；在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象。
• 非享元(Unsharable Flyweight)角色：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类；当需要一个非共享具体享元类的对象时可以直接通过实例化创建。
• 享元工厂(Flyweight Factory)角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检查系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

以下是一个例题：下图是众所周知的俄罗斯方块中的一个个方块，如果在俄罗斯方块这个游戏中，每个不同的方块都是一个实例对象，这些对象就要占用很多的内存空间，下面利用享元模式进行实现。

代码如下：

public class FlyweightDemo {
    public static void main(String[] args) {
        BoxFactory instance = BoxFactory.getInstance();
        instance.getShape("I").display("灰色");
        instance.getShape("L").display("红色");
        instance.getShape("O").display("绿色");
    }
}

// 抽象享元角色
abstract class AbstractBox {
    // 获取图形的方法
    public abstract String getShape();

    // 显示图形及颜色
    public void display(String color) {
        System.out.println("方块形状：" + getShape() + "，颜色：" + color);
    }
}

// 具体享元——I图形类
class IBox extends AbstractBox {
    @Override
    public String getShape() {
        return "I";
    }
}

// 具体享元——L图形类
class LBox extends AbstractBox {
    @Override
    public String getShape() {
        return "L";
    }
}

// 具体享元——O图形类
class OBox extends AbstractBox {
    @Override
    public String getShape() {
        return "O";
    }
}

// 工厂类：将该类设置为单例
class BoxFactory {
    private HashMap<String, AbstractBox> map;
    private static BoxFactory factory = new BoxFactory();

    // 在构造方法中进行初始化操作
    private BoxFactory() {
        map = new HashMap<>();
        map.put("I", new IBox());
        map.put("L", new LBox());
        map.put("O", new OBox());
    }

    // 获取实例
    public static BoxFactory getInstance() {
        return factory;
    }

    // 根据名称获取图形对象
    public AbstractBox getShape(String name) {
        return map.get(name);
    }
}

享元模式的优点：

• 极大减少内存中相似或相同对象数量，节约系统资源，提供系统性能
• 享元模式中的外部状态相对独立，且不影响内部状态

享元模式的缺点：

• 为了使对象可以共享，需要将享元对象的部分状态外部化，分离内部状态和外部状态，使程序逻辑复杂

使用场景:

• 一个系统有大量相同或者相似的对象，造成内存的大量耗费。
• 对象的大部分状态都可以外部化，可以将这些外部状态传入对象中。
• 在使用享元模式时需要维护一个存储享元对象的享元池，而这需要耗费一定的系统资源，因此，应当在需要多次重复使用享元对象时才值得使用享元模式。