标签：一篇 对象 void 代理 模式 String 设计模式 public 结构型

一篇文章带你了解设计模式——结构型模式

在之前的文章中我们已经介绍了设计模式中的创建者模式

下面我们来学习第二种类型的设计模式，结构型模式描述如何将类或对象按某种布局组成更大的结构

它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。

下面我们会介绍到七种结构型模式：

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

代理模式

首先我们先来介绍第一种结构型模式代理模式

代理模式简述

代理模式概念：

• 由于某些原因需要给某对象提供一个代理以控制对该对象的访问。
• 这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介。

代理模式分类：

• Java中的代理按照代理类生成时机不同又分为静态代理和动态代理。
• 静态代理代理类在编译期就生成，而动态代理代理类则是在Java运行时动态生成；动态代理又有JDK代理和CGLib代理两种。

代理模式结构

代理（Proxy）模式分为三种角色：

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

我们对上述角色做一个简单举例：

• 抽象主题类：一个抽象类，具有卖票sell抽象方法
• 真实主题类：火车售票站，负责售卖火车票，具有卖票sell方法
• 代理类：地方代售处，负责代售火车票，具有sell方法，但sell方法中调用了真实主题类（火车售票站）的sell方法

静态代理介绍

我们通过一个简单的例子来介绍动态代理：

具体分析：

/*

【例】火车站卖票

如果要买火车票的话，需要去火车站买票，坐车到火车站，排队等一系列的操作，显然比较麻烦。
而火车站在多个地方都有代售点，我们去代售点买票就方便很多了。这个例子其实就是典型的代理模式，火车站是目标对象，代售点是代理对象。

*/

/* 代码展示 */

// 抽象主题类： 卖票接口
public interface SellTickets {
    void sell();
}

// 真实主题类： 火车站  
// 火车站具有卖票功能，所以需要实现SellTickets接口
public class TrainStation implements SellTickets {

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

// 代理类： 代售点
// 代售点具有卖票功能，所以需要实现SellTickets接口
public class ProxyPoint implements SellTickets {

    // 代售点最终还是使用的真实主题类，所以需要创建一个真实主题类，并调用其方法
    private TrainStation station = new TrainStation();

    // 在代理类中可以做一些功能增强操作
    public void sell() {
        System.out.println("代理点收取一些服务费用");
        station.sell();
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        ProxyPoint pp = new ProxyPoint();
        pp.sell();
    }
}

动态代理JDK

我们同样采用上面的案例来进行JDK动态代理说明：

具体分析：

/*

JDK动态代理说明：
	Java中提供了一个动态代理类Proxy，Proxy并不是我们上述所说的代理对象的类
	而是提供了一个创建代理对象的静态方法（newProxyInstance方法）来获取代理对象。

*/

/* 代码展示 */

//卖票接口
public interface SellTickets {
    void sell();
}

//火车站  火车站具有卖票功能，所以需要实现SellTickets接口
public class TrainStation implements SellTickets {

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

//代理工厂，用来创建代理对象
public class ProxyFactory {

    // 我们需要一个真实主题类来获得相关信息
    private TrainStation station = new TrainStation();

    // 创建一个方法，用于生成代理对象
    public SellTickets getProxyObject() {
        
        //使用Proxy获取代理对象
        
        /*
            newProxyInstance()方法参数说明：
                ClassLoader loader ： 类加载器，用于加载代理类，使用真实对象的类加载器即可
                Class<?>[] interfaces ： 真实对象所实现的接口，代理模式真实对象和代理对象实现相同的接口
                InvocationHandler h ： 代理对象的调用处理程序
         */
        
        SellTickets sellTickets = (SellTickets) Proxy.newProxyInstance(station.getClass().getClassLoader(),
                station.getClass().getInterfaces(),
                new InvocationHandler() {
                    /*
                    	InvocationHandler就是调用由factory工厂获得的代理对象调用方法后所执行的内容
                    	采用匿名内部类的形式重写invoke方法，下面书写基本为固定形式
                    	
                        InvocationHandler中invoke方法参数说明：
                            proxy ： 代理对象
                            method ： 对应于在代理对象上调用的接口方法的 Method 实例
                            args ： 代理对象调用接口方法时传递的实际参数
                     */
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

                        // 增强操作
                        System.out.println("代理点收取一些服务费用(JDK动态代理方式)");
                        
                        //执行真实对象（代理对象调用什么方法就会对应调用station的方法，并传入args参数）
                        Object result = method.invoke(station, args);
                        return result;
                    }
                });
        return sellTickets;
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        //获取代理对象
        ProxyFactory factory = new ProxyFactory();
        
