设计模式——结构型

旧城等待， 2022-11-27 11:29 146阅读 0赞

### 文章目录 ###

*  结构型模式
 *   *  概念
     *  类型
 *  代理模式
 *   *  概念
     *  静态代理
     *   *  示例
         *  优缺点
     *  动态代理
     *   *  示例
         *  优缺点
     *  CGLIB代理
     *   *  示例
     *  代理模式使用场景
 *  桥接模式
 *   *  概念
     *  示例
     *  案例
 *  装饰者模式
 *  适配器模式
 *   *  应用实例
     *  代理、桥接、装饰器、适配器4种设计模式的区别
 *  门面模式
 *  组合模式
 *   *  示例
 *  享元模式
 *   *  使用场景
     *  示例
     *  享元模式 vs 单例、缓存、对象池
     *  享元模式的应用

# 结构型模式 #

## 概念 ##

结构型模式主要总结了一些类或者对象组合在一起的经典结构，这些经典的结构可以解决特定应用场景的问题。

## 类型 ##

共7种  
代理模式、桥接模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式

# 代理模式 #

## 概念 ##

代理模式（Proxy Design Pattern）的原理和代码实现都不难掌握。它在不改变原始类（或叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能。

## 静态代理 ##

静态代理的角色分为抽象类、被代理类、代理类  
抽象类是一个接口，被代理类实现了抽象类这个接口，而代理类也实现了此接口，代理类可以在被代理类调用前后做特殊处理。

（1）多个代理类，代理同一个类：如果需要替换代理类或者某场景下被代理类可以作为公共部分，实现代码的复用，业务系统通过调用不同的代理类实现不同的操作。

（2）一个代理类，代理多个类：根据传入的不同实现类对象，代理不同的类。

### 示例 ###

//抽象类
    public interface DrinksSubject {
        
        void sell();
    }
    
    //被代理类
    public class HuiyuanRealSubject implements DrinksSubject {
    
        @Override
        public void sell() {
            System.out.println("销售汇源果汁饮料");
        }
    }
    
    
    //代理类
    public class DrinkProxy implements DrinksSubject {
    
        private DrinksSubject drinksSubject;
    
        public DrinkProxy(DrinksSubject drinksSubject) {
            this.drinksSubject = drinksSubject;
        }
    
        @Override
        public void sell() {
            System.out.println("代理销售汇源果汁前打广告，招聘销售员");
            drinksSubject.sell();
            System.out.println("销售果汁之后回笼资金");
        }
    }
    
    @RestController
    @RequestMapping("api")
    public class TestController {
    
        @RequestMapping("testProxy")
        public void testProxy(){
            DrinkProxy drinkProxy = new DrinkProxy(new HuiyuanRealSubject());
            drinkProxy.sell();
        }
    }

### 优缺点 ###

优点：静态代理实现简单，不需要修改被代理类功能就可以对其进行扩展，符合设计模式的开闭原则；

缺点：因为代理类和被代理类实现同一个接口，如果接口改变那么代理类和被代理类都需要修改，而且如果有不同的代理需要添加不同的代理类。

## 动态代理 ##

动态代理可以通过一个代理类完成全部代理功能，不在需要手动创建代理类，只需要编写一个动态处理器即可，真正的代理对象由JDK在运行的时候动态创建。

动态代理只能满足一个代理类，代理多个被代理类。

### 示例 ###

//抽象类
    public interface DrinksSubject {
        
        void sell();
    }
    
    //被代理类
    public class HuiyuanRealSubject implements DrinksSubject {
    
        @Override
        public void sell() {
            System.out.println("销售汇源果汁饮料");
        }
    }
    
    
    //动态处理类
    public class ProxyHandler implements InvocationHandler {
    
        private Object object;
        
       public Object newProxyInstance(Object object){
            this.object = object;
            return Proxy.newProxyInstance(object.getClass().getClassLoader(), 
                                          object.getClass().getInterfaces(), this);
        }
        
        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            System.out.println("===" + object.getClass().getName() + "：" + method.getName() + "===");
            System.out.println("代理销售汇源果汁前打广告，招聘销售员");
            Object invoke = method.invoke(object, args);
            System.out.println("销售果汁之后回笼资金");
            return invoke;
        }
        
    }
    
    //测试类
    @RestController
    @RequestMapping("api")
    public class TestController {
    
     @RequestMapping("testProxyHandler")
        public void testProxyHandler(){
            ProxyHandler proxyHandler = new ProxyHandler();
            DrinksSubject drinksSubject = (DrinksSubject)proxyHandler.
                newProxyInstance(new HuiyuanRealSubject());
            drinksSubject.sell();
        }
    }

