设计模式总结之Flyweight Pattern(享元模式)

目录

创建型设计模式: 结构型设计模式: 行为型设计模式:

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)享元模式将享元对象的状态外部化,而读取外部状态使得运行时间稍微变长。

没有更多推荐了,返回首页