NET设计模式 第二部分 结构性模式(12)：享元模式（Flyweight Pattern）

享元模式（Flyweight Pattern）

——.NET设计模式系列之十三

Terrylee，2006年3月

摘要：面向对象的思想很好地解决了抽象性的问题，一般也不会出现性能上的问题。但是在某些情况下，对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作？

本文试图通过一个简单的字符处理的例子，运用重构的手段，一步步带你走进Flyweight模式，在这个过程中我们一同思考、探索、权衡，通过比较而得出好的实现方式，而不是给你最终的一个完美解决方案。

主要内容：

1．  Flyweight模式解说

2．.NET中的Flyweight模式

3．Flyweight模式的实现要点

……

概述

面向对象的思想很好地解决了抽象性的问题，一般也不会出现性能上的问题。但是在某些情况下，对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作？

意图

运用共享技术有效地支持大量细粒度的对象。[GOF 《设计模式》]

结构图

图1  Flyweight模式结构图

生活中的例子

享元模式使用共享技术有效地支持大量细粒度的对象。公共交换电话网（PSTN）是享元的一个例子。有一些资源例如拨号音发生器、振铃发生器和拨号接收器是必须由所有用户共享的。当一个用户拿起听筒打电话时，他不需要知道使用了多少资源。对于用户而言所有的事情就是有拨号音，拨打号码，拨通电话。

图2  使用拨号音发生器例子的享元模式对象图

Flyweight模式解说

Flyweight在拳击比赛中指最轻量级，即“蝇量级”，这里翻译为“享元”，可以理解为共享元对象（细粒度对象）的意思。提到Flyweight模式都会一般都会用编辑器例子来说明，这里也不例外，但我会尝试着通过重构来看待Flyweight模式。考虑这样一个字处理软件，它需要处理的对象可能有单个的字符，由字符组成的段落以及整篇文档，根据面向对象的设计思想和Composite模式，不管是字符还是段落，文档都应该作为单个的对象去看待，这里只考虑单个的字符，不考虑段落及文档等对象，于是可以很容易的得到下面的结构图：

图3

示意性实现代码：

// "Charactor"
public abstract class Charactor
{
    //Fields
    protected char _symbol;

    protected int _width;

    protected int _height;

    protected int _ascent;

    protected int _descent;

    protected int _pointSize;

    //Method
    public abstract void Display();
}

// "CharactorA"
public class CharactorA : Charactor
{
    // Constructor
    public CharactorA()
    {
      this._symbol = ‘A‘;
      this._height = 100;
      this._width = 120;
      this._ascent = 70;
      this._descent = 0;
      this._pointSize = 12;
    }

    //Method
    public override void Display()
    {
        Console.WriteLine(this._symbol);
    }
}

// "CharactorB"
public class CharactorB : Charactor
{
    // Constructor
    public CharactorB()
    {
        this._symbol = ‘B‘;
        this._height = 100;
        this._width = 140;
        this._ascent = 72;
        this._descent = 0;
        this._pointSize = 10;
    }

    //Method
    public override void Display()
    {
        Console.WriteLine(this._symbol);
    }
}

// "CharactorC"
public class CharactorC : Charactor
{
    // Constructor
    public CharactorC()
    {
        this._symbol = ‘C‘;
        this._height = 100;
        this._width = 160;
        this._ascent = 74;
        this._descent = 0;
        this._pointSize = 14;
    }

    //Method
    public override void Display()
    {
        Console.WriteLine(this._symbol);
    }
}

好了，现在看到的这段代码可以说是很好地符合了面向对象的思想，但是同时我们也为此付出了沉重的代价，那就是性能上的开销，可以想象，在一篇文档中，字符的数量远不止几百个这么简单，可能上千上万，内存中就同时存在了上千上万个Charactor对象，这样的内存开销是可想而知的。进一步分析可以发现，虽然我们需要的Charactor实例非常多，这些实例之间只不过是状态不同而已，也就是说这些实例的状态数量是很少的。所以我们并不需要这么多的独立的Charactor实例，而只需要为每一种Charactor状态创建一个实例，让整个字符处理软件共享这些实例就可以了。看这样一幅示意图：

图4

现在我们看到的A，B，C三个字符是共享的，也就是说如果文档中任何地方需要这三个字符，只需要使用共享的这三个实例就可以了。然而我们发现单纯的这样共享也是有问题的。虽然文档中的用到了很多的A字符，虽然字符的symbol等是相同的，它可以共享；但是它们的pointSize却是不相同的，即字符在文档中中的大小是不相同的，这个状态不可以共享。为解决这个问题，首先我们将不可共享的状态从类里面剔除出去，即去掉pointSize这个状态（只是暂时的J），类结构图如下所示：