### 优缺点 ###

优点：动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理（InvocationHandler.invoke）。这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。而且动态代理的应用使我们的类职责更加单一，复用性更强。

缺点： Proxy已经设计得非常优美，但是还是有一点点小小的遗憾之处——它始终无法摆脱仅支持 interface代理的桎梏，因为它的设计注定了这个遗憾。动态生成的代理类的继承关系图，已经注定有一个共同的父类叫 Proxy。Java 的继承机制注定了这些动态代理类们无法实现对 class 的动态代理，原因是多继承在 Java 中本质上就行不通。

## CGLIB代理 ##

静态代理和动态代理的局限性就是要求代理目标实现接口，但是并不是所有对象都实现接口，那么可以使用继承目标类的目标对象子类的方式实现代理，或者不需要继承任何类，当然如果目标类实现接口通过CGLIB代理也是可以的。

CGLIB代理采用了非常底层的字节码技术，其原理是通过字节码技术为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类的方法的调用，顺势织入横切逻辑。但是因为采用的是继承，所以不能对final修饰的类进行代理。

### 示例 ###

//示例1
    public class CglibProxy implements MethodInterceptor {
    
        private  Object object;
    
        public Object getInstance(final Object object){
            this.object = object;
            //实例化一个增强器，也就是cglib中的一个class generator
            Enhancer enhancer = new Enhancer();
            //设置目标类
            enhancer.setSuperclass(this.object.getClass());
            //设置拦截对象
            enhancer.setCallback(this);
            return enhancer.create();
        }
    
    
        @Override
        public Object intercept(Object o, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
            System.out.println("代理销售饮料前打广告，招聘销售员");
            Object invoke = methodProxy.invoke(object, args);
            System.out.println("销售饮料之后回笼资金");
            return invoke;
        }
    }
    
    //测试类
    @RestController
    @RequestMapping("api")
    public class TestController {
    
        @RequestMapping("testProxyHandler1")
        public void testProxyHandler1(){
            DrinksSubject huiyuanRealSubject = new HuiyuanRealSubject();
            CglibProxy cglibProxy = new CglibProxy();
            DrinksSubject instance = (DrinksSubject)cglibProxy.getInstance(huiyuanRealSubject);
            instance.sell();
        }
        
       @RequestMapping("testProxyHandler2")
        public void testProxyHandler2(){
            CocaColaRealSubject cocaColaRealSubject = new CocaColaRealSubject();
            CglibProxy cglibProxy = new CglibProxy();
            CocaColaRealSubject instance = (CocaColaRealSubject)cglibProxy.getInstance(cocaColaRealSubject);
            instance.sellBottled();
    
        }
    }
    
    //结果
    代理销售饮料前打广告，招聘销售员
    销售汇源果汁饮料
    销售饮料之后回笼资金
    
    代理销售饮料前打广告，招聘销售员
    可口可乐瓶装饮料
    销售饮料之后回笼资金

## 代理模式使用场景 ##

业务系统的非功能性需求开发

代理模式最常用的一个应用场景就是，在业务系统中开发一些非功能性需求，比如：监控、统计、鉴权、限流、事务、幂等、日志。我们将这些附加功能与业务功能解耦，放到代理类中统一处理，让程序员只需要关注业务方面的开发。如果你熟悉 Java 语言和 Spring 开发框架，这部分工作都是可以在 Spring AOP 切面中完成的。前面我们也提到，Spring AOP 底层的实现原理就是基于动态代理。

# 桥接模式 #

## 概念 ##

将抽象和实现解耦，让他们可以独立变化

## 示例 ##

