C++设计模式总结-汇总了全部23种设计模式的详细说明
第15种：亨元模式
一、亨元模式基本介绍
1.1 模式定义与核心思想
亨元模式（Flyweight Pattern）是一种结构型设计模式，其核心目标是通过共享技术减少大量细粒度对象的资源消耗，它旨在通过共享对象来减少内存使用和提高性能。该模式通过将对象的状态分为内部状态（可以共享的状态）和外部状态（不可共享的状态），将那些具有相同内部状态的对象进行共享，从而避免创建大量重复的对象，达到节省内存的目的。尤其适用于需要创建海量相似对象的场景。它将对象状态分为内部状态（Intrinsic State）和外部状态（Extrinsic State），内部状态可共享，外部状态由客户端维护。
经典比喻：
假设某快餐连锁店需制作10万份汉堡套餐，若每份套餐都要独立存储配料信息，将严重浪费内存。亨元模式将固定配料（面包、肉饼）作为内部状态共享，仅记录顾客定制信息（酱料、配菜）作为外部状态。
1.2 模式诞生背景
在游戏开发中，当需要渲染10万棵树木时，若每棵树独立存储纹理、模型数据将导致内存爆炸。亨元模式通过分离树木类型（共享数据）与位置坐标（独立数据），使内存消耗从O(N)降为O(1)+O(N)。
二、内部原理与结构解析
2.1 享元里的角色划分
抽象亨元（Flyweight）：定义了亨元对象的共享接口（如draw()方法），声明了操作外部状态的方法。
具体亨元（ConcreteFlyweight）：实现抽象亨元的内部状态存储接口，并可以通过操作方法接受和处理外部状态。
亨元工厂（FlyweightFactory）：负责创建和管理亨元对象。它维护一个亨元对象池，当客户端请求亨元对象时，先检查池中是否已有该对象，如果有则直接返回，没有则创建新的亨元对象并放入池中。
非共享享元（UnsharedConcreteFlyweight）：特殊场景的独立对象；
客户端（Client）：通过亨元工厂获取亨元对象，并为其提供外部状态，维护外部状态并调用享元对象；
2.2 关键实现原理
// 抽象享元：棋子接口
class ChessPiece {
public:
virtual void draw(int x, int y) = 0; // x,y为外部状态
};
// 具体享元：黑棋（内部状态固定）
class BlackChess : public ChessPiece {
public:
void draw(int x, int y) override {
cout << "在(" << x << "," << y << ")绘制黑棋" << endl;
}
};
// 享元工厂
class ChessFactory {
private:
static map<string, ChessPiece*> pool; // 对象池
public:
static ChessPiece* getChess(const string& color) {
if (pool.find(color) == pool.end()) {
if (color == "黑") pool[color] = new BlackChess();
else if (color == "白") pool[color] = new WhiteChess();
}
return pool[color];
}
};
map<string, ChessPiece*> ChessFactory::pool;
// 客户端调用
ChessPiece* black1 = ChessFactory::getChess("黑");
black1->draw(10, 20); // 外部状态由客户端传递
实现要点：
- 工厂类使用静态对象池管理享元实例；
- 所有具体享元类必须为不可变对象；
- 外部状态通过方法参数传递，不存储在享元中；
三、典型应用场景
3.1 图形渲染系统
在图形处理系统中，可能会有大量的图形对象，如线条、矩形、圆形等。这些图形对象的颜色、线条宽度等属性可以作为内部状态共享，而图形的位置、大小等属性可以作为外部状态。通过亨元模式，可以减少图形对象的创建数量，提高图形处理的效率。
-
案例1：游戏引擎
内部状态：3D模型、纹理贴图（数百MB级别数据）；
外部状态：坐标、旋转角度（每帧更新）；
效果：比如要渲染10万角色，内存消耗会降低一大半； -
案例2：文档编辑器
内部状态：字符字体、字号（样式对象）；
外部状态：字符位置、颜色；
优化：100万字符文档，样式对象仅保留100种常用组合；
3.2 基础设施与中间件
亨元模式的亨元工厂实际上起到了缓存的作用，当需要频繁创建和销毁相同对象时，使用亨元模式可以避免重复创建对象，提高系统性能。例如，在一个游戏中，可能会有大量的子弹对象，如果每次发射子弹都创建一个新对象，会消耗大量资源。通过亨元模式，可以将子弹的基本属性（如外观、速度等）作为内部状态共享，而将子弹的位置、方向等作为外部状态，从而提高游戏的性能。
-
案例3：数据库连接池
内部状态：数据库IP、协议版本；
外部状态：当前事务状态、超时时间；
优势：复用连接对象，避免频繁创建销毁； -
案例4：物联网设备管理
内部状态：设备型号参数（传感器精度、通信协议）；
外部状态：实时采集数据、网络状态；
应用：10万台设备监控，内存占用会大量减少；
四、使用方法与实现步骤
标准实现流程
步骤1：识别状态类型
内部状态：对象中不变的共性数据（如棋子的颜色）
外部状态：对象间变化的个性数据（如棋子的位置）
步骤2：创建享元接口
class Flyweight {
public:
virtual void operation(const string& extrinsicState) = 0;
};
步骤3：实现具体享元类
class ConcreteFlyweight : public Flyweight {
private:
string intrinsicState; // 内部状态
public:
ConcreteFlyweight(const string& state) : intrinsicState(state) {}
void operation(const string& extrinsicState) override {
cout << "内部状态:" << intrinsicState
<< " 外部状态:" << extrinsicState << endl;
}
};
步骤4：构建享元工厂
class FlyweightFactory {
private:
unordered_map<string, Flyweight*> pool;
public:
Flyweight* getFlyweight(const string& key) {
if (pool.find(key) == pool.end()) {
pool[key] = new ConcreteFlyweight(key);
}
return pool[key];
}
};
步骤5：客户端调用
FlyweightFactory factory;
Flyweight* fw1 = factory.getFlyweight(" 共享数据A");
fw1->operation("外部参数1"); // 输出：内部状态:A 外部状态:1
Flyweight* fw2 = factory.getFlyweight(" 共享数据A");
cout << (fw1 == fw2) << endl; // 输出1，证明对象被复用
五、常见问题与解决方案
5.1 典型误区与挑战
| 问题类型 | 表现症状 | 解决方案 |
|---|---|---|
| 线程安全问题 | 多线程并发获取享元导致状态错乱 | 可以使用工厂类加互斥锁，C++11使用std::mutex |
| 内存泄漏 | 享元对象未释放 | 可以引入智能指针（如shared_ptr）管理对象池 |
| 状态混淆 | 错误地将外部状态存入享元 | 严格审核接口设计，外部状态仅通过参数传递 |
| 过度使用 | 简单场景强行拆分状态 | 评估对象数量，1K以下对象数量级的无需亨元 |
5.2 性能优化技巧
延迟加载：首次请求时创建对象，减少启动时间；
缓存策略：LRU算法淘汰低频使用的享元；
批量处理：合并外部状态传递次数（如渲染批次提交）；
六、总结与模式对比
6.1 核心优势
内存优化：减少对象数量级（从O(N)到O(M)，M<<N）；
性能提升：降低GC压力，提高缓存命中率；
架构清晰：强制分离不变与可变逻辑；
6.2 适用性评估
推荐场景：
- 需要创建海量相似对象（如粒子系统）；
- 对象具备明显的内/外部状态划分；
- 系统内存敏感，需极致优化；
不适用场景：
- 对象状态全部为外部状态
- 系统已存在高效对象池实现
- 对象数量级较小（比如<1000个对象）
6.3 与其他模式对比
| 模式 | 区别点 | 典型场景应用 |
|---|---|---|
| 单例模式 | 全局唯一对象 vs 共享多个对象 | 配置管理器 vs 字符样式 |
| 原型模式 | 通过克隆生成对象 vs 通过共享复用对象 | 复杂对象初始化 vs 轻量级对象池 |
| 对象池 | 关注对象复用生命周期 vs 关注状态分离 | 数据库连接 vs 游戏实体属性 |
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
