结构型设计模式07-享元模式

1、享元模式介绍

享元模式是一种结构型设计模式，旨在通过共享对象来减少内存使用和提高性能。它主要用于处理大量细粒度对象的情况，其中许多对象具有相似的属性和行为。

在享元模式中，对象分为两种类型：内部状态（Intrinsic State）和外部状态（Extrinsic State）。

内部状态是对象的固有属性，它们不随外部环境的改变而改变。

外部状态取决于外部环境，它们在运行时可以改变。

享元模式的核心思想是将具有相同内部状态的对象共享，以减少内存占用。当需要创建一个对象时，首先检查是否已经存在具有相同内部状态的对象。如果存在，则重用该对象，而不是创建一个新的对象。如果不存在，则创建一个新的对象并将其添加到共享池中，以供以后使用。

1.1 享元模式基本实现

享元模式代码结构图：

Flyweight类

是所有具体享元类的超类或接口，通过这个接口， Flyweight可以接受并作用于外部状态。

/**
 * @author Shier
 * CreateTime 2023/5/22 16:06
 * Flyweight类 - 接受外部状态
 */
public abstract class Flyweight {
    public abstract void operation(int extrinsicState);
}

ConcreteFlyweight是继承Flyweight超类或实现Flyweight接口，并为内部状态增加存储空间。

/**
 * @author Shier
 * CreateTime 2023/5/22 16:09
 * 需要共享的具体Flyweight子类
 */
public class ConcreteFlyweight extends Flyweight {
    @Override
    public void operation(int extrinsicState) {
        System.out.println("需要共享的具体Flyweight子类：" + extrinsicState);
    }
}

UnsharedConcreteFlyweight是指那些不需要共享的Flyweight子类。因为Flyweight接口共享成为可能，但它并不强制共享。

/**
 * @author Shier
 * CreateTime 2023/5/22 16:09
 * 需要共享的具体Flyweight子类
 */
public class UnsharedConcreteFlyweight extends Flyweight {
    @Override
    public void operation(int extrinsicState) {
        System.out.println("不需要共享的具体Flyweight子类：" + extrinsicState);
    }
}

FlyweightFactory是一个享元工厂，用来创建并管理Flyweight对象。它主要是用来确保合理地共享Flyweight，当用户请求一个Flyweight时， FlyweightFactory对象提供一个已创建的实例或者创建一个（如果不存在的话）。

/**
 * @author Shier
 * CreateTime 2023/5/22 16:12
 * 享元工厂
 */
public class FlyweightFactory {
    private Hashtable<String, Flyweight> flyweights = new Hashtable<String, Flyweight>();

    /**
     * 初始化工厂三个实例
     */
    public FlyweightFactory() {
        flyweights.put("A", new ConcreteFlyweight());
        flyweights.put("B", new ConcreteFlyweight());
        flyweights.put("C", new ConcreteFlyweight());
    }

    /**
     * 根据客户端请求，获得已生成的实例
     *
     * @param key
     * @return
     */
    public Flyweight getFlyweight(String key) {
        return flyweights.get(key);
    }
}

客户端代码：

/**
 * @author Shier
 * CreateTime 2023/5/22 16:16
 */
public class FlyweightClient {
    public static void main(String[] args) {
        int extrinsicState = 22;
        FlyweightFactory factory = new FlyweightFactory();

        Flyweight flyweightA = factory.getFlyweight("A");
        flyweightA.operation(--extrinsicState);
        Flyweight flyweightB = factory.getFlyweight("B");
        flyweightB.operation(--extrinsicState);
        Flyweight flyweightC = factory.getFlyweight("C");
        flyweightC.operation(--extrinsicState);
        // 不要共享的
        UnsharedConcreteFlyweight unsharedFly = new UnsharedConcreteFlyweight();
        unsharedFly.operation(--extrinsicState);
    }
}

输出结果：

FlyweightFactory根据客户需求返回早已生成好的对象，但一定要事先生成对象实例吗？