桥接模式可以理解为抽象定义了实现要有的功能，实现具体完成功能，不论业务需要哪个实现方式，只需要传入具体的实现对象即可，这样也就解耦，符合开闭原则，即对修改关闭，对扩展开放。比如：若代码中if-else分支逻辑比较多的时候，可以通过桥接模式进行重构。

public interface MsgSender {
      void send(String message);
    }
    
    public class TelephoneMsgSender implements MsgSender {
      private List<String> telephones;
    
      public TelephoneMsgSender(List<String> telephones) {
        this.telephones = telephones;
      }
    
      @Override
      public void send(String message) {
        //...
      }
    
    }
    
    public class EmailMsgSender implements MsgSender {
      // 与TelephoneMsgSender代码结构类似，所以省略...
    }
    
    public class WechatMsgSender implements MsgSender {
      // 与TelephoneMsgSender代码结构类似，所以省略...
    }
    
    public abstract class Notification {
      protected MsgSender msgSender;
    
      public Notification(MsgSender msgSender) {
        this.msgSender = msgSender;
      }
    
      public abstract void notify(String message);
    }
    
    public class SevereNotification extends Notification {
      public SevereNotification(MsgSender msgSender) {
        super(msgSender);
      }
    
      @Override
      public void notify(String message) {
        msgSender.send(message);
      }
    }
    
    public class UrgencyNotification extends Notification {
      // 与SevereNotification代码结构类似，所以省略...
    }
    public class NormalNotification extends Notification {
      // 与SevereNotification代码结构类似，所以省略...
    }
    public class TrivialNotification extends Notification {
      // 与SevereNotification代码结构类似，所以省略...
    }

## 案例 ##

JDBC驱动是桥接模式经典案例

Class.forName("com.mysql.jdbc.Driver");//加载及注册JDBC驱动程序
    String url = "jdbc:mysql://localhost:3306/sample_db?user=root&password=your_password";
    Connection con = DriverManager.getConnection(url);
    Statement stmt = con.createStatement()；
    String query = "select * from test";
    ResultSet rs=stmt.executeQuery(query);
    while(rs.next()) {
      rs.getString(1);
      rs.getInt(2);
    }

不论连接的是mysql还是oracle数据库，连接的URL是相同的，而具体连接的是哪种数据库，通过Class.forName(“com.mysql.jdbc.Driver”);来确定，当然在现在开发中数据库的配置一般都在配置文件中配置。

其实不论配置文件还是代码实现，底层实现都相同

package com.mysql.jdbc;
    import java.sql.SQLException;
    
    public class Driver extends NonRegisteringDriver implements java.sql.Driver {
      static {
        try {
          java.sql.DriverManager.registerDriver(new Driver());
        } catch (SQLException E) {
          throw new RuntimeException("Can't register driver!");
        }
      }
    
      /**
       * Construct a new driver and register it with DriverManager
       * @throws SQLException if a database error occurs.
       */
      public Driver() throws SQLException {
        // Required for Class.forName().newInstance()
      }
    }

结合 com.mysql.jdbc.Driver 的代码实现，我们可以发现，当执行 Class.forName(“com.mysql.jdbc.Driver”) 这条语句的时候，实际上是做了两件事情。第一件事情是要求 JVM 查找并加载指定的 Driver 类，第二件事情是执行该类的静态代码，也就是将 MySQL Driver 注册到 DriverManager 类中。

public class DriverManager {
      private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<DriverInfo>();
    
      //...
      static {
        loadInitialDrivers();
        println("JDBC DriverManager initialized");
      }
      //...
    
      public static synchronized void registerDriver(java.sql.Driver driver) throws SQLException {
        if (driver != null) {
          registeredDrivers.addIfAbsent(new DriverInfo(driver));
        } else {
          throw new NullPointerException();
        }
      }
    
      public static Connection getConnection(String url, String user, String password) throws SQLException {
        java.util.Properties info = new java.util.Properties();
        if (user != null) {
          info.put("user", user);
        }
        if (password != null) {
          info.put("password", password);
        }
        return (getConnection(url, info, Reflection.getCallerClass()));
      }
      //...
    }

