设计模式总结之Flyweight Pattern（享元模式）

最新推荐文章于 2024-04-23 09:30:39 发布

迷死特兔

最新推荐文章于 2024-04-23 09:30:39 发布

阅读量3k

点赞数

分类专栏： Architecture 文章标签：设计模式 Flyweight 享元模式

本文链接：https://blog.csdn.net/cooldragon/article/details/52174529

版权

Architecture 专栏收录该内容

29 篇文章 4 订阅

订阅专栏

Flyweight Pattern（享元模式）

意图

运用共享技术有效地支持大量细粒度的对象。

适用性

当以下所有的条件都满足时，可以考虑使用享元模式：
* 一个应用程序使用了大量的对象。
* 完全由于使用大量的对象，造成很大的存储开销。
* 对象的大多数状态都可变为外部状态。
* 如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。
* 应用程序不依赖于对象标识。由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。

满足以上的这些条件的系统可以使用享元对象。

最后，使用享元模式需要维护一个记录了系统已有的所有享元的表，而这需要耗费资源。因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。

注意要点：
　　根据我们的经验，当要将一个对象进行共享时，就需要考虑到对象的状态问题了；不同的客户端获得共享的对象之后，可能会修改共享对象的某些状态；大家都修改了共享对象的状态，那么就会出现对象状态的紊乱。对于享元模式，在实现时一定要考虑到共享对象的状态问题。那么享元模式是如何实现的呢？
　　在享元模式中，有两个非常重要的概念：内部状态（intrinsicState）和外部状态（extrinsicState）。
　　内部状态存储于flyweight中，它包含了独立于flyweight场景的信息，这些信息使得flyweight可以被共享。而外部状态取决于flyweight场景，并根据场景而变化，因此不可共享。用户对象负责在必要的时候将外部状态传递给flyweight。
　　flyweight执行时所需的状态必定是内部的或外部的。内部状态存储于ConcreteFlyweight对象之中；而外部对象则由 Client对象存储或计算。当用户调用flyweight对象的操作时，将该状态传递给它。同时，用户不应该直接对ConcreteFlyweight 类进行实例化，而只能从FlyweightFactory对象得到ConcreteFlyweight对象，这可以保证对它们适当地进行共享；由于共享一个实例，所以在创建这个实例时，就可以考虑使用单例模式来进行实现。
　　享元模式的工厂类维护了一个实例列表，这个列表中保存了所有的共享实例；当用户从享元模式的工厂类请求共享对象时，首先查询这个实例表，如果不存在对应实例，则创建一个；如果存在，则直接返回对应的实例。

结构

Flyweight：描述一个接口，通过这个接口flyweight可以接受并作用于外部状态；
ConcreteFlyweight：实现Flyweight接口，并为定义了一些内部状态，ConcreteFlyweight对象必须是可共享的；同时，它所存储的状态必须是内部的；即，它必须独立于ConcreteFlyweight对象的场景；
UnsharedConcreteFlyweight：并非所有的Flyweight子类都需要被共享。Flyweight接口使共享成为可能，但它并不强制共享。
FlyweightFactory：创建并管理flyweight对象。它需要确保合理地共享flyweight；当用户请求一个flyweight时，FlyweightFactory对象提供一个已创建的实例，如果请求的实例不存在的情况下，就新创建一个实例；
Client：维持一个对flyweight的引用；同时，它需要计算或存储flyweight的外部状态。

如何共享了Flyweight，如下图：

例子

注：可共享——>可以理解为可以复用的。
不可共享——>可以理解为不需要复用，不可复用的。

优缺点

> 优点：
享元模式可以避免大量非常相似对象的开销。在程序设计时，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例数据除了几个参数外基本都是相同的，使用享元模式就可以大幅度地减少对象的数量。

> 缺点：
1）享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。
2）享元模式将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。