精读C++20设计模式——结构型设计模式：享元模式

精读C++20设计模式——结构型设计模式：享元模式

前言

​ 现在我们来仔细学习一下享元模式：Flyweight，但是我觉得好像叫 Token 或者是 Cookie更加的合适（原书并列的说，笔者认为后两个说辞我显然更加能接受和理解），它主要是尝试解决一种性能问题——我们可不可以复用一些已经有的东西呢（注意我们没有在复用抽象，而是在复用数据，更加像是期待用引用取代值）

一个例子：文本显示

​ 假设我们现在正在打开一本超级无敌大的书，大约几千万个字吧！但是我们知道，常用的汉字本身可能也就不到 4000 个。比如说，在整本书中，大量出现了“我”、“你”、“吧”等高频词汇。那问题来了：我们真的有必要在内存里反复存储一大堆一模一样的字形数据吗？显然没有必要。

​ 我们完全可以不存储字本身的完整信息，而是存储指向这个字的索引。换句话说，就是把“字”放到一个共享的字典池里，文本本身只记录“引用”。这样，当需要显示时，再根据索引去取对应的字形。这种方式就避免了冗余存储，从而极大节省了内存空间。

那为什么 ASCII 文本中我们没有这么做呢？原因在于代价问题。ASCII 编码本身只占一个字节，而指针或索引往往需要 2~4 个字节（甚至更多），这样一来就得不偿失了。换句话说，ASCII 字符已经足够小，继续压缩反而增加了额外负担。

​ 不过，事情并没有到此为止。让我们继续思考：如果不仅仅是单个字频繁出现，还有一些字的组合或搭配也非常常见，比如“你好”、“谢谢”、“没事吧”。在整本书的文本里，这些词组也会反复出现。那我们是不是也可以用同样的方法，把它们放到共享池里，然后文本只存储索引？

​ 这样一来，我们就不仅减少了对单字的重复存储，还进一步减少了对常见词组的重复存储。随着共享池的规模合理扩展，我们就能用有限的资源，存储和渲染出极其庞大的文本。这种思想，其实就是**享元模式（Flyweight Pattern）**在文本显示场景下的一个具体应用。

#include <iostream>
#include <unordered_map>
#include <memory>
#include <string>
#include <vector>// 享元对象：表示一个“字”或“词组”
class Glyph {
public:explicit Glyph(const std::string& content) : content_(content) {}void draw() const {std::cout << content_;}
private:std::string content_;
};// 享元工厂：管理所有的共享对象
class GlyphFactory {
public:std::shared_ptr<Glyph> getGlyph(const std::string& content) {auto it = pool_.find(content);if (it != pool_.end()) {return it->second; // 已存在，直接复用}auto glyph = std::make_shared<Glyph>(content);pool_[content] = glyph;return glyph;}
private:std::unordered_map<std::string, std::shared_ptr<Glyph>> pool_;
};// 客户端：文本渲染
class Document {
public:void addWord(const std::shared_ptr<Glyph>& glyph) {text_.push_back(glyph);}void render() const {for (auto& g : text_) {g->draw();}std::cout << std::endl;}
private:std::vector<std::shared_ptr<Glyph>> text_;
};int main() {GlyphFactory factory;Document doc;// 假设整本书有很多 "你", "好", "吧"auto g1 = factory.getGlyph("你");auto g2 = factory.getGlyph("好");auto g3 = factory.getGlyph("吧");// 多次重复使用，不会创建新的对象doc.addWord(g1);doc.addWord(g2);doc.addWord(g3);doc.addWord(g1);doc.addWord(g2);doc.render(); // 输出：你好吧你好
}

棋盘游戏

#include <iostream>
#include <unordered_map>
#include <memory>// 享元对象：棋子
class ChessPiece {
public:ChessPiece(const std::string& color, const std::string& type): color_(color), type_(type) {}void draw(int x, int y) const {std::cout << color_ << type_ << " 放在 (" << x << "," << y << ")\n";}
private:std::string color_; // 内部状态：颜色std::string type_;  // 内部状态：棋子类型
};// 工厂：保证相同的棋子只创建一次
class ChessFactory {
public:std::shared_ptr<ChessPiece> getChess(const std::string& color, const std::string& type) {std::string key = color + type;if (pool_.count(key)) return pool_[key];auto piece = std::make_shared<ChessPiece>(color, type);pool_[key] = piece;return piece;}
private:std::unordered_map<std::string, std::shared_ptr<ChessPiece>> pool_;
};int main() {ChessFactory factory;auto blackPawn = factory.getChess("黑", "卒");auto redPawn   = factory.getChess("红", "兵");// 外部状态：位置blackPawn->draw(2, 3);redPawn->draw(5, 6);blackPawn->draw(2, 4);
}

​ 我们可以得到输出

黑卒 放在 (2,3)
红兵 放在 (5,6)
黑卒 放在 (2,4)

即使棋盘上有 16 个卒，它们在内存中只会存在两个共享对象（黑卒、红兵）。

---

数据库连接池

#include <iostream>
#include <unordered_map>
#include <memory>// 享元对象：连接配置
class DBConfig {
public:DBConfig(const std::string& host, int port) : host_(host), port_(port) {}void show() const {std::cout << "DBConfig: " << host_ << ":" << port_ << "\n";}
private:std::string host_;int port_;
};// 工厂：共享相同配置
class DBConfigFactory {
public:std::shared_ptr<DBConfig> getConfig(const std::string& host, int port) {std::string key = host + ":" + std::to_string(port);if (pool_.count(key)) return pool_[key];auto cfg = std::make_shared<DBConfig>(host, port);pool_[key] = cfg;return cfg;}
private:std::unordered_map<std::string, std::shared_ptr<DBConfig>> pool_;
};int main() {DBConfigFactory factory;auto c1 = factory.getConfig("127.0.0.1", 3306);auto c2 = factory.getConfig("127.0.0.1", 3306);auto c3 = factory.getConfig("192.168.1.10", 5432);c1->show();c2->show();c3->show();
}

咋用啊？

• 打印店字体库：一台电脑装了一份宋体字库，所有人都用这份库。没有必要为每份文档都单独保存字形。
• 地铁 IC 卡：内部状态是固定的芯片结构，外部状态是余额、有效期等随用户变化的数据。
• 视频游戏贴图：相同的树木、草丛、石头模型在地图里出现成百上千次，但只加载一份纹理资源，实例化时传入不同的位置和缩放参数。

---

总结

我们要解决什么问题？

当系统中存在大量相似对象时，内存占用可能急剧膨胀，性能下降。
但这些对象其实往往存在可复用的内部状态（如字形、纹理、连接配置），如果能共享这部分，就能显著节省资源。

享元模式要解决的核心问题就是：如何在保证功能的前提下，尽量减少内存中的冗余对象。

---

我们如何解决？

享元模式通过将对象的状态拆分为两类：

1. 内部状态（Intrinsic State）
   • 对象本身不会随环境变化的、不变的、可被共享的部分。
   • 例如：汉字的字形、棋子的颜色与类型、数据库连接参数。
2. 外部状态（Extrinsic State）
   • 与上下文相关的、每次使用时才决定的部分。
   • 例如：汉字在文档中的位置、棋子在棋盘上的坐标、连接池中的使用次数。

通过共享内部状态对象 + 外部状态由调用方提供，就能极大减少对象数量。

享元模式优缺点

优点	缺点
显著减少内存占用	系统复杂度增加，需要区分内外部状态
提升对象复用率	不适合对象完全不同、共享价值不大的场景
便于维护共享资源池	外部状态需要额外传递，增加调用方负担