        SellTickets proxyObject = factory.getProxyObject();
        proxyObject.sell();
    }
}

那么我们给出一个问题：

• ProxyFactory是代理类吗？
• ProxyFactory不是代理模式中所说的代理类，而代理类是程序在运行过程中动态的在内存中生成的类。

所以我们需要查看真正的代理类的内部结构：

//程序运行过程中动态生成的代理类
public final class $Proxy0 extends Proxy implements SellTickets {
    private static Method m3;

    public $Proxy0(InvocationHandler invocationHandler) {
        super(invocationHandler);
    }

    // 这里采用反射获得方法
    static {
        m3 = Class.forName("com.itheima.proxy.dynamic.jdk.SellTickets").getMethod("sell", new Class[0]);
    }

    // 这里对不同的方法调用不同的真实主题类的方法
    public final void sell() {
        this.h.invoke(this, m3, null);
    }
}

//Java提供的动态代理相关类
public class Proxy implements java.io.Serializable {
	protected InvocationHandler h;
	 
	protected Proxy(InvocationHandler h) {
        this.h = h;
    }
}

//代理工厂类
public class ProxyFactory {

    private TrainStation station = new TrainStation();

    public SellTickets getProxyObject() {
        SellTickets sellTickets = (SellTickets) Proxy.newProxyInstance(station.getClass().getClassLoader(),
                station.getClass().getInterfaces(),
                new InvocationHandler() {
                    
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

                        System.out.println("代理点收取一些服务费用(JDK动态代理方式)");
                        Object result = method.invoke(station, args);
                        return result;
                    }
                });
        return sellTickets;
    }
}


//测试访问类
public class Client {
    public static void main(String[] args) {
        //获取代理对象
        ProxyFactory factory = new ProxyFactory();
        SellTickets proxyObject = factory.getProxyObject();
        proxyObject.sell();
    }
}

最后我们给出JDK动态代理的逻辑顺序：

1. 在测试类中通过代理对象调用sell()方法
2. 根据多态的特性，执行的是代理类（$Proxy0）中的sell()方法
3. 代理类（$Proxy0）中的sell()方法中又调用了InvocationHandler接口的子实现类对象的invoke方法
4. invoke方法通过反射执行了真实对象所属类(TrainStation)中的sell()方法

动态代理CGLIB

我们首先简单介绍一下CgLIB动态代理：

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

我们同样采用之前的案例，但这次我们不需要卖票接口：

/* jar包展示*/

<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>2.2.2</version>
</dependency>
    
/* 代码展示 */
    
// 火车站
public class TrainStation {

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

// 代理工厂
// 这里需要继承MethodInterceptor接口，因为我们下面的setCallback方法需要一个MethodInterceptor
// 我们直接在本类中重写MethodInterceptor的intercept方法并传入this本身即可
public class ProxyFactory implements MethodInterceptor {

    private TrainStation target = new TrainStation();

    public TrainStation getProxyObject() {
        //创建Enhancer对象，类似于JDK动态代理的Proxy类，下一步就是设置几个参数
        Enhancer enhancer =new Enhancer();
        //设置父类的字节码对象
        enhancer.setSuperclass(target.getClass());
        //设置回调函数（执行函数）
        enhancer.setCallback(this);
        //创建代理对象
        TrainStation obj = (TrainStation) enhancer.create();
        return obj;
    }