实际上是不一定需要的，完全可以初始化时什么也不做，到需要时，再去判断对象是否为null来决定是否实例化。

还有个问题，为什么要有UnsharedConcreteFlyweight的存在呢？

这是因为尽管我们大部分时间都需要共享对象来降低内存的损耗，但个别时候也有可能不需要共享，那么此时的UnsharedConcreteFlyweight子类就有存在的必要了，它可以解决那些不需要共享对象的问题。

2、具体例子说明

接单做网站：要求做产品展示网站，有的人希望是新闻发布形式的，有的人希望是博客形式的，也有还是原来的产品图片加说明形式的。

因为他们找我们来做的人的需求只是有一些小小的差别。

但是不可能有100家企业来找你做网站，你难道去申请100个服务器，用100个数据库，然后用类似的代码复制100遍，去实现吗？

2.1 不使用享元模式 - 接单做网站

//网站
public class WebSite {
    private String name = "";
    public WebSite(String name) {
        this.name = name;
    }
    public void use() {
        System.out.println("网站分类：" + name);
    }
}

客户端：

public class Test {
    public static void main(String[] args) {
        WebSite fx = new WebSite("产品展示");
        fx.use();
        
        WebSite fy = new WebSite("产品展示");
        fy.use();
        
        WebSite fz = new WebSite("产品展示");
        fz.use();
        
        WebSite fl = new WebSite("博客");
        fl.use();

        WebSite fm = new WebSite("博客");
        fm.use();

        WebSite fn = new WebSite("博客");
        fn.use();
    }
}

结果显示：

如果要做三个产品展示，三个博客的网站，就需要六个网站类的实例，而其实它们本质上都是一样的代码，如果网站增多，实例 也就随着增多，这对服务器的资源浪费得很严重。

可以利用用户ID的不同，来区分不同的用户，具体数据和模板可以不同，但代码核心和数据库却是共享的。

首先这些客户，他们需要的网站结构相似度很高，而且都不是那种高访问量的网站，如果分成多个虚拟空间来处理，相当于一个相同网站的实例对象很多，这造成服务器的大量资源浪费，当然更实际的其实就是钞票的浪费，如果整合到一个网站中，共享其相关的代码和数据，那么对于硬盘、内存、CPU、数据库空间等服务器资源都可以达成共享，减少服务器资源，而对于代码，由于是一份实 例，维护和扩展都更加容易。

2.2 适用享元模式 - 接单做网站

2.2.1 第一版

网站抽象类：

/**
 * @author Shier
 * CreateTime 2023/5/22 16:32
 */
public abstract class WebSite {
    public abstract void use();
}

具体网站类：

/**
 * @author Shier
 * CreateTime 2023/5/22 16:32
 */
public class ConcreteWebSite extends WebSite {

    private String name = "";

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

    @Override
    public void use() {
        System.out.println("网站分类：" + name);
    }
}

网站工厂类：

/**
 * @author Shier
 * CreateTime 2023/5/22 16:33
 */
public class WebSiteFactory {
    private Hashtable<String, WebSite> flyweights = new Hashtable<>();

    /**
     * 获得网站分类
     *
     * @param key
     * @return
     */
    public WebSite getWebSiteCategory(String key) {
        if (!flyweights.contains(key)) {
            flyweights.put(key, new ConcreteWebSite(key));
        }
        return flyweights.get(key);
    }

    /**
     * 获得网站实例个数
     *
     * @return
     */
    public int getWebSiteCount() {
        return flyweights.size();
    }
}

客户端：