图5

示意性实现代码：

// "Charactor"
public abstract class Charactor
{
    //Fields
    protected char _symbol;

    protected int _width;

    protected int _height;

    protected int _ascent;

    protected int _descent;

    //Method
    public abstract void Display();
}

// "CharactorA"
public class CharactorA : Charactor
{
    // Constructor
    public CharactorA()
    {
        this._symbol = ‘A‘;
        this._height = 100;
        this._width = 120;
        this._ascent = 70;
        this._descent = 0;
    }

    //Method
    public override void Display()
    {
        Console.WriteLine(this._symbol);
    }
}

// "CharactorB"
public class CharactorB : Charactor
{
    // Constructor
    public CharactorB()
    {
        this._symbol = ‘B‘;
        this._height = 100;
        this._width = 140;
        this._ascent = 72;
        this._descent = 0;
    }

    //Method
    public override void Display()
    {
        Console.WriteLine(this._symbol);
    }
}

// "CharactorC"
public class CharactorC : Charactor
{
    // Constructor
    public CharactorC()
    {
        this._symbol = ‘C‘;
        this._height = 100;
        this._width = 160;
        this._ascent = 74;
        this._descent = 0;
    }

    //Method
    public override void Display()
    {
        Console.WriteLine(this._symbol);
    }
}

好，现在类里面剩下的状态都可以共享了，下面我们要做的工作就是控制Charactor类的创建过程，即如果已经存在了“A”字符这样的实例，就不需要再创建，直接返回实例；如果没有，则创建一个新的实例。如果把这项工作交给Charactor类，即Charactor类在负责它自身职责的同时也要负责管理Charactor实例的管理工作，这在一定程度上有可能违背类的单一职责原则，因此，需要一个单独的类来做这项工作，引入CharactorFactory类，结构图如下：

图6

示意性实现代码：

// "CharactorFactory"
public class CharactorFactory
{
    // Fields
    private Hashtable charactors = new Hashtable();

    // Constructor
    public CharactorFactory()
    {
        charactors.Add("A", new CharactorA());
        charactors.Add("B", new CharactorB());
        charactors.Add("C", new CharactorC());
    }

    // Method
    public Charactor GetCharactor(string key)
    {
        Charactor charactor = charactors[key] as Charactor;

        if (charactor == null)
        {
            switch (key)
            {
                case "A": charactor = new CharactorA(); break;
                case "B": charactor = new CharactorB(); break;
                case "C": charactor = new CharactorC(); break;
                //
            }
            charactors.Add(key, charactor);
        }
        return charactor;
    }
}

到这里已经完全解决了可以共享的状态（这里很丑陋的一个地方是出现了switch语句，但这可以通过别的办法消除，为了简单期间我们先保持这种写法）。下面的工作就是处理刚才被我们剔除出去的那些不可共享的状态，因为虽然将那些状态移除了，但是Charactor对象仍然需要这些状态，被我们剥离后这些对象根本就无法工作，所以需要将这些状态外部化。首先会想到一种比较简单的解决方案就是对于不能共享的那些状态，不需要去在Charactor类中设置，而直接在客户程序代码中进行设置，类结构图如下：

图7

示意性实现代码：

public class Program
{
    public static void Main()
    {
        Charactor ca = new CharactorA();
        Charactor cb = new CharactorB();
        Charactor cc = new CharactorC();

        //显示字符

        //设置字符的大小ChangeSize();
    }

    public void ChangeSize()
    {
        //在这里设置字符的大小
    }
}

按照这样的实现思路，可以发现如果有多个客户端程序使用的话，会出现大量的重复性的逻辑，用重构的术语来说是出现了代码的坏味道，不利于代码的复用和维护；另外把这些状态和行为移到客户程序里面破坏了封装性的原则。再次转变我们的实现思路，可以确定的是这些状态仍然属于Charactor对象，所以它还是应该出现在Charactor类中，对于不同的状态可以采取在客户程序中通过参数化的方式传入。类结构图如下：

图8

示意性实现代码：

// "Charactor"
public abstract class Charactor
{
    //Fields
    protected char _symbol;

    protected int _width;

    protected int _height;

    protected int _ascent;

    protected int _descent;

    protected int _pointSize;

    //Method
    public abstract void SetPointSize(int size);
    public abstract void Display();
}