    /*
        intercept方法参数说明：
            o ： 代理对象
            method ： 真实对象中的方法的Method实例
            args ： 实际参数
            methodProxy ：代理对象中的方法的method实例
     */
    public TrainStation intercept(Object o, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
        // 增强操作
        System.out.println("代理点收取一些服务费用(CGLIB动态代理方式)");
        // 调用目标对象的方法，等价于target.sell方法;
        Object result = method.invoke(o,args);
        return result;
    }
}

// 测试类
public class Client {
    public static void main(String[] args) {
        //创建代理工厂对象
        ProxyFactory factory = new ProxyFactory();
        //获取代理对象
        TrainStation proxyObject = factory.getProxyObject();

        proxyObject.sell();
    }
}

代理模式比较

首先我们给出静态代理和动态代理的区别：

• 动态代理最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理InvocationHandler.invoke；这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。
• 如果接口增加一个方法，静态代理模式除了所有实现类需要实现这个方法外，所有代理类也需要实现此方法。增加了代码维护的复杂度。而动态代理不会出现该问题。

然后我们给出JDK动态代理和CGLIB动态代理的区别：

• 使用CGLib实现动态代理，CGLib底层采用ASM字节码生成框架，使用字节码技术生成代理类，在JDK1.6之前比使用Java反射效率要高。唯一需要注意的是，CGLib不能对声明为final的类或者方法进行代理，因为CGLib原理是动态生成被代理类的子类。

• 如果有接口使用JDK动态代理，如果没有接口使用CGLIB代理。

代理模式分析

我们首先给出代理模式的适用场景：

• 远程（Remote）代理

  本地服务通过网络请求远程服务。为了实现本地到远程的通信，我们需要实现网络通信，处理其中可能的异常。为良好的代码设计和可维护性，我们将网络通信部分隐藏起来，只暴露给本地服务一个接口，通过该接口即可访问远程服务提供的功能，而不必过多关心通信部分的细节。

• 防火墙（Firewall）代理

  当你将浏览器配置成使用代理功能时，防火墙就将你的浏览器的请求转给互联网；当互联网返回响应时，代理服务器再把它转给你的浏览器。

• 保护（Protect or Access）代理

  控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。

同时我们给出代理模式的优点：

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

最后我们给出代理模式的缺点：

• 增加了系统的复杂度；

适配器模式

接下来我们来介绍适配器模式

适配器模式简述

首先我们给出适配器模式的概述：

• 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
• 例如我们的插座是三角插座，但是我们的插头是二头插头，这时我们就需要一个三角转两头的适配器来帮助我们插上插头

适配器模式大致分为两种：

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

适配器模式结构

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

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

类适配器案例

我们通过一个案例来讲述类适配器：

具体分析：

/*

【例】读卡器

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

分析：

1. Computer只能接收SDCard类型的类，并调用其readSD方法

2. SDCard是一个接口，SDCardImpl是其实现类

3. TFCard是一个接口，TFCardImpl是其实现类

4. SDAdapter是适配器，我们如果希望发采用Computer去直接使用TFCard，那么我们就需要一个中介，但是Computer需要使用SDCard作为参数，所以我们的SDAdapter需要继承SDCard接口或者类；又由于我们需要去使用TFCard，所以我们需要继承TFCard来直接使用其方法

*/

/* 代码展示 */

//电脑类
public class Computer {

    public String readSD(SDCard sdCard) {
        if(sdCard == null) {
            throw new NullPointerException("sd card null");
        }
        return sdCard.readSD();
    }
}

//SD卡的接口
public interface SDCard {
    //读取SD卡方法
    String readSD();
    //写入SD卡功能
    void writeSD(String msg);
}

//SD卡实现类
public class SDCardImpl implements SDCard {
    public String readSD() {
        String msg = "sd card read a msg :hello word SD";
        return msg;
    }

    public void writeSD(String msg) {
        System.out.println("sd card write msg : " + msg);
    }
}

//TF卡接口
public interface TFCard {
    //读取TF卡方法
    String readTF();
    //写入TF卡功能
    void writeTF(String msg);
}

//TF卡实现类
public class TFCardImpl implements TFCard {

    public String readTF() {
        String msg ="tf card read msg : hello word tf card";
        return msg;
    }

    public void writeTF(String msg) {
        System.out.println("tf card write a msg : " + msg);
    }
}

//定义适配器类（SD兼容TF）
public class SDAdapterTF extends TFCardImpl implements SDCard {

