当前位置: 首页 > article >正文

设计模式之享元(Flyweight)模式

前言

        面向对象很好地解决了 “抽象” 的问题,但是不可避免的要付出一定的代价。对于通常情况来讲,面向对象的成本大都可以忽略不计。但是某些情况,面向对象所带来的成本必须谨慎处理

        具体需要自己根据需求去评估

定义

        “对象性能” 模式。运用共享技术有效的支持大量细粒度对象        

动机

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

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

案例

        代码

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 item=fontPool.find(key);
        
        if(item!=footPool.end()){
            return fontPool[key];
        }
        else{
            Font* font = new Font(key);
            fontPool[key]= font;
            return font;
        }

    }
    
    void clear(){
        //...
    }
};

类图

        

总结

        面向对象很好地解决了抽象性的问题,但作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。享元主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题

        享元采用对象共享的方式来降低系统中的对象个数,从而降低细粒度对象对系统带来的内存压力。再具体实现方面,需要注意对象状态的处理

        对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细地根据具体应用情况进行评估,不能凭空臆断


http://www.kler.cn/a/324518.html

相关文章:

  • 力扣刷题日记之150.逆波兰表达式求值
  • MySQL数据库:SQL语言入门 【3】(学习笔记)
  • go 集成swagger 在线接口文档
  • Git 中的 patch 功能
  • SpringMVC数据校验、数据格式化处理、国际化设置
  • 如何编译 Cesium 源码
  • 设计模式小记:构造器
  • QT九月28日
  • 阿里云函数计算 x NVIDIA 加速企业 AI 应用落地
  • 量化金融中的 AI 革命:LLMs 如何重新定义交易策略
  • .NET 开源的功能强大的人脸识别 API
  • 博客摘录「 GD32的flash读、擦除、写操作」2024年9月2日
  • 前端问答:JavaScript 中的??和|| 有啥不同
  • 小程序电量
  • 阿布量化:基于 Python 的量化交易框架
  • 德克威尔FS系列一体式PROFINET协议模块组态步骤
  • 文件和目录
  • YOLOv8最新改进2023 CVPR 结合BiFormer
  • 【Java-JVM】
  • Vue之axios请求
  • 性能优化-数据库索引优化实战指南
  • 【Flume Kafaka实战】Using Kafka with Flume
  • ISA Server配置https踩坑全过程
  • 【初阶数据结构】排序——插入排序
  • Vue.js与Flask/Django全栈开发实战:从零搭建前后端分离的高效Web应用,打造现代化全栈开发体验!
  • HAL库I2C通用驱动程序(HAL I2C Generic Driver)