问题标签 [flyweight-pattern]

据我了解，享元设计模式与工厂或单例设计模式没有太大区别。

它只是一个生产不可变（和池化）对象的工厂。它只是为每种类型（托管对象）提供一个实例的单例，而不是全局单个实例。

工厂模式和单例模式是创建模式，那么为什么要考虑享元模式呢？

我正在学习 Python，我认为这将是一个很好的借口来更新我的模式知识，在这种情况下，就是 Flyweight 模式。

我创建了两个小程序，一个没有优化，一个是实现享元模式。出于测试目的，我正在创建一个由 1'000'000 个Enemy对象组成的军队。每个敌人可以是三种类型（士兵、忍者或酋长），我为每种类型分配了座右铭。

我想检查的是，使用我未优化的程序，我得到了 1'000'000 个敌人，每个人都有一个类型和一个包含座右铭的“长”字符串。使用优化的代码，我只想创建三个对象 ( EnemyType) 匹配每种类型并且只包含 3 倍的座右铭字符串。然后，我为每个添加一个成员Enemy，指向所需的EnemyType.

现在代码（仅摘录）：

1. 未优化的程序

   在这个版本中，每个敌人都会存储其类型和座右铭。

   /li>

2. 优化程序

   在这个版本中，每个敌人都有一个EnemyType存储其类型和座右铭的对象的成员。只创建了三个实例，EnemyType我应该会看到内存占用的影响。

   /li>

现在我正在使用它来获取我的内存占用量（在我的应用程序自行关闭之前的最后一行）：

我的问题是，我看不出我的两个程序的输出有什么区别：

优化 = 384.0859375 Mb
未优化 = 383.40234375 Mb

它是获取内存占用的正确工具吗？我是 Python 新手，所以我的代码可能有问题，但我在第二个解决方案中检查了我的 EnemyType 对象，我确实只有三个出现。因此，我应该有 3 个座右铭字符串而不是 1'000'000。

我读过一个名为Heapy for Python 的工具，这里会更准确吗？

考虑这段代码：

所以我想将Person构造函数更改为

这将查找 staticReligion*的“表”。毕竟，属于完全相同教派的两个人应该共享相同的Religion*值。所以这是我试图在这里实现的轻量级设计模式。问题是我们不知道Is...包装有多长（子子-...-面额的数量在任何地方都不是固定的），所以我不认为一个简单的多维数组行不通。因此，我正在做的是Religion*在适当的类中放置一些 s 的静态 const 向量，并且该Is...包将用于查找要查找的最终向量。

更新：有更好的方法吗？如果您在下面看到，到目前为止我发现的解决方案有一个主要缺点。

我开始学习设计模式。我知道原型是用来制作我已经拥有的对象的精确副本，而享元是用来制作类似的对象。

我已经编写了 2D 平台游戏，例如马里奥（Java）。有很多相同的敌人，唯一的区别是他们的位置[x,y]。还有由大量矩形建造的墙壁，唯一的区别是它们的位置[x,y]。

在这种特殊情况下使用其中一些设计模式是否明智？我应该使用原型通过可克隆然后设置来克隆对象[x,y]吗？

使用享元是否更好 - 当我需要新对象时，我只需从我的哈希图中返回它们，然后设置 [x,y]？

在这两种情况下，我都避免使用 new 运算符，但我不确定使用哪一个。

我在没有 Spring 的 java 编程中有一个 Flyweight 模式实现。请建议我如何将其作为 Spring 托管 Bean。它有静态方法调用和内部类。目的是最初从 CRM 加载所有选项集以在应用程序中共享相同的选项集。这可以防止昂贵的 CRM 调用。用户被限制创建任何新的选项集，因此是内部类。首先需要实现为 Spring bean，然后使其成为 ApplicationContextAware 以引用其他 bean。我主要使用 Spring XML 配置进行 bean 定义。

我需要找出 Prototype DP 和 Flyweight DP 之间的一些区别我知道基本区别在于前者进行深度复制。而这封信使共享对象。我的讲师说还有更多的差异。

有人认识其他人吗？

我有一个看起来像这样的不可变类：

该方法通过混合两个现有对象的内部来bar返回一个对象。因为已经在一个对象中，所以保证它是有效的并且不需要复制或验证（构造函数当前所做的）。FooFooMutableObjectFoo

因为验证（可能还有克隆？）是昂贵的，如果可能的话，我想避免它们。最好的方法是什么？这就是我想出的：

我认为，至少，它比使用虚拟参数更清晰/更清晰，并且比交换订单更不容易出错，但是有没有更好的方法来做到这一点？这通常如何实现？

当需要打包大量特定类型的对象时，我们使用享元。因为它们共享一个公共数据（内在状态），所以有助于减少内存消耗，并且还拥有自己的状态（外在状态），所有其他对象都不共享。这是一个示例代码

和司机

在这个例子中，我希望大小是内在的，坐标（x，y）是外在的，但是当我改变它的坐标时，first_circle它也反映了变化，second_circle因为它们共享一个完整的对象而不仅仅是一个状态。输出如下

它相当于创建一个对象并将其存储在不同的对象中，但是它们都具有相同的状态或数据，那么它们如何拥有自己的数据（外部状态）？

要应用享元模式，我们需要将对象属性分为内在属性和外在属性。内在属性使对象独一无二，而外在属性由客户端代码设置并用于执行不同的操作。

但我的问题是，为什么我们不能同时拥有内在和外在属性作为实例变量（参见下面的电子邮件类），只在循环外创建一个对象并在循环中设置参数并发送多封具有不同参数的电子邮件。

I have an odd situation.

I have a simple flyweight factory that allows me to reuse instances that are equal() in a graph of objects.

When I serialize the root object, with and without use flyweight, to measure its benefit, I go from 2,014,169 bytes with a new object for each reference, down to 1,680,865. Okay, that is fine.

BUT, when I look at this object's retained size in a heap dump in jvisualvm, I always see 6,807,832.

How can it be? Surely if in one case I have multiple instances of the same object, they each take up memory. Retained size should be the amount that would be recovered from GC. I would think that would be more without using the flyweight factory to recycle instances. If I wasn't seeing the benefit in serialization, I'd think it was a bug in the flyweight factory, but I can't see how it'd only work for serialization.

Right now I'm a bit perplexed.

Using the flyweight factory, you pass new instances through a check to see if a reference can be reused instead:

If not using the flyweight, store the new object every time:

And for reference, here is the flyweight factory class: