享元模式通过共享内部状态减少对象创建开销，适用于大量相似对象场景。在Golang中，将字体等不变属性作为内部状态由TextRenderer持有，位置和内容等可变数据作为外部状态传入Render方法。RendererFactory使用map缓存实例，按字体配置复用渲染器，避免重复创建。10000个字符渲染时，相同样式的对象共享同一实例，显著降低内存占用。该模式适合编辑器、游戏文本系统等高频对象创建场景，需注意内部状态不可变、外部状态传递复杂度及并发安全问题。Golang虽无继承，但通过接口与组合可简洁实现享元模式，关键在于分离变与不变部分并由工厂统一管理实例生命周期。
在 Golang 中使用享元模式可以有效减少对象创建的开销，尤其适用于大量相似对象存在的场景。核心思路是共享可变与不可变部分，将不变的状态提取为“内部状态”，由多个对象共享；而变化的部分作为“外部状态”传入，避免每个对象都持有独立副本。
享元模式的基本结构
享元模式包含三个关键角色：
- 享元接口（Flyweight）：定义操作方法，接收外部状态作为参数
- 具体享元（ConcreteFlyweight）：实现接口，存储内部状态并处理外部状态
- 享元工厂（FlyweightFactory）：管理享元实例的创建和复用，通常使用 map 缓存已创建的对象
实际代码示例
假设我们要渲染大量文本字符，每个字符有字体、颜色等属性。这些属性中，字体和大小是重复的，可以共享；而位置和内容是变化的，应作为外部状态传入。
package main
type Character struct {
FontSize int
FontName string
Color string
}
type TextRenderer struct {
char Character
}
func (tr *TextRenderer) Render(x, y int, content rune) {
// 外部状态 x, y, content 通过参数传入
println("Render", string(content), "at (", x, ",", y, ") with font:", tr.char.FontName)
}
工厂负责管理共享的 TextRenderer 实例：
立即学习“go语言免费学习笔记（深入）”；
type RendererFactory struct {
renderers map[string]*TextRenderer
}
func NewRendererFactory() *RendererFactory {
return &RendererFactory{renderers: make(map[string]*TextRenderer)}
}
func (f *RendererFactory) GetRenderer(fontSize int, fontName, color string) *TextRenderer {
key := fontName + "-" + color + "-" + fmt.Sprint(fontSize)
if renderer, exists := f.renderers[key]; exists {
return renderer
}
renderer := &TextRenderer{
char: Character{
FontSize: fontSize,
FontName: fontName,
Color: color,
},
}
f.renderers[key] = renderer
return renderer
}
如何节省内存开销
当需要渲染 10000 个字符时，如果每个都独立创建 TextRenderer，会占用大量内存。使用享元后，只要字体样式相同，就复用同一个实例。
- 内部状态（如字体）被集中存储，只保存一份
- 外部状态（坐标、字符）不存储在对象内，而是调用时传入
- 通过工厂缓存，避免重复创建相同配置的渲染器
这种设计显著降低了内存占用，特别适合编辑器、游戏文本系统等高频创建对象的场景。
适用场景与注意事项
享元模式并非万能，需根据实际情况判断是否使用：
- 对象数量极大且存在大量重复状态时效果明显
- 内部状态应尽量不可变，避免共享导致副作用
- 外部状态传递可能增加方法参数复杂度，需权衡清晰性与性能
- 注意并发安全，若共享对象被修改，需加锁或设为只读
基本上就这些。Golang 没有继承机制，但通过组合和接口轻松实现享元模式，关键是把可变与不可变分离，再配合工厂统一管理实例生命周期。不复杂但容易忽略。