    // 我们的适配器继承SDCard接口，实现其readSD方法，使其调用TFCard的readTF方法
    public String readSD() {
        System.out.println("adapter read tf card ");
        return readTF();
    }

    public void writeSD(String msg) {
        System.out.println("adapter write tf card");
        writeTF(msg);
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        Computer computer = new Computer();
        SDCard sdCard = new SDCardImpl();
        System.out.println(computer.readSD(sdCard));

        System.out.println("------------");

        SDAdapterTF adapter = new SDAdapterTF();
        System.out.println(computer.readSD(adapter));
    }
}

但是类适配器模式违背了合成复用原则。

类适配器是客户类有一个接口规范的情况下可用，反之不可用。

对象适配器案例

我们同样采用之前的案例来讲解对象适配器：

具体分析：

/*

【例】读卡器

我们使用对象适配器模式将读卡器的案例进行改写。

分析：

1. 我们需要注意TFCard和SDAdapterTF的关系由继承关系变为了聚合关系

2. 我们即使没有SDCard接口，我们也可以直接继承SDCardImpl对象，因为我们不需要顾及TFCard了

*/

/* 代码展示 */

//创建适配器对象（SD兼容TF）
public class SDAdapterTF  implements SDCard {

    // 我们直接将TFcard作为参数
    private TFCard tfCard;

    // 我们需要有参构造，为了保证存在TFCard，使其能够调用readTF方法
    public SDAdapterTF(TFCard tfCard) {
        this.tfCard = tfCard;
    }

    public String readSD() {
        System.out.println("adapter read tf card ");
        return tfCard.readTF();
    }

    public void writeSD(String msg) {
        System.out.println("adapter write tf card");
        tfCard.writeTF(msg);
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        Computer computer = new Computer();
        SDCard sdCard = new SDCardImpl();
        System.out.println(computer.readSD(sdCard));

        System.out.println("------------");

        TFCard tfCard = new TFCardImpl();
        SDAdapterTF adapter = new SDAdapterTF(tfCard);
        System.out.println(computer.readSD(adapter));
    }
}

适配器适用场景

最后我们给出适配器的适用场景：

• 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
• 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。

装饰者模式

下面我们来介绍装饰者模式

装饰者模式简述

我们直接给出装饰者模式的概念：

• 指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式。

我们给出一个简单的例子：

• 我们在点餐时可以对餐品进行小料添加的操作，例如在炒米中添加火腿肠添加培根等操作

装饰者模式结构

装饰（Decorator）模式中的角色：

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

装饰者模式案例

我们通过一个简单的案例来介绍装饰者模式：

具体分析：

/*

我们使用装饰者模式对快餐店案例进行改进，体会装饰者模式的精髓。

我们首先介绍上述角色：

1. FastFood：快餐，抽象构件据角色

2. FriedRice，FriedNoodles：炒米炒面，具体构件角色

3. Garnish：小料，抽象装饰角色

4. Egg，Bacon：鸡蛋培根，具体装饰角色

我们可以注意到Garnish不仅继承了FastFood还聚合了FastFood，它所聚合的FastFood作为一个原型，自身FastFood作为一个装饰来完成增强操作

*/

/* 代码展示 */

//快餐接口
public abstract class FastFood {
    
    // 价格+描述
    private float price;
    private String desc;

    // 无参构造
    public FastFood() {
    }

    // 有参构造
    public FastFood(float price, String desc) {
        this.price = price;
        this.desc = desc;
    }

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

    public float getPrice() {
        return price;
    }

    public String getDesc() {
        return desc;
    }

    public void setDesc(String desc) {
        this.desc = desc;
    }
    
    //获取价格
    public abstract float cost();
}

//炒饭
public class FriedRice extends FastFood {

    // 有参构造（赋值）
    public FriedRice() {
        super(10, "炒饭");
    }

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

//炒面
public class FriedNoodles extends FastFood {

