26. 享元模式
约 1679 字大约 6 分钟
2026-03-27
定义
享元模式(Flyweight),运用共享技术有效地支持大量细粒度的对象。
人话:享元模式就像围棋下棋的过程。围棋棋盘上可以放很多棋子,一局棋下来可能有上百甚至更多的黑白棋子。
如果不用享元模式来设计,就相当于每下一颗棋子都 new 一个对象,每个对象里都包含颜色、位置等信息。这样一来,棋子越多,占用的内存就越大,这在软件中就属于对象数量过多、内存浪费严重。
而实际上,围棋棋子本质上只有两种:黑棋 和 白棋。也就是说,颜色是固定且可以共享的,并不需要为每一颗棋子都单独创建一个“黑棋对象”或“白棋对象”。
于是,使用享元模式之后,我们会这样设计:
- 只创建 两个共享对象:黑棋对象、白棋对象(享元)
- 每次落子时,不再创建新对象,而是复用已有的黑棋或白棋
- 棋子的位置(比如“第几行第几列”)不存储在对象内部,而是在使用时作为参数传入
这样一来:
- 颜色(黑/白)是内部状态 → 可以共享
- 位置(坐标)是外部状态 → 由外部传入
比如:
- 落一颗黑棋 → 使用“黑棋对象” + 位置(3,5)
- 再落一颗黑棋 → 还是同一个“黑棋对象” + 不同位置(7,8)
在软件中也是一样:享元模式通过共享相同的内部状态对象,把变化的部分(外部状态)交给外部管理,从而大幅减少对象数量,降低内存开销,让系统在处理大量细粒度对象时更加高效。
享元模式(Flyweight)结构图
Flyweight类——抽象享元:
// Flyweight(抽象享元)
abstract class Flyweight
{
// extrinsicState:外部状态
public abstract void Operation(int extrinsicState);
}ConcreteFlyweight类——具体享元(共享):
// ConcreteFlyweight(具体享元)
class ConcreteFlyweight : Flyweight
{
public override void Operation(int extrinsicState)
{
Console.WriteLine("具体 Flyweight:" + extrinsicState);
}
}UnsharedConcreteFlyweight类——不共享的享元:
// UnsharedConcreteFlyweight(不共享的享元)
class UnsharedConcreteFlyweight : Flyweight
{
public override void Operation(int extrinsicState)
{
Console.WriteLine("不共享的具体 Flyweight:" + extrinsicState);
}
}FlyweightFactory类——享元工厂:
// FlyweightFactory(享元工厂)
class FlyweightFactory
{
private Hashtable flyweights = new Hashtable();
public FlyweightFactory()
{
// 初始化时创建一些实例
flyweights.Add("X", new ConcreteFlyweight());
flyweights.Add("Y", new ConcreteFlyweight());
flyweights.Add("Z", new ConcreteFlyweight());
}
// 获取享元对象
public Flyweight GetFlyweight(string key)
{
return (Flyweight)flyweights[key];
}
}客户端代码:
static void Main(string[] args)
{
int extrinsicState = 22;
FlyweightFactory f = new FlyweightFactory();
Flyweight fx = f.GetFlyweight("X");
fx.Operation(--extrinsicState);
Flyweight fy = f.GetFlyweight("Y");
fy.Operation(--extrinsicState);
Flyweight fz = f.GetFlyweight("Z");
fz.Operation(--extrinsicState);
// 不共享的对象
UnsharedConcreteFlyweight uf = new UnsharedConcreteFlyweight();
uf.Operation(--extrinsicState);
Console.Read();
}运行结果:
具体 Flyweight:21
具体 Flyweight:20
具体 Flyweight:19
不共享的具体 Flyweight:18FlyweightFactory 根据客户需求返回早已生成好的对象,但一定要事先生成对象实例吗?实际上是不一定需要的,完全可以初始化时什么也不做,到需要时,再去判断对象是否为 null 来决定是否实例化。
为什么要有 UnsharedConcreteFlyweight 的存在呢?这是因为尽管我们大部分时间都需要共享对象来降低内存的损耗,但个别时候也有可能不需要共享的,那么此时的 UnsharedConcreteFlyweight 子类就有存在的必要了,它可以解决那些不需要共享对象的问题。
在享元对象内部并且不会随环境改变而改变的共享部分,可以称为是享元对象的内部状态,而随环境改变而改变的、不可以共享的状态就是外部状态了。事实上,享元模式可以避免大量非常相似类的开销。在程序设计中,有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的,有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面,在方法调用时将它们传递进来,就可以通过共享大幅度地减少单个实例的数目。也就是说,享元模式 Flyweight 执行时所需的状态是有内部的也可能有外部的,内部状态存储于 ConcreteFlyweight 对象之中,而外部对象则应该考虑由客户端对象存储或计算,当调用 Flyweight 对象的操作时,将该状态传递给它。
如果一个应用程序使用了大量的对象,而大量的这些对象造成了很大的存储开销时就应该考虑使用;还有就是对象的大多数状态可以外部状态,如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象,此时可以考虑使用享元模式。
在某些情况下,对象的数量可能会太多,从而导致了运行时的资源与性能损耗。那么我们如何去避免大量细粒度的对象,同时又不影响客户程序,是一个值得去思考的问题,享元模式,可以运用共享技术有效地支持大量细粒度的对象。不过,你也别高兴得太早,使用享元模式需要维护一个记录了系统已有的所有享元的列表,而这本身需要耗费资源,另外享元模式使得系统更加复杂。为了使对象可以共享,需要将一些状态外部化,这使得程序的逻辑复杂化。因此,应当在有足够多的对象实例可供共享时才值得使用享元模式。
