众所周知，在Flyweight模式的UML图中有一个非共享的具体实例，它实现了接口flyweight。我的问题是，如果它的外在状态毫无意义，为什么要实施呢？我的意思是，对于共享的具体实例，需要接口，因此您必须确保可以传递外部状态，但是未共享的是什么？我们不能轻易地不实现界面并获得相同的结果吗？
答案 0 :(得分：0)
扩展Flyweight接口提供了将客户端与flyweight模式实现分离的机会。
示例：
为'Glyph'-s实施了一个Flyweight模式。 根据模式的UML，'Glyph'代表'Flyweight'基类或接口。 '客户端'使用一组字形。 FlyweightFactory（此处为GlyphFactory）可以使用flyweight模式创建字形（通常为SharedFlyWeightGlyph对象实例）。
客户端可能会将文本存储为一组字形。
现在让我们说，在普通字形旁边，你想要使用一些FlyWeightFactory无法创建的自定义字形。通过扩展'Glyph'接口（根据模式的UML图表是UnsharedFlyweight），您有机会使用自定义字形，但在这些情况下，无法利用flyweight模式的性能优势。
答案 1 :(得分：0)
未共享的具体实例没有内部数据要共享，但它可以使用外部“数据”来生成其操作输出，因此它实现了相同的接口。
此模式的主要目的是节省存储空间，有效地使用大量对象。
内在状态是不变的（与上下文无关），因此可以共享。外在状态是变体（依赖于上下文），因此不能共享，必须传入。
卡片上的例子。我们必须跟踪大量的手和他们的分数;上下文是手，共享实例是标准卡，而非共享对象是笑话者。标准卡的方法points（）的输出取决于其内在数据（套件和等级）和手头。小丑的积分（）取决于手和特定的选择，它不是内在的，也不是外在的。