• 【Flyweight模式】C++设计模式——享元模式



        C++设计模式大全,23种设计模式合集详解—👉(点我跳转)

    一、设计流程探讨

    1. 问题引出
      假如你希望在长时间工作后放松一下, 所以开发了一款简单的游戏: 玩家们在地图上移动并相互射击。 你决定实现一个真实的粒子系统, 并将其作为游戏的特色。 大量的子弹、 导弹和爆炸弹片会在整个地图上穿行, 为玩家提供紧张刺激的游戏体验。
      开发完成后, 你推送提交了最新版本的程序, 并在编译游戏后将其发送给了一个朋友进行测试。 尽管该游戏在你的电脑上完美运行, 但是你的朋友却无法长时间进行游戏: 游戏总是会在他的电脑上运行几分钟后崩溃。 在研究了几个小时的调试消息记录后, 你发现导致游戏崩溃的原因是内存容量不足。 朋友的设备性能远比不上你的电脑, 因此游戏运行在他的电脑上时很快就会出现问题。
      真正的问题与粒子系统有关。 每个粒子 (一颗子弹、 一枚导弹或一块弹片) 都由包含完整数据的独立对象来表示。 当玩家在游戏中鏖战进入高潮后的某一时刻, 游戏将无法在剩余内存中载入新建粒子, 于是程序就崩溃了。
    在这里插入图片描述
      仔细观察 粒子Par­ti­cle 类, 你可能会注意到 颜色(color) 和 精灵图(sprite) 这两个成员变量所消耗的内存要比其他变量多得多。 更糟糕的是, 对于所有的粒子来说, 这两个成员变量所存储的数据几乎完全一样 (比如所有子弹的颜色和精灵图都一样)。
    在这里插入图片描述
      每个粒子的另一些状态 (坐标、 移动矢量和速度) 则是不同的。 因为这些成员变量的数值会不断变化。 这些数据代表粒子在存续期间不断变化的情景, 但每个粒子的颜色和精灵图则会保持不变。
      对象的常量数据通常被称为内在状态, 其位于对象中, 其他对象只能读取但不能修改其数值。 而对象的其他状态常常能被其他对象 “从外部” 改变, 因此被称为外在状态
      享元模式建议不在对象中存储外在状态, 而是将其传递给依赖于它的一个特殊方法。 程序只在对象中保存内在状态, 以方便在不同情景下重用。 这些对象的区别仅在于其内在状态 (与外在状态相比, 内在状态的变体要少很多), 因此你所需的对象数量会大大削减。
    在这里插入图片描述
      让我们回到游戏中。假如能从粒子类中抽出外在状态, 那么我们只需三个不同的对象(子弹、导弹和弹片)就能表示游戏中的所有粒子。你现在很可能已经猜到了,我们将这样一个仅存储内在状态的对象称为享元。
    2. 外在状态存储
      那么外在状态会被移动到什么地方呢?总得有类来存储它们,对不对?在大部分情况中,它们会被移动到容器对象中,也就是我们应用享元模式前的聚合对象中。
      在我们的例子中, 容器对象就是主要的 游戏Game对象, 其会将所有粒子存储在名为 粒子par­ti­cles的成员变量中。 为了能将外在状态移动到这个类中, 你需要创建多个数组成员变量来存储每个粒子的坐标、 方向矢量和速度。 除此之外, 你还需要另一个数组来存储指向代表粒子的特定享元的引用。 这些数组必须保持同步, 这样你才能够使用同一索引来获取关于某个粒子的所有数据。
    在这里插入图片描述
      更优雅的解决方案是创建独立的情景类来存储外在状态和对享元对象的引用。 在该方法中, 容器类只需包含一个数组。
      稍等! 这样的话情景对象数量不是会和不采用该模式时的对象数量一样多吗? 的确如此, 但这些对象要比之前小很多。 消耗内存最多的成员变量已经被移动到很少的几个享元对象中了。 现在, 一个享元大对象会被上千个情境小对象复用, 因此无需再重复存储数千个大对象的数据。
    在这里插入图片描述

    二、模式介绍

    (1)模式动机
      在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面的代价
      如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?
    (2)模式定义
      运用共享技术有效地支持大量细粒度的对象。
    (3)要点总结
    a). 面向对象很好地解决了抽象性的问题,但是作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。Flyweight主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题。
    b). Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状态的处理。
    c). 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细的根据具体应用情况进行评估,而不能凭空臆断。

    三、代码实现

      上面说的游戏例子及类图已经讲得比较清楚了,我们这里只以 “字体对象” 来简单例举代码实现,采用享元的模式,key 可以看成是字体的名称,而通过 key 可以获得该字体 font 的资源。

    class Font {
    private:
    	// unique object key
    	string key;
    	// object state
    	// ...
    public:
    	Font(const string &key){
    		// ...
    	}
    };
    class FontFactory{
    private:
    	map<string, Font*> fontPool;
    public:
    	Font* GetFont(const string& key){
    		map<string, Font*>::iterator it = fontPool.find(key);
    		if (it != fontPool.end()) {
    			return fontPool[key];
    		} else {
    			Font* font = new Font(key);
    			fontPool[key] = font;
    			return font;
    		}
    	}
    	void clear(){
    		//...
    	}
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
  • 相关阅读:
    Canvas—从入门到案例实现
    “计算机艺术之父”、现代计算机技术先驱查理斯·苏黎去世,享年99岁
    Red Hat Enterprise Linux (RHEL) 9 更新了哪些新特性?
    CodeTalker 踩坑实录
    Redis学习笔记( 入门篇)
    linux环境下安装jdk1.8
    【开源】历史学习网站 JAVA+Vue.js+SpringBoot+MySQL
    Git常用命令(面试+复习)
    算法训练与程序竞赛题目集合(L1)
    环形旋转效果
  • 原文地址:https://blog.csdn.net/u012011079/article/details/126033261