设计模式11: Flyweight 享元模式(结构型模式)

Flyweight 享元模式(结构型模式)

面向对象的代价

面向对象很好的解决了系统抽象性的问题,同时在大多数情况下也不会损及系统的性能。但是,在某些特殊应用中,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。

动机(Motivation)

采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,而带来很高的运行代价——主要指内存需求方面的代价。

如何避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象方式进行操作?

意图(Intent)

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

    class Font//(4+4+4)bytes+8bytes=20bytes (8bytes:4bytes垃圾回收控制位,4bytes虚表指针)
    {
        public string fontName;//4bytes 只是举例子,实际中应该用属性的
        public int size;//4bytes
        public Color color;//4bytes        public Font(string fontName,int size,Color color)        {            this.fontName = fontName;            this.size = size;            this.color = color;        }
    }
    /*
     4:string fontName,字符串比较特殊,由于已经用了字符串池,就不考虑它在堆中的大小,这里只计算了它的指针大小。
     4:int size
     4:Color color
     8:4bytes垃圾回收控制位+4bytes虚表指针
     共20bytes
     */

    class Charactor//(2+4+20+2)bytes+8bytes=36bytes
    {
        pubic char chr;//2bytes
        pubic Font font;//20bytes
    }
    /*
     2:char chr
     4:Font font,指针占4bytes
     20:Font font 堆中大小
     2:32位系统的4bytes填充效应,char chr只占2bytes,补充了2bytes
     8:4bytes垃圾回收控制位+4bytes虚表指针
     共36bytes
     */

    class System
    {
        public static void Main()
        {

            List<Charactor> list=new List<Charactor>();
            for (int i = 0; i < 100000; i++)
            {
                Charactor charactor=new Charactor();
                list.Add(charactor);
            }
            //36bytes*100000=3600000bytes≈3600k≈3.6M
            //如果是1千万个对象结果就是大约360M,这就太大了,要考虑享元模式。
        }
    }

当Charactor 对象个数非常多时,就考虑使用享元模式了。需要对Charactor 进行改造:

    class Charactor
    {
        public char chr;
        private Font font;
        private static Dictionary<string,Font> dicFont;

        public Font CFunt
        {
            get { return font; }
            set
            {
                string key = value.fontName + value.size + value.color;

                if (dicFont.Keys.Contains(key))
                {
                    this.font = dicFont[key];
                }
                else
                {
                    dicFont.Add(key, value);
                    this.font = value;
                }
            }
        }
    }

这样当出现重复的字体的时候就不会占用多余的空间了。

            Charactor c1=new Charactor();
            Font f1= new Font("宋体", 10, Color.Red);
            c1.CFunt = f1;

            Charactor c2 = new Charactor();
            Font f2 = new Font("宋体", 10, Color.Red);
            c2.CFunt = f2;

f1和f2是不同对象,它们指向不同的内存地址,但是在给c1,和c2的CFont赋值时,由于用了Dictionary<string,Font>,对c2的CFont就没有分配新的内存空间。当对象非常多的时候,这样可以节省很多的空间。

.NET中字符串池就是运用了享元模式。

Flyweight模式的几个要点

  • 面向对象很好地解决了抽象性的问题,但是作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题。
  • Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状态的处理。
  • 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细的根据具体应用情况进行评估,而不能凭空臆断。
时间: 2024-09-30 21:29:58

设计模式11: Flyweight 享元模式(结构型模式)的相关文章

Flyweight 享元(结构型)

一:描述:(该模式实际应用较少) Flyweight 享元模式是对大量细粒度的元素进行共享和重用.减少对象的创建减轻内存: 注和单例模式不同的是:享元模式的各个对象佣有各自的行为并可实例化,单例模式的各个对象佣有一样的行为并不可直接实例化. 二:模式图: 三:实现代码简单例子: 1.创建抽像的享元类 2.创建共享的享元对象(可以有很多这种对像) 3.创建非共享的享元对象 4.创建享元的工厂 5.客端的使用和效果;

设计模式(十二): Flyweight享元模式 -- 结构型模式

说明: 相对于其它模式,Flyweight模式在PHP实现似乎没有太大的意义,因为PHP的生命周期就在一个请求,请求执行完了,php占用的资源都被释放.我们只是为了学习而简单做了介绍. 1. 概述 面向对象技术可以很好地解决系统一些灵活性或可扩展性或抽象性的问题,但在很多情况下需要在系统中增加类和对象的个数.当对象数量太多时,将导致运行代价过高,带来性能下降等问题.比如:例子1:图形应用中的图元等对象.字处理应用中的字符对象等. 2.解决方案: 享元模式(Flyweight):对象结构型模式运用