实际上，JDBC 本身就相当于“抽象”。注意，这里所说的“抽象”，指的并非“抽象类”或“接口”，而是跟具体的数据库无关的、被抽象出来的一套“类库”。具体的 Driver（比如，com.mysql.jdbc.Driver）就相当于“实现”。注意，这里所说的“实现”，也并非指“接口的实现类”，而是跟具体数据库相关的一套“类库”。JDBC 和 Driver 独立开发（可以各自有各自的接口或者抽象类，以及具体实现类）通过对象之间的组合关系，组装在一起。JDBC 的所有逻辑操作，最终都委托给 Driver 来执行。

# 装饰者模式 #

装饰者模式其实从名称比较好理解，就是在同一事物上添加新的东西。与代理模式相似，区别在于代理模式中，代理类附加的是跟原始类无关的功能，而在装饰器模式中，装饰器类附加的是跟原始类相关的增强功能。

举个例子：代理模式就像购物，购物前要开车上街，购物完了饿了去吃了点东西，开车上街和吃东西呢与购物其实没有太大关系。

装饰者模式就像买了一个房子，要买家具，买家电等等进行装饰，家具，家电都属于房子的一部分.

java中IO类的设计思想就结合了装饰者模式  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center]

我们还讲到“组合优于继承”，可以“使用组合来替代继承”。针对刚刚的继承结构过于复杂的问题，我们可以通过将继承关系改为组合关系来解决。

装饰者模式不是简单的“用组合代替继承”，它有两个特殊的地方

*  第一个比较特殊的地方是：装饰器类和原始类继承同样的父类，这样我们可以对原始类“嵌套”多个装饰器类
 *  第二个比较特殊的地方是：装饰器类是对功能的增强，这也是装饰器模式应用场景的一个重要特点。

# 适配器模式 #

适配器模式的英文翻译是 Adapter Design Pattern。顾名思义，这个模式就是用来做适配的，它将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作。对于这个模式，有一个经常被拿来解释它的例子，就是 USB 转接头充当适配器，把两种不兼容的接口，通过转接变得可以一起工作。

适配器模式有两种实现方式：类适配器和对象适配器。类适配器使用继承关系来实现，对象适配器使用组合关系来实现

类适配器