// "CharactorA"
public class CharactorA : Charactor
{
    // Constructor
    public CharactorA()
    {
        this._symbol = ‘A‘;
        this._height = 100;
        this._width = 120;
        this._ascent = 70;
        this._descent = 0;
    }

    //Method
    public override void SetPointSize(int size)
    {
        this._pointSize = size;
    }

    public override void Display()
    {
        Console.WriteLine(this._symbol +
          "pointsize:" + this._pointSize);
    }
}

// "CharactorB"
public class CharactorB : Charactor
{
    // Constructor
    public CharactorB()
    {
        this._symbol = ‘B‘;
        this._height = 100;
        this._width = 140;
        this._ascent = 72;
        this._descent = 0;
    }

    //Method
    public override void SetPointSize(int size)
    {
        this._pointSize = size;
    }

    public override void Display()
    {
        Console.WriteLine(this._symbol +
          "pointsize:" + this._pointSize);
    }
}

// "CharactorC"
public class CharactorC : Charactor
{
    // Constructor
    public CharactorC()
    {
        this._symbol = ‘C‘;
        this._height = 100;
        this._width = 160;
        this._ascent = 74;
        this._descent = 0;
    }

    //Method
    public override void SetPointSize(int size)
    {
        this._pointSize = size;
    }

    public override void Display()
    {
        Console.WriteLine(this._symbol +
          "pointsize:" + this._pointSize);
    }
}

// "CharactorFactory"
public class CharactorFactory
{
    // Fields
    private Hashtable charactors = new Hashtable();

    // Constructor
    public CharactorFactory()
    {
        charactors.Add("A", new CharactorA());
        charactors.Add("B", new CharactorB());
        charactors.Add("C", new CharactorC());
    }

    // Method
    public Charactor GetCharactor(string key)
    {
        Charactor charactor = charactors[key] as Charactor;

        if (charactor == null)
        {
            switch (key)
            {
                case "A": charactor = new CharactorA(); break;
                case "B": charactor = new CharactorB(); break;
                case "C": charactor = new CharactorC(); break;
                //
            }
            charactors.Add(key, charactor);
        }
        return charactor;
    }
}

public class Program
{
    public static void Main()
    {
        CharactorFactory factory = new CharactorFactory();

        // Charactor "A"
        CharactorA ca = (CharactorA)factory.GetCharactor("A");
        ca.SetPointSize(12);
        ca.Display();

        // Charactor "B"
        CharactorB cb = (CharactorB)factory.GetCharactor("B");
        ca.SetPointSize(10);
        ca.Display();

        // Charactor "C"
        CharactorC cc = (CharactorC)factory.GetCharactor("C");
        ca.SetPointSize(14);
        ca.Display();
    }
}

可以看到这样的实现明显优于第一种实现思路。好了，到这里我们就到到了通过Flyweight模式实现了优化资源的这样一个目的。在这个过程中，还有如下几点需要说明：

1．引入CharactorFactory是个关键，在这里创建对象已经不是new一个Charactor对象那么简单，而必须用工厂方法封装起来。

2．在这个例子中把Charactor对象作为Flyweight对象是否准确值的考虑，这里只是为了说明Flyweight模式，至于在实际应用中，哪些对象需要作为Flyweight对象是要经过很好的计算得知，而绝不是凭空臆想。

3．区分内外部状态很重要，这是享元对象能做到享元的关键所在。

到这里，其实我们的讨论还没有结束。有人可能会提出如下问题，享元对象（Charactor）在这个系统中相对于每一个内部状态而言它是唯一的，这跟单件模式有什么区别呢？这个问题已经很好回答了，那就是单件类是不能直接被实例化的，而享元类是可以被实例化的。事实上在这里面真正被设计为单件的应该是享元工厂（不是享元）类，因为如果创建很多个享元工厂的实例，那我们所做的一切努力都是白费的，并没有减少对象的个数。修改后的类结构图如下：

图9

示意性实现代码：

// "CharactorFactory"
public class CharactorFactory
{
    // Fields
    private Hashtable charactors = new Hashtable();

    private CharactorFactory instance;
    // Constructor
    private CharactorFactory()
    {
        charactors.Add("A", new CharactorA());
        charactors.Add("B", new CharactorB());
        charactors.Add("C", new CharactorC());
    }

    // Property
    public CharactorFactory Instance
    {
        get
        {
            if (instance != null)
            {
                instance = new CharactorFactory();
            }
            return instance;
        }
    }

