GoF 书中的经典享元模式实现示例仅将字符代码存储在可共享的“字符”中，并使用“GlyphContext”将外部状态存储在树结构中。这个例子还提到了行和列，但是它没有提到如何存储享元（“字符”对象）的“集合”。
很明显，这种模式允许通过共享实例来避免创建大量对象，但是如何创建此类对象的结构（例如，表示文档）而不创建对缓存对象的引用结构（这会使模式的目的）？我看到其他示例使用缓存实例作为“丢弃”对象，而不构建任何类型的结构，但这似乎没有任何意义，因为它可以被一组静态操作替换。
是否可以得出这样的结论：如果在创建享元后需要引用它们，那么该模式的好处可以粗略地计算为[固有状态的大小]/[对象引用的大小]。这意味着只有 1 个字段的享元没有意义？
编辑：我的“内存计算”是错误的......没有flyweights，你无论如何都需要存储引用，但是使用flyweights，你不需要再存储对象了。问题的基本点似乎仍然有效 - 模式提供的节省程度与内在状态的大小成正比，而不是“逻辑对象”的数量。对或错？