    // 有参构造（赋值）
    public FriedNoodles() {
        super(12, "炒面");
    }

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

//配料类（采用抽象类，继承FastFood使其具有FastFood的属性方法，创建独特的构造方法，使其在FastFood的基础上做增强操作）
public abstract class Garnish extends FastFood {

    // 内置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;
    }
}

//鸡蛋配料
public class Egg extends Garnish {

    // 添加方法，fastFood是构件，然后后面是装饰者
    public Egg(FastFood fastFood) {
        super(fastFood,1,"鸡蛋");
    }

    // 计算开销，计算构件开销+自身装饰者开销
    public float cost() {
        return getPrice() + getFastFood().getPrice();
    }

    // 给出具体描述，构件描述+装饰者描述
    @Override
    public String getDesc() {
        return super.getDesc() + getFastFood().getDesc();
    }
}

//培根配料
public class Bacon extends Garnish {

    public Bacon(FastFood fastFood) {

        super(fastFood,2,"培根");
    }

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

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

//测试类
public class Client {
    public static void main(String[] args) {
        //点一份炒饭
        FastFood food = new FriedRice();
        //花费的价格
        System.out.println(food.getDesc() + " " + food.cost() + "元");

        System.out.println("========");
        //点一份加鸡蛋的炒饭
        FastFood food1 = new FriedRice();

        food1 = new Egg(food1);
        //花费的价格
        System.out.println(food1.getDesc() + " " + food1.cost() + "元");

        System.out.println("========");
        //点一份加培根的炒面
        FastFood food2 = new FriedNoodles();
        food2 = new Bacon(food2);
        //花费的价格
        System.out.println(food2.getDesc() + " " + food2.cost() + "元");
    }
}

装饰者模式分析

首先我们给出装饰者模式的适用场景：

• 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

• 当对象的功能要求可以动态地添加，也可以再动态地撤销时。

• 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。

  不能采用继承的情况主要有两类：

  • 第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；
  • 第二类是因为类定义不能继承（如final类）

然后我们给出装饰者模式的优点：

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

装饰者模式区别

我们将装饰者模式和代理模式做一个简单的区分：

• 相同点：
  • 都要实现与目标类相同的业务接口
  • 在两个类中都要声明目标对象
  • 都可以在不修改目标类的前提下增强目标方法
• 不同点：
  • 目的不同
    装饰者是为了增强目标对象
    静态代理是为了保护和隐藏目标对象
  • 获取目标对象构建的地方不同
    装饰者是由外界传递进来，可以通过构造方法传递
    静态代理是在代理类内部创建，以此来隐藏目标对象

桥接模式

下面我们来介绍桥接模式

桥接模式简述

首先我们给出桥接模式的定义：

• 将抽象与实现分离，使它们可以独立变化。
• 它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

桥接模式结构

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

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

桥接模式案例

我们同样通过一个简单的案例来解释桥接模式：

具体分析：

/*

【例】视频播放器

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

*/

/* 代码展示 */

//视频文件 （实现化）
public interface VideoFile {
    void decode(String fileName);
}

//avi文件 （具体实现化）
public class AVIFile implements VideoFile {
    public void decode(String fileName) {
        System.out.println("avi视频文件："+ fileName);
    }
}
 
//rmvb文件 （具体实现化）
public class REVBBFile implements VideoFile {

    public void decode(String fileName) {
        System.out.println("rmvb文件：" + fileName);
    }
}

//操作系统版本 （抽象化角色）
public abstract class OperatingSystemVersion {

    // 内置一个实现化角色，后续子类可以调用该实现化角色的方法
    protected VideoFile videoFile;

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

    public abstract void play(String fileName);
}

//Windows版本 （扩展抽象化）
public class Windows extends OperatingSystem {

    public Windows(VideoFile videoFile) {
        super(videoFile);
    }

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

//mac版本 （扩展抽象化）
public class Mac extends OperatingSystemVersion {

    public Mac(VideoFile videoFile) {
        super(videoFile);
    }

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

//测试类
public class Client {
    public static void main(String[] args) {
        OperatingSystem os = new Windows(new AVIFile());
        os.play("战狼3");
    }
}

桥接模式分析

我们首先给出桥接模式的适用场景：

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

我们再给出桥接模式的好处：

• 桥接模式提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。