// 类适配器: 基于继承
    public interface ITarget {
      void f1();
      void f2();
      void fc();
    }
    
    public class Adaptee {
      public void fa() { //... }
      public void fb() { //... }
      public void fc() { //... }
    }
    
    public class Adaptor extends Adaptee implements ITarget {
      public void f1() {
        super.fa();
      }
      
      public void f2() {
        //...重新实现f2()...
      }
      
      // 这里fc()不需要实现，直接继承自Adaptee，这是跟对象适配器最大的不同点
    }

对象适配器

// 对象适配器：基于组合
    public interface ITarget {
      void f1();
      void f2();
      void fc();
    }
    
    public class Adaptee {
      public void fa() { //... }
      public void fb() { //... }
      public void fc() { //... }
    }
    
    public class Adaptor implements ITarget {
      private Adaptee adaptee;
      
      public Adaptor(Adaptee adaptee) {
        this.adaptee = adaptee;
      }
      
      public void f1() {
        adaptee.fa(); //委托给Adaptee
      }
      
      public void f2() {
        //...重新实现f2()...
      }
      
      public void fc() {
        adaptee.fc();
      }
    }

针对这两种实现方式，在实际的开发中，到底该如何选择使用哪一种呢？判断的标准主要有两个；

一个是 Adaptee 接口的个数，另一个是 Adaptee 和 ITarget 的契合程度。

如果 Adaptee 接口并不多，那两种实现方式都可以。

如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都相同，那我们推荐使用类适配器，因为 Adaptor 复用父类 Adaptee 的接口，比起对象适配器的实现方式，Adaptor 的代码量要少一些。

如果 Adaptee 接口很多，而且 Adaptee 和 ITarget 接口定义大部分都不相同，那我们推荐使用对象适配器，因为组合结构相对于继承更加灵活。

适配器模式的应用场景

1.  封装有缺陷的接口设计
2.  统一多个类的接口设计
3.  替换依赖的外部系统
4.  兼容老版本接口
5.  适配不同格式的数据

## 应用实例 ##

日志打印框架，我们一般开发中可能用到的日志打印框架有log4j，logback等，但是他们没有实现统一接口。java开发总比较熟悉的日志框架还有一个Slf4，它相当于JDBC规范，提供一套打印日志的统一接口规范。

## 代理、桥接、装饰器、适配器4种设计模式的区别 ##

代理、桥接、装饰器、适配器，这4种模式是比较常用的结构型设计模式。它们的代码结构非常相似。笼统来说，它们都可以称为 Wrapper 模式，也就是通过Wrapper类二次封装原始类。尽管代码结构相似，但这4种设计模式的用意完全不同，也就是说要解决的问题、应用场景不同，这也是它们的主要区别。

*  代理模式：代理模式在不改变原始类接口的条件下，为原始类定义一个代理类，主要目的是控制访问，而非加强功能，这是它跟装饰器模式最大的不同。
 *  桥接模式：桥接模式的目的是将接口部分和实现部分分离，从而让它们可以较为容易、也相对独立地加以改变。
 *  装饰器模式：装饰者模式在不改变原始类接口的情况下，对原始类功能进行增强，并且支持多个装饰器的嵌套使用。
 *  适配器模式：适配器模式是一种事后的补救策略。适配器提供跟原始类不同的接口，而代理模式、装饰器模式提供的都是跟原始类相同的接口。

# 门面模式 #

门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。

1.  解决易用性问题  
    比如两个系统交互只暴露有限的，必要的接口；一个接口有多个方法，比如第三方jar包，但是实际项目只用到其中几个方法，如果直接实现此接口，那么就要实现很多非必要的方法，那么可以创建一个接口继承第三方接口，重写必要的接口。
2.  解决性能问题  
    比如两个系统交互，其中一个系统要连续调用另外一个系统多个接口，那么可以将多个接口封装成一个接口，只调用一次即可，减少网络调用提高性能
3.  解决分布式事务问题  
    根据不同的业务场景将不同的功能放在不同的接口，如果有需要结合不同场景的情况，可以创建一个接口兼容对应场景需要的方法。

# 组合模式 #

将一组对象组织（Compose）成树形结构，以表示一种“部分 - 整体”的层次结构。组合让客户端（在很多设计模式书籍中，“客户端”代指代码的使用者。）可以统一单个对象和组合对象的处理逻辑。

比如文件目录与文件的关系，部门与员工的关系都是“整体与部分”的关系

## 示例 ##

没有使用组合模式示例

public class FileSystemNode {
      private String path;
      private boolean isFile;
      private List<FileSystemNode> subNodes = new ArrayList<>();
    
      public FileSystemNode(String path, boolean isFile) {
        this.path = path;
        this.isFile = isFile;
      }
    
      public int countNumOfFiles() {
        // TODO:...
      }
    
      public long countSizeOfFiles() {
        // TODO:...
      }
    
      public String getPath() {
        return path;
      }
    
      public void addSubNode(FileSystemNode fileOrDir) {
        subNodes.add(fileOrDir);
      }
    
      public void removeSubNode(FileSystemNode fileOrDir) {
        int size = subNodes.size();
        int i = 0;
        for (; i < size; ++i) {
          if (subNodes.get(i).getPath().equalsIgnoreCase(fileOrDir.getPath())) {
            break;
          }
        }
        if (i < size) {
          subNodes.remove(i);
        }
      }
    }

使用组合模式重构以后示例

public abstract class FileSystemNode {
      protected String path;
    
      public FileSystemNode(String path) {
        this.path = path;
      }
    
      public abstract int countNumOfFiles();
      public abstract long countSizeOfFiles();
    
      public String getPath() {
        return path;
      }
    }
    
    public class File extends FileSystemNode {
      public File(String path) {
        super(path);
      }
    
      @Override
      public int countNumOfFiles() {
        return 1;
      }
    
      @Override
      public long countSizeOfFiles() {
        java.io.File file = new java.io.File(path);
        if (!file.exists()) return 0;
        return file.length();
      }
    }
    
    public class Directory extends FileSystemNode {
      private List<FileSystemNode> subNodes = new ArrayList<>();
    
      public Directory(String path) {
        super(path);
      }
    
      @Override
      public int countNumOfFiles() {
        int numOfFiles = 0;
        for (FileSystemNode fileOrDir : subNodes) {
          numOfFiles += fileOrDir.countNumOfFiles();
        }
        return numOfFiles;
      }
    
      @Override
      public long countSizeOfFiles() {
        long sizeofFiles = 0;
        for (FileSystemNode fileOrDir : subNodes) {
          sizeofFiles += fileOrDir.countSizeOfFiles();
        }
        return sizeofFiles;
      }
    
      public void addSubNode(FileSystemNode fileOrDir) {
        subNodes.add(fileOrDir);
      }
    
      public void removeSubNode(FileSystemNode fileOrDir) {
        int size = subNodes.size();
        int i = 0;
        for (; i < size; ++i) {
          if (subNodes.get(i).getPath().equalsIgnoreCase(fileOrDir.getPath())) {
            break;
          }
        }
        if (i < size) {
          subNodes.remove(i);
        }
      }
    }

套用模板：部分与整体继承同一个父类，重新父类方法

# 享元模式 #

享元模式的原理和实现非常简单，享元模式就是共享单元，意图是复用对象，节省内存，前提是享元对象是不可变对象。

## 使用场景 ##

具体来讲，当一个系统中存在大量重复对象的时候，如果这些重复的对象是不可变对象，我们就可以利用享元模式将对象设计成享元，在内存中只保留一份实例，供多处代码引用。这样可以减少内存中对象的数量，起到节省内存的目的。实际上，不仅仅相同对象可以设计成享元，对于相似对象，我们也可以将这些对象中相同的部分（字段）提取出来，设计成享元，让这些大量相似对象引用这些享元。

## 示例 ##

假设我们在开发一个棋牌游戏（比如象棋）。一个游戏厅中有成千上万个“房间”，每个房间对应一个棋局。棋局要保存每个棋子的数据，比如：棋子类型（将、相、士、炮等）、棋子颜色（红方、黑方）、棋子在棋局中的位置。利用这些数据，我们就能显示一个完整的棋盘给玩家。具体的代码如下所示。其中，ChessPiece 类表示棋子，ChessBoard 类表示一个棋局，里面保存了象棋中 30 个棋子的信息。

没有使用享元模式

public class ChessPiece {//棋子
      private int id;
      private String text;
      private Color color;
      private int positionX;
      private int positionY;
    
      public ChessPiece(int id, String text, Color color, int positionX, int positionY) {
        this.id = id;
        this.text = text;
        this.color = color;
        this.positionX = positionX;
        this.positionY = positionX;
      }
    
      public static enum Color {
        RED, BLACK
      }
    
      // ...省略其他属性和getter/setter方法...
    }
    
    public class ChessBoard {//棋局
      private Map<Integer, ChessPiece> chessPieces = new HashMap<>();
    
      public ChessBoard() {
        init();
      }
    
      private void init() {
        chessPieces.put(1, new ChessPiece(1, "車", ChessPiece.Color.BLACK, 0, 0));
        chessPieces.put(2, new ChessPiece(2,"馬", ChessPiece.Color.BLACK, 0, 1));
        //...省略摆放其他棋子的代码...
      }
    
      public void move(int chessPieceId, int toPositionX, int toPositionY) {
        //...省略...
      }
    }

使用享元模式重构

// 享元类
    public class ChessPieceUnit {
      private int id;
      private String text;
      private Color color;
    
      public ChessPieceUnit(int id, String text, Color color) {
        this.id = id;
        this.text = text;
        this.color = color;
      }
    
      public static enum Color {
        RED, BLACK
      }
    
      // ...省略其他属性和getter方法...
    }
    
    public class ChessPieceUnitFactory {
      private static final Map<Integer, ChessPieceUnit> pieces = new HashMap<>();
    
      static {
        pieces.put(1, new ChessPieceUnit(1, "車", ChessPieceUnit.Color.BLACK));
        pieces.put(2, new ChessPieceUnit(2,"馬", ChessPieceUnit.Color.BLACK));
        //...省略摆放其他棋子的代码...
      }
    
      public static ChessPieceUnit getChessPiece(int chessPieceId) {
        return pieces.get(chessPieceId);
      }
    }
    
    public class ChessPiece {
      private ChessPieceUnit chessPieceUnit;
      private int positionX;
      private int positionY;
    
      public ChessPiece(ChessPieceUnit unit, int positionX, int positionY) {
        this.chessPieceUnit = unit;
        this.positionX = positionX;
        this.positionY = positionY;
      }
      // 省略getter、setter方法
    }
    
    public class ChessBoard {
      private Map<Integer, ChessPiece> chessPieces = new HashMap<>();
    
      public ChessBoard() {
        init();
      }
    
      private void init() {
        chessPieces.put(1, new ChessPiece(
                ChessPieceUnitFactory.getChessPiece(1), 0,0));
        chessPieces.put(1, new ChessPiece(
                ChessPieceUnitFactory.getChessPiece(2), 1,0));
        //...省略摆放其他棋子的代码...
      }
    
      public void move(int chessPieceId, int toPositionX, int toPositionY) {
        //...省略...
      }
    }

在上面的代码实现中，我们利用工厂类来缓存 ChessPieceUnit 信息（也就是 id、text、color）。通过工厂类获取到的 ChessPieceUnit 就是享元。所有的 ChessBoard 对象共享这 30 个 ChessPieceUnit 对象（因为象棋中只有 30 个棋子）。在使用享元模式之前，记录 1 万个棋局，我们要创建 30 万（30\*1 万）个棋子的 ChessPieceUnit 对象。利用享元模式，我们只需要创建 30 个享元对象供所有棋局共享使用即可，大大节省了内存。

实际上，它的代码实现非常简单，主要是通过工厂模式，在工厂类中，通过一个 Map来缓存已经创建过的享元对象，来达到复用的目的。

## 享元模式 vs 单例、缓存、对象池 ##

*  享元模式与单例  
      
    单例模式是一个类只创建一个对象，而享元模式是一个类创建多个对象，每个对象被多处共享。实际上，享元模式有点类似于之前讲到的单例的变体：多例。  
      
    我们前面也多次提到，区别两种设计模式，不能光看代码实现，而是要看设计意图，也就是要解决的问题。尽管从代码实现上来看，享元模式和多例有很多相似之处，但从设计意图上来看，它们是完全不同的。应用享元模式是为了对象复用，节省内存，而应用多例模式是为了限制对象的个数。
 *  享元模式与缓存区别  
      
    在享元模式的实现中，我们通过工厂类来“缓存”已经创建好的对象。这里的“缓存”实际上是“存储”的意思，跟我们平时所说  
    的“数据库缓存”“CPU缓存”“MemCache缓存”是两回事。我们平时所讲的缓存，主要是为了提高访问效率，而非复用。
 *  享元模式与对象池  
      
    虽然对象池、连接池、线程池、享元模式都是为了复用，但是，如果我们再细致地抠一抠“复用”这个字眼的话，对象池、连接池、线程池等池化技术中的“复用”和享元模式中的“复用”实际上是不同的概念。  
      
    池化技术中的“复用”可以理解为“重复使用”，主要目的是节省时间（比如从数据库池中取一个连接，不需要重新创建）。在任意时刻，每一个对象、连接、线程，并不会被多处使用，而是被一个使用者独占，当使用完成之后，放回到池中，再由其他使用者重复利用。享元模式中的“复用”可以理解为“共享使用”，在整个生命周期中，都是被所有使用者共享的，主要目的是节省空间。

## 享元模式的应用 ##

在java代码中常用的Integer和String

Integer在-128到127之间的数字通过IntegerCache获取，超出这个范围重新创建，如下示例

Integer i1 = 56;
    Integer i2 = 56;
    Integer i3 = 129;
    Integer i4 = 129;
    System.out.println(i1 == i2);
    System.out.println(i3 == i4);
    
    结果：
    true
    false

String在jvm中有一个字符串常量池，如果是在常量池中存在那么就复用常量池中对象的引用地址

String s1 = "小争哥";
    String s2 = "小争哥";
    String s3 = new String("小争哥");
    
    System.out.println(s1 == s2);
    System.out.println(s1 == s3);
    
    结果：
    true
    false

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNTgwOA_size_16_color_FFFFFF_t_70_pic_center]: /images/20221124/18a5ca5055f9430692eded9f7501050c.png