public class WebStateClient1 {
    public static void main(String[] args) {
        WebSiteFactory webSiteFactory = new WebSiteFactory();
        WebSite siteCategory = webSiteFactory.getWebSiteCategory("产品展示");
        siteCategory.use();
        WebSite siteCategory1 = webSiteFactory.getWebSiteCategory("产品展示");
        siteCategory1.use();
        WebSite siteCategory2 = webSiteFactory.getWebSiteCategory("产品展示");
        siteCategory2.use();
        WebSite siteCategory3 = webSiteFactory.getWebSiteCategory("博客");
        siteCategory3.use();
        WebSite siteCategory4 = webSiteFactory.getWebSiteCategory("博客");
        siteCategory4.use();
        WebSite siteCategory5 = webSiteFactory.getWebSiteCategory("博客");
        siteCategory5.use();
        System.out.println("总共创建了 " + webSiteFactory.getWebSiteCount() + " 个实例");
    }
}

结果：

基本实现了享元模式的共享对象的目的，也就是说，不管建个网站，只要是 ‘产品展示’ ，都是一样的，只要是 ‘博客’ ，也是完全相同的，但这样是有问题的，以上这样建的网站不是一家客户的，它们的数据不会相同，所以至少它们都应该有不同的账号。

这样写没有体现对象间的不同，只体现了它们共享 的部分。

2.2.2 内部状态 - 外部状态 - 享元模式 - 接单做网站

在享元对象内部并且不会随环境改变而改变的共享部分，可以称为享元对象的内部状态，随环境改变而改变的、不可以共享的状态就是外部状态。

事实上，享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个 参数外基本上都是相同的，有时就能够大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来， 就可以通过共享大幅度地减少单个实例的数目。

也就是说，享元模式 Flyweight 执行时所需的状态有内部的也可能有外部的，内部状态存储于 ConcreteFlyweight 对象之中，而外部对象则应该考虑由客户端对象存储或计 算，当调用Flyweight对象的操作时，将该状态传递给它。

客户的账号就是外部状态，应该由专门的对象来处理。代码结构图：

用户类，用于网站的客户账号，是"网站"类的外部状态。

/**
 * @author Shier
 * CreateTime 2023/5/22 16:49
 */
public class User {
    private String name;

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

    public String getName() {
        return name;
    }
}

网站抽象类：

/**
 * @author Shier
 * CreateTime 2023/5/22 16:32
 */
public abstract class WebSite {
    public abstract void use(User user);
}

具体网站类：

/**
 * @author Shier
 * CreateTime 2023/5/22 16:32
 */
public class ConcreteWebSite extends WebSite {

    private String name = "";

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

    @Override
    public void use(User user) {
        System.out.println("网站分类：" + name + " 来自客户：" + user.getName() + "的需求");
    }
}

网站工厂类不要改变同上。

客户端：

最后得到的结果：

这样就可以协调内部与外部状态了。由于用了享元模 式，哪怕接手了1000个网站的需求，只要要求相同或类似，你的实际开发代码也就是分类的那几种，对于服务器来说，占用的硬盘空间、内存、CPU资 源都是非常少的，这确实是很好的一个方式。money自然就到手了。

3、享元模式总结

3.1 享元模式应用

如果一个应用程序使用了大量的对象，而大 量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大 多数状态可以是外部状态，如果删除对象的外部状态，那么可以用相对较少 的共享对象取代很多组对象，此时可以考虑使用享元模式。

实际上在Java中，字符串String就是运用了Flyweight模式。举个例子吧。== 可以用来确定 titleA 与 titleB 是否是相同的实例，返回值为 boolean 值。当用 new String() 方法时，两个对象 titleA 和 titleB 的引用地址是不相同的，但当 titleC 和 titleD 都使用赋值的方式时，两个字符串的引用地址竟然是相同的。

得出结果：

享元模式更多的时候是一种底层的设计模式，但现实中也是有应用的。

比如说休闲游戏开发中，像围棋、五子棋、跳棋等，它们都有大量的棋子对象，分析一下，它们的内部状态和外部状态各是什么？

围棋和五子棋只有黑白两色、跳棋颜色略多一些，但也是不太变化的， 所以颜色应该是棋子的内部状态，而各个棋子之间的差别主要就是位置的不同，所以方位坐标应该是棋子的外部状态。

