c#如何实现享元模式_c#享元模式完整教程与代码实例

先说几个核心判断：享元模式在C#中并非"必须用"，而是当你发现内存里堆着大量重复、细粒度对象（比如上万个小图标、字符样式、棋子实例），且它们的状态可拆分为「内在状态」和「外在状态」时，才值得引入——否则就是过度设计。如果对象需要Dispose、含事件订阅或依赖this引用，那基本可以放弃享元化的念头。

什么时候该用 IFlyweight 而不是直接 new 对象

典型信号是：你发现自己在循环创建大量相似对象，每个只差一两个字段（如坐标、颜色、ID），而这些差异能被外部传入；同时对象本身不保存上下文，也不持有对其他业务实体的引用。换句话说，对象的状态可以分成两拨——一拨是铁打不动的内在状态，一拨是随叫随到的外在状态。

• 常见场景：System.Drawing.Font 的复用（字体名+大小+样式固定，但绘制位置每次不同）、文本编辑器中成千上万个 Character 实例（字符本身不变，位置/高亮状态由行渲染器控制）
• 反模式信号：对象有生命周期管理（如需Dispose）、内部含事件订阅、依赖 this 引用调用其他服务——这类不适合享元化
• 性能影响：享元工厂首次访问有哈希查找开销，但后续复用能省下不少GC压力；如果对象总数本来就少，那就不值得折腾了

FlyweightFactory.GetFlyweight(string key) 的 key 设计要点

key不是随便拼的字符串，它必须唯一、稳定、无歧义地标识一组内在状态。别用 ToString() 或 JSON 序列化结果作 key——太重且易出错，那相当于给享元模式开了个性能倒车。

• 推荐方式：用 ValueTuple（C# 7.0+）或自定义 struct 作为 key，例如 (string fontName, float size, FontStyle style)
• 避免方式：用 new { Name = "Arial", Size = 12 } —— 匿名类型每次 new 都是新类型，Dictionary 根本查不到
• 注意线程安全：如果工厂被多线程调用，ConcurrentDictionary 比手动加锁更稳妥，省心不少

外在状态怎么传给 IFlyweight.Operation(externalState)

享元接口的 Operation 方法必须接收所有变化的数据，不能靠闭包捕获、也不能存字段——那是破坏享元本质，把共享搞成了寄生。

• 正确做法：把坐标、渲染上下文、用户 ID 等每次不同的数据，作为参数传入，例如 flyweight.Render(graphics, x, y, isHighlighted)
• 错误做法：在享元类里设 public int X { get; set; }，然后外部反复赋值——这会让对象失去共享安全性，多线程下直接崩给你看
• 边界提醒：如果参数超过4–5个，说明外在状态可能没合理分层，考虑封装成 RenderContext 类，但别让它带业务逻辑，否则就背离了分离的初衷

为什么 ConcreteFlyweight 必须是不可变的

因为多个地方共用同一个实例，一旦某个调用方改了它的字段，其他调用方立刻看到脏数据——这不是bug，是设计失效。可以这么说，享元模式的核心约束之一就是：共享的对象必须不可变，否则共享就成了灾难。

• 强制手段：所有字段声明为 readonly，构造函数一次性注入内在状态，不提供 public setter
• 例外情况：极少数场景需延迟初始化（如图片资源首次访问才加载），可用 Lazy，但初始化逻辑仍要线程安全
• 调试提示：若发现享元行为异常，优先检查是否无意中修改了字段，或用了可变集合（如 List）作为内在状态的一部分

真正难的不是写对工厂和接口，而是判断哪些状态属于"内在"、哪些必须剥离出去——这需要你画出对象图，标出哪些字段在所有实例中完全一致，哪些随上下文跳变。画不出来，就先别上享元。毕竟，设计模式是来解决问题的，不是为了制造问题。