享元模式——如何在数据结构中存储享元？
GoF 书中的经典 Flyweight 模式实现示例仅将字符代码存储在可共享的“Characters”中，并使用“GlyphContext”在树结构中存储外部状态。这个例子还提到了行和列，但是它没有提到如何存储享元（“字符”对象）的“集合”。
很明显，这种模式可以避免通过共享实例来创建大量对象，但是如何在不创建对缓存对象的引用结构（这会使缓存对象无效）的情况下创建此类对象的结构（例如，表示文档）？模式的目的）？我看到其他示例使用缓存实例作为“丢弃”对象，而不构建任何类型的结构，但这似乎没有任何意义，因为它可以被一组静态操作替换。
如果需要在创建享元后引用它们，则该模式的好处可以粗略地计算为[内在状态的大小]/[对象引用的大小]，这样的结论是否正确？这意味着只有 1 个字段的蝇量级没有意义？
编辑：我的“内存计算”是错误的......如果没有享元，你无论如何都需要存储引用，但是有了享元，你就不再需要存储对象了。这个问题的基本点似乎仍然有效 - 模式提供的节省程度与内在状态的大小成正比，而不是“逻辑对象”的数量。是真是假？
Classic Flyweight pattern implementation example from GoF book only stores character code in sharable "Characters" and uses "GlyphContext" to store extrinsic state in a tree structure. This example also mentions Rows and Columns, however it doesn't mention how would one store a "collection" of flyweights ("Character" objects).
It's clear that this pattern allows to avoid creating huge number of objects by sharing instances, but how can one create a structure of such objects (for example, to represent a document) without creating a structure of references to cached objects (which would invalidate the purpose of the pattern)? I see that other examples use cached instances as "throw-away" objects, without building any sort of structure, but this doesn't seem to make any sense, since it could be replaced by a set of static operations.
Is it correct to conclude that if one needs to refer to flyweights after they are created, the benefit of the pattern can roughly be calculated as [size of intrinsic state]/[size of object reference]. This means that flyweight with only 1 field doesn't make sense?
EDIT: I was wrong in my "memory calculations"... Without flyweights, you need to store references anyway, but with flyweights, you don't need to store objects anymore. The basic point of the question still seems to be valid - the extent of savings, provided by the pattern is proportional to the size of intrinsic state, not the number of "logical objects". True or false?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，如果您经常使用该对象，即使是一个字段享元对象也有意义。获取它们的实例然后创建新对象会更快。
我发现
Map（在 Java 中）是存储它们的好方法。为什么需要“无结构”？使用某种结构来存储正在使用的 Flywiegt 不会使模式的目的失效。您需要一些 Flywiights 实例才能使用它们。您可以在运行时创建它们并将它们添加到它们的列表中（这就是应该完成的方式，以避免不需要的对象），或者您可以在运行时之前准备它们（女巫使“低”有意义）。
Yes, even one field flyweight object makes sense if you will use that object a lot. Its faster to get their instances, then making new objects.
I find
Map <string name, Object yourobject>(in Java) a good way to store them. Why you need "no structure"?Using some structure to store flywieght being in use doesn't invalidate the purpose of the pattern. You need some instances of flywieghts to use them. You can make them during runtime and add them to list of them (that's the way it should be done, to avoid unneeded objects), or you can prepare them before runtime (witch makes "low" sense).