    // Method
    public Charactor GetCharactor(string key)
    {
        Charactor charactor = charactors[key] as Charactor;

        if (charactor == null)
        {
            switch (key)
            {
                case "A": charactor = new CharactorA(); break;
                case "B": charactor = new CharactorB(); break;
                case "C": charactor = new CharactorC(); break;
                //
            }
            charactors.Add(key, charactor);
        }
        return charactor;
    }
}

.NET框架中的Flyweight

Flyweight更多时候的时候一种底层的设计模式，在我们的实际应用程序中使用的并不是很多。在.NET中的String类型其实就是运用了Flyweight模式。可以想象，如果每次执行string s1 = “abcd”操作，都创建一个新的字符串对象的话，内存的开销会很大。所以.NET中如果第一次创建了这样的一个字符串对象s1，下次再创建相同的字符串s2时只是把它的引用指向“abcd”，这样就实现了“abcd”在内存中的共享。可以通过下面一个简单的程序来演示s1和s2的引用是否一致：

public class Program
{
    public static void Main(string[] args)
    {
        string s1 = "abcd";
        string s2 = "abcd";

        Console.WriteLine(Object.ReferenceEquals(s1,s2));

        Console.ReadLine();
    }
}

可以看到，输出的结果为True。但是大家要注意的是如果再有一个字符串s3，它的初始值为“ab”，再对它进行操作s3 = s3 + “cd”，这时虽然s1和s3的值相同，但是它们的引用是不同的。关于String的详细情况大家可以参考SDK，这里不再讨论了。

效果及实现要点

1．面向对象很好的解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。

2．Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。

3．享元模式的优点在于它大幅度地降低内存中对象的数量。但是，它做到这一点所付出的代价也是很高的：享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。另外它将享元对象的状态外部化，而读取外部状态使得运行时间稍微变长。

适用性

当以下所有的条件都满足时，可以考虑使用享元模式：

1、   一个系统有大量的对象。

2、   这些对象耗费大量的内存。

3、   这些对象的状态中的大部分都可以外部化。

4、   这些对象可以按照内蕴状态分成很多的组，当把外蕴对象从对象中剔除时，每一个组都可以仅用一个对象代替。

5、   软件系统不依赖于这些对象的身份，换言之，这些对象可以是不可分辨的。

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

总结

Flyweight模式解决的是由于大量的细粒度对象所造成的内存开销的问题，它在实际的开发中并不常用，但是作为底层的提升性能的一种手段却很有效。

参考资料

Erich Gamma等，《设计模式：可复用面向对象软件的基础》，机械工业出版社

Robert C.Martin，《敏捷软件开发：原则、模式与实践》，清华大学出版社

阎宏，《Java与模式》，电子工业出版社

Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社

MSDN WebCast 《C#面向对象设计模式纵横谈(12)：Flyweight享元模式(结构型模式)》

http://www.dofactory.com/

时间： 2024-10-07 05:45:38

NET设计模式 第二部分 结构性模式(12)：享元模式（Flyweight Pattern）的相关文章

设计模式——12.享元模式

1. 模式动机 面向对象技术可以很好地解决一些灵活性或可扩展性问题,但在很多情况下需要在系统中增加类和对象的个数.当对象数量太多时,将导致运行代价过高,带来性能下降等问题. 享元模式正是为解决这一类问题而诞生的.享元模式通过共享技术实现相同或相似对象的重用. 在享元模式中可以共享的相同内容称为内部状态(IntrinsicState),而那些需要外部环境来设置的不能共享的内容称为外部状态(Extrinsic State),由于区分了内部状态和外部状态,因此可以通过设置不同的外部状态使得相同的对象可

java/android 设计模式学习笔记（13）---享元模式

这篇我们来介绍一下享元模式(Flyweight Pattern),Flyweight 代表轻量级的意思,享元模式是对象池的一种实现.享元模式用来尽可能减少内存使用量,它适合用于可能存在大量重复对象的场景,缓存可共享的对象,来达到对象共享和避免创建过多对象的效果,这样一来就可以提升性能,避免内存移除和频繁 GC 等. 享元模式的一个经典使用案例是文本系统中图形显示所用的数据结构,一个文本系统能够显示的字符种类就是那么几十上百个,那么就定义这么些基础字符对象,存储每个字符的显示外形和其他的格式化数据

15结构型模式之享元模式

概念 Flyweight模式也叫享元模式,是构造型模式之一,它通过与其他类似对象共享数据来减小内存占用. 角色和职责 抽象享元角色: 所有具体享元类的父类,规定一些需要实现的公共接口. 具体享元角色: 抽象享元角色的具体实现类,并实现了抽象享元角色规定的方法. 享元工厂角色: 负责创建和管理享元角色. 使用场景: 是以共享的方式,高效的支持大量的细粒度的对象. 案例 //相同的信息,但不是同一个人. #include <iostream> using namespace std; #inclu