像围棋，一盘棋理论上有361个空位可以放棋子，那如果用常规的面向对象方式编程，每盘棋都可能有两三百个棋子对象产生，一台服务器就很难支持更多的玩家玩围棋游戏了，毕竟内存空间还是有限的。如果用了享元模式来处理棋子，那么棋子对象可以减少到只有两个实例。

在某些情况下，对象的数量可能会太多，从而导致了运行时的资源与性能损耗。

那么我们如何去避免大量细粒度的对象，同时又不影响客户程序，是一个值得去思考的问题。

享元模式，可以运用共享技术有效地支持大量细 粒度的对象。不过，使用享元模式需要维护一个记录了系统已有的所有享元的列表，而这本身需要耗费资源，另外享元模式使得系 统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。

因此，应当在有足够多的对象实例可供共享时才值得使用享元模式。

3.2 优缺点、适用场景总结

优点

内存优化：通过共享对象的内部状态，可以大大减少对象的数量，从而节省内存空间。

性能提升：减少对象数量和内存占用可以提高系统的性能，特别是在处理大量细粒度对象时。

可扩展性：享元模式可以轻松扩展以支持新的外部状态，而无需修改现有的共享对象。

对象复用：通过共享对象，可以实现对象的复用，避免重复创建相同的对象，提高系统的效率和资源利用率。

缺点：

共享对象可能引入线程安全问题：如果多个线程同时访问和修改共享对象的状态，需要考虑线程安全性，以避免并发访问引发的问题。

对象状态的外部化：为了实现对象共享，部分对象状态需要外部化，这可能会增加代码复杂性和维护成本。

适用场景：

当系统中存在大量相似对象，且这些对象的内部状态相同或相似，而外部状态有所不同时，可以考虑使用享元模式。

当需要创建大量对象，但创建和销毁对象的代价很高时，可以使用享元模式来复用已有对象，提高系统性能。

当系统需要缓存对象以提高性能，并且可以忍受一定程度的对象状态变化时，享元模式也是一个不错的选择。

当对象的状态可以被多个对象共享，并且这些对象之间的外部状态可以相对独立时，可以使用享元模式。

使用享元模式的一个常见例子是文本编辑器中的字符对象。在一个文本文件中，可能有大量的字符对象，它们的外部状态（例如位置、字体、颜色等）可能不同，但内部状态（例如字符代码、字符宽度等）是相同的。通过共享具有相同字符代码的字符对象，可以大大减少内存使用

总之，享元模式适用于大量细粒度对象的场景，通过共享对象的内部状态来减少对象数量和内存占用，从而提高系统性能和资源利用率。它在需要重复创建相似对象的情况下特别有用，并且适用于多线程环境，但需要注意线程安全性。

这可能会增加代码复杂性和维护成本。

适用场景：

当系统中存在大量相似对象，且这些对象的内部状态相同或相似，而外部状态有所不同时，可以考虑使用享元模式。

当需要创建大量对象，但创建和销毁对象的代价很高时，可以使用享元模式来复用已有对象，提高系统性能。

当系统需要缓存对象以提高性能，并且可以忍受一定程度的对象状态变化时，享元模式也是一个不错的选择。

当对象的状态可以被多个对象共享，并且这些对象之间的外部状态可以相对独立时，可以使用享元模式。

使用享元模式的一个常见例子是文本编辑器中的字符对象。在一个文本文件中，可能有大量的字符对象，它们的外部状态（例如位置、字体、颜色等）可能不同，但内部状态（例如字符代码、字符宽度等）是相同的。通过共享具有相同字符代码的字符对象，可以大大减少内存使用

总之，享元模式适用于大量细粒度对象的场景，通过共享对象的内部状态来减少对象数量和内存占用，从而提高系统性能和资源利用率。它在需要重复创建相似对象的情况下特别有用，并且适用于多线程环境，但需要注意线程安全性。