  如：如果现在还有一种视频文件类型wmv，我们只需要再定义一个类实现VideoFile接口即可，其他类不需要发生变化。

• 实现细节对客户透明

外观模式

下面我们来介绍外观模式

外观模式简述

首先我们来简单介绍一下外观模式：

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

我们举一个简单的例子：

• 当我们炒股时，我们需要去了解股票，股票有很多种，我们只有了解了才能去使用
• 但是在股票之外有基金，我们如果想要炒股，可以直接投入基金中，让基金帮我炒股
• 就好比Client借助了基金，即使不需要了解一个东西，我们也可以直接去使用该东西

外观模式结构

外观（Facade）模式包含以下主要角色：

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

外观模式案例

我们同样以一个简单的案例来解释外观模式：

具体分析：

/*

【例】智能家电控制

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

Client ： 顾客

SmartApplicancesFacade ： 智能音响 外观角色

Light，TV，AirCondition ： 家具 子系统角色

*/

/* 代码展示 */

//智能音箱
public class SmartAppliancesFacade {

    // 外观角色聚合所有子系统角色
    private Light light;
    private TV tv;
    private AirCondition airCondition;

    // 构造方法中进行初始化
    public SmartAppliancesFacade() {
        light = new Light();
        tv = new TV();
        airCondition = new AirCondition();
    }

    // 通过简单命令使外观角色一键控制所有子系统角色
    public void say(String message) {
        if(message.contains("打开")) {
            on();
        } else if(message.contains("关闭")) {
            off();
        } else {
            System.out.println("我还听不懂你说的！！！");
        }
    }

    //起床后一键开电器
    private void on() {
        System.out.println("起床了");
        light.on();
        tv.on();
        airCondition.on();
    }

    //睡觉一键关电器
    private void off() {
        System.out.println("睡觉了");
        light.off();
        tv.off();
        airCondition.off();
    }
}

//灯类
public class Light {
    public void on() {
        System.out.println("打开了灯....");
    }

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

//电视类
public class TV {
    public void on() {
        System.out.println("打开了电视....");
    }

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

//控制类
public class AirCondition {
    public void on() {
        System.out.println("打开了空调....");
    }

    public void off() {
        System.out.println("关闭了空调....");
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        //创建外观对象
        SmartAppliancesFacade facade = new SmartAppliancesFacade();
        //客户端直接与外观对象进行交互
        facade.say("打开家电");
        facade.say("关闭家电");
    }
}

外观模式分析

我们首先给出外观模式的适用场景：

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

然后我们给出外观模式的优点：

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

最后给出外观模式的缺点：

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

组合模式

下面我们来介绍组合模式

组合模式简述

首先我们来简单介绍一下组合模式：

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

组合模式结构

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

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

组合模式案例

我们首先给出案例的示例图：

然后我们给出上述案例的类图：

具体分析：

/*

【例】软件菜单

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

MenuComponent: 文件抽象类，里面会定义所有可能出现的方法，对于相同方法书写全部内容，对于非全包含的方法，采用throw异常的书写方法

Menu：文件夹具体类，由于文件夹比文件多一些方法，所以Menu会继承父类的共性方法，然后重写仅自己包含的方法

MenuItem： 文件具体类，由于是文件，方法较少，所以直接继承父类即可，针对一些无法实现的功能父类已经为我们封装了异常处理

*/

/* 代码展示 */

// 菜单组件  不管是菜单还是菜单项，都应该继承该类
public 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 i){
        throw new UnsupportedOperationException();
    }

    // 获取菜单名称（共性方法）
    public String getName(){
        return name;
    }

    public void print(){
        throw new UnsupportedOperationException();
    }
}

// 文件夹（重写只有自己存在的方法）
public class Menu extends MenuComponent {

    private List<MenuComponent> menuComponentList;

    public Menu(String name,int level){
        this.level = level;
        this.name = name;
        menuComponentList = new ArrayList<MenuComponent>();
    }

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

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

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