设计模式-12 享元模式（结构型模式）

一 享元模式 享元模式的主要目的是实现对象的共享,即共享池,当系统中对象多的时候可以减少内存的开销,通常与工厂模式一起使用. 主要解决:在有大量对象时,有可能会造成内存溢出,我们把其中共同的部分抽象出来,如果有相同的业务请求,直接返回在内存中已有的对象,避免重新创建. 关键代码:存储相似的对象 使用场景: 1.系统有大量相似对象. 2.需要缓冲池的场景. 类图 : 二 实现代码 Java里面的JDBC连接池,适用于作共享的一些个对象,他们有一些共有的属性,就拿数据库连接 池来说,url.driv

C#设计模式(12)——享元模式（Flyweight Pattern）

一.引言 在软件开发过程,如果我们需要重复使用某个对象的时候,如果我们重复地使用new创建这个对象的话,这样我们在内存就需要多次地去申请内存空间了,这样可能会出现内存使用越来越多的情况,这样的问题是非常严重,然而享元模式可以解决这个问题,下面具体看看享元模式是如何去解决这个问题的. 二.享元模式的详细介绍 在前面说了,享元模式可以解决上面的问题了,在介绍享元模式之前,让我们先要分析下如果去解决上面那个问题,上面的问题就是重复创建了同一个对象,如果让我们去解决这个问题肯定会这样想:"既然都是同一个

设计模式C#实现（十三）——享元模式（蝇量模式）

意图 0 适用性 1 结构 2 实现 3 效果 4 参考 5 意图 运用共享技术有效地支持大量细粒度的对象. 适用性 当以下情况都成立时使用: 一个程序使用了大量的对象 完全由于使用大量对象造成很大存储开销 对象的大多数状态都可以变为外部状态 如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象 应用程序不依赖对象标识 结构 以下摘自参考1 享元模式采用一个共享来避免大量拥有相同内容对象的开销.这种开销最常见.最直观的就是内存的损耗.享元对象能做到共享的关键是区分内蕴状态(Inte

12.享元模式(Flyweight Pattern)

using System; using System.Collections; namespace ConsoleApplication5 { class Program { /// <summary> /// 在软件开发过程,如果我们需要重复使用某个对象的时候, /// 如果我们重复地使用new创建这个对象的话,这样我们在内存就需要多次地去申请内存空间了, /// 这样可能会出现内存使用越来越多的情况,这样的问题是非常严重,然而享元模式可以解决这个问题, /// 下面具体看看享元模式是如何去

设计模式之二十二：享元模式(FlyWeight)

享元模式: 使用共享技术有效地支持大量细粒度的对象. Use sharing to support large numbers of fine-grained objects efficiently. 这个设计模式和它的名字一样核心是为了共享代码. UML图: 主要包括: FlyWeight:声明了一个接口,通过这个接口所有的FlyWeight能够接受并作用于外部的状态. ConcreteFlyWeight:实现了FlyWeight声明的接口,并且可能会增加一些内部状态. UnSharedCon

用最简单的例子说明设计模式（三）之责任链、建造者、适配器、代理模式、享元模式

责任链模式 一个请求有多个对象来处理,这些对象是一条链,但具体由哪个对象来处理,根据条件判断来确定,如果不能处理会传递给该链中的下一个对象,直到有对象处理它为止 使用场景 1)有多个对象可以处理同一个请求,具体哪个对象处理该请求待运行时刻再确定 2)在不明确指定接收者的情况下,向多个对象中的一个提交一个请求 3)可动态指定一组对象处理请求,客户端可以动态创建职责链来处理请求 public class Chain { public abstract class Handler { private

设计模式---对象性能模式之享元模式（Flyweight）

一:概念 通过与其他类似对象共享数据来减少内存占用 如果一个应用程序使用了太多的对象, 就会造成很大的存储开销. 特别是对于大量轻量级 (细粒度)的对象,比如在文档编辑器的设计过程中,我们如果为每个字母创建一个对象的话,系统可能会因为大量的对象而造成存储开销的浪费.例如一个字母“a”在文档中出现了100000 次,而实际上我们可以让这一万个字母“a”共享一个对象,当然因为在不同的位置可能字母“a”有不同的显示效果(例如字体和大小等设置不同) ,在这种情况我们可以为将对象的状态分为“外部状态”和“