design-patterns - 享元模式 - 非共享具体实例的意义何在？

Question

众所周知，享元模式的UML图中有一个非共享的具体实例，它实现了享元接口。我的问题是，如果它的外部状态毫无意义，它为什么要实现它？我的意思是，对于共享的具体实例，接口是必需的，所以你必须确保可以传递外部状态，但是非共享的呢？难道我们不能轻易不实现接口并达到相同的结果吗？

Answer 1

扩展享元接口提供了将客户端与享元模式实现分离的机会。

例子：

为“字形”-s 实现了享元模式。根据该模式的 UML，“Glyph”代表“享元”基类或接口。“客户”使用一组字形。FlyweightFactory（此处为 GlyphFactory）可以使用享元模式创建字形（通常为 SharedFlyWeightGlyph 对象实例）。

客户端可能将文本存储为一组字形。

现在让我们说，在普通字形旁边，您想使用一些无法由 FlyWeightFactory 创建的自定义字形。通过扩展“Glyph”接口（根据该模式的 UML 图，它是 UnsharedFlyweight），您有机会使用自定义字形，但是在这些情况下，无法利用享元模式的性能优势。

Answer 2

非共享的具体实例没有内在的数据可以共享，但它可以消耗外在的“数据”来产生它的操作输出，因此它实现了相同的接口。

这种模式的主要目的是节省存储空间，有效地使用大量对象。

内在状态是不变的（与上下文无关），因此可以共享。外部状态是可变的（依赖于上下文），因此不能共享，必须传入。

卡片上的例子。我们必须跟踪大量的手牌和他们的分数；上下文是手，共享实例是标准牌，非共享对象是小丑。标准卡的方法 points() 的输出取决于其内在数据（套件和等级）和手牌。小丑的 points() 取决于手和特定的选择，它不是内在的，也不是外在的。