    @Override
    public void print() {

        for (int i = 1; i < level; i++) {
            System.out.print("--");
        }
        System.out.println(name);
        for (MenuComponent menuComponent : menuComponentList) {
            menuComponent.print();
        }
    }
}

// 文件（全部继承，部分方法以异常形式处理）
public class MenuItem extends MenuComponent {

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

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

组合模式分类

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

• 透明组合模式
• 安全组合模式

我们首先来介绍透明组合模式：

• 透明组合模式中，抽象根节点角色中声明了所有用于管理成员对象的方法，比如在示例中 MenuComponent 声明了add，remove， getChild 方法，这样做的好处是确保所有的构件类都有相同的接口。透明组合模式也是组合模式的标准形式。

• 透明组合模式的缺点是不够安全，因为叶子对象和容器对象在本质上是有区别的，叶子对象不可能有下一个层次的对象，即不可能包含成员对象，因此为其提供 add()、remove() 等方法是没有意义的，这在编译阶段不会出错，但在运行阶段如果调用这些方法可能会出错（如果没有提供相应的错误处理代码）

然后我们来介绍安全组合模式：

• 在安全组合模式中，在抽象构件角色中没有声明任何用于管理成员对象的方法，而是在树枝节点 Menu 类中声明并实现这些方法。
• 安全组合模式的缺点是不够透明，因为叶子构件和容器构件具有不同的方法，且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义，因此客户端不能完全针对抽象编程，必须有区别地对待叶子构件和容器构件。

组合模式分析

首先我们给出组合模式的适用场景：

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

最后我们给出组合模式的优点：

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

享元模式

最后我们来介绍享元模式

享元模式简述

首先我们来简单介绍一下享元模式：

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

享元模式结构

享元模式中存在以下两种状态：

• 内部状态：即不会随着环境的改变而改变的可共享部分。

• 外部状态：指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。

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

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

享元模式案例

我们以一个简单的案例来介绍享元模式：

具体分析：

/*

【例】俄罗斯方块

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

AbstractBox : 抽象方块，定义了方块的共性属性和行为，其中getShape就是共性方法，其中color就属于外部状态，根据外部因素产生变化

*/

/* 代码展示 */

// 抽象享元角色
public abstract class AbstractBox {
    public abstract String getShape();

    public void display(String color) {
        System.out.println("方块形状：" + this.getShape() + " 颜色：" + color);
    }
}

// 具体享元角色
public class IBox extends AbstractBox {

    @Override
    public String getShape() {
        return "I";
    }
}

public class LBox extends AbstractBox {

    @Override
    public String getShape() {
        return "L";
    }
}

public class OBox extends AbstractBox {

    @Override
    public String getShape() {
        return "O";
    }
}

// 工厂类，负责管理享元角色，由于工厂只有一个，这里以单例模式书写工厂类，采用内部类懒汉式单例模式
public class BoxFactory {

    // 存放享元对象，若不存在加入，若存在直接使用
    private static HashMap<String, AbstractBox> map;

    // 初始化
    private BoxFactory() {
        map = new HashMap<String, AbstractBox>();
        AbstractBox iBox = new IBox();
        AbstractBox lBox = new LBox();
        AbstractBox oBox = new OBox();
        map.put("I", iBox);
        map.put("L", lBox);
        map.put("O", oBox);
    }

    // get方法
    public static final BoxFactory getInstance() {
        return SingletonHolder.INSTANCE;
    }

    // 单例对象创建
    private static class SingletonHolder {
        private static final BoxFactory INSTANCE = new BoxFactory();
    }

    public AbstractBox getBox(String key) {
        return map.get(key);
    }
}

享元模式分析

首先我们给出享元模式的适用场景：

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

然后我们给出享元模式的优点：

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

最后给出享元模式的缺点：

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

结束语

关于结构型模式我们就介绍到这里，后面我会继续更新二十三种设计模式，希望能给你带来帮助~

附录

该文章属于学习内容，具体参考B站黑马程序员的Java设计模式详解

这里附上视频链接：1.设计模式-结构型模式概述_哔哩哔哩_bilibili

标签：一篇,对象,void,代理,模式,String,设计模式,public,结构型
From： https://www.cnblogs.com/qiuluoyuweiliang/p/17087391.html