设计模式(九):Composite组合模式 -- 结构型模式

1. 概述 在数据结构里面,树结构是很重要,我们可以把树的结构应用到设计模式里面. 例子1:就是多级树形菜单. 例子2:文件和文件夹目录 2.问题 我们可以使用简单的对象组合成复杂的对象,而这个复杂对象有可以组合成更大的对象.我们可以把简单这些对象定义成类,然后定义一些容器类来存储这些简单对象.客户端代码必须区别对象简单对象和容器对象,而实际上大多数情况下用户认为它们是一样的.对这些类区别使用,使得程序更加复杂.递归使用的时候跟麻烦,而我们如何使用递归组合,使得用户不必对这些类进行区别呢? 3.

设计模式(十一):FACADE外观模式 -- 结构型模式

1. 概述 外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性.例子1:一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计. 2. 问题 为了降低复杂性,常常将系统划分为若干个子系统.但是如何做到各个系统之间的通信和相互依赖关系达到最小呢? 3. 解决方案 外观模式:为子系统中的一组接口提供一个一致的界面,

设计模式(八):Bridge桥接模式 -- 结构型模式

1. 概述 在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度? 例子1:设想如果要绘制矩形.圆形.椭圆.正方形,我们至少需要4个形状类,但是如果绘制的图形需要具有不同的颜色,如红色.绿色.蓝色等,此时至少有如下两种设计方案: •第一种设计方案是为每一种形状都提供一套各种颜色的版本. •第二种设计方案是根据实际需要对形状和颜色进行组合. 方案1: 方案2:  

一起学java设计模式--代理模式(结构型模式)

代理模式 应用软件所提供的桌面快捷方式是快速启动应用程序的代理,桌面快捷方式一般使用一张小图片来表示(Picture),通过调用快捷方式的run()方法将调用应用软件(Application)的run()方法.使用代理模式模拟该过程,绘制类图并编程实现. package ProxyPattern; interface Software { void run(); } class Application implements Software { public void run() { Syste

设计模式(十):Decorator装饰者模式 -- 结构型模式

1. 概述 若你从事过面向对象开发,实现给一个类或对象增加行为,使用继承机制,这是所有面向对象语言的一个基本特性.如果已经存在的一个类缺少某些方法,或者须要给方法添加更多的功能(魅力),你也许会仅仅继承这个类来产生一个新类—这建立在额外的代码上. 通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法.但是这种方法是静态的,用户不能控制增加行为的方式和时机.如果  你希望改变一个已经初始化的对象的行为,你怎么办?或者,你希望继承许多类的行为,改怎么办?前一个,只能在于运行时完成,后者

设计模式(十三): Proxy代理模式 -- 结构型模式

  设计模式(十一)代理模式Proxy(结构型) 1.概述 因为某个对象消耗太多资源,而且你的代码并不是每个逻辑路径都需要此对象, 你曾有过延迟创建对象的想法吗 ( if和else就是不同的两条逻辑路径) ? 你有想过限制访问某个对象,也就是说,提供一组方法给普通用户,特别方法给管理员用户?以上两种需求都非常类似,并且都需要解决一个更大的问题:你如何提供一致的接口给某个对象让它可以改变其内部功能,或者是从来不存在的功能? 可以通过引入一个新的对象,来实现对真实对象的操作或者将新的对象作为真实对象

Flyweight享元模式(结构型模式)

1.面向对象的缺点 虽然OOP能很好的解决系统抽象的问题,并且在大多数的情况下,也不会损失系统的性能.但是在某些特殊的业务下,由于对象的数量太多,采用面向对象会给系统带来难以承受的内存开销.示例代码如下: /// <summary> /// Word文字的Font样式 /// </summary> public class Font //8+8(继承object的虚表指针4个字节.垃圾收集同步占4个字节)=16个字节 { public Font(string fontName, i

(转)Java经典设计模式(2):七大结构型模式(附实例和详解)

原文出处: 小宝鸽 总体来说设计模式分为三大类:创建型模式.结构型模式和行为型模式. 博主的上一篇文章已经提到过创建型模式,此外该文章还有设计模式概况和设计模式的六大原则.设计模式的六大原则是设计模式的核心思想,详情请看博主的另外一篇文章:Java经典设计模式之五大创建模式(附实例和详解). 接下来我们看看结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式.其中适配器模式主要分为三类:类的适配器模式.对象的适配器模式.接口的适配器模式.其中的对象的适配器