工厂模式：可以＆＃34;定义＆＃34;太大了？

Question

＆＃34;定义对象＆＃34;是否有缺点？进入＆＃34;工厂＆＃34;变得（太）大/复杂？

实施例

在游戏引擎中，我有一个非常大的原型类3D图形对象，至少对我而言。

它包含： -

• 3D网格的指针（句柄）
• 8个纹理的指针（句柄）（例如朗伯，镜面）
• 8种纹理的颜色（例如颜色倍增器） - 每种颜色浮动
• 8个纹理的自定义设置 - 每个4个浮点数
• ~10用于混合，深度测试，深度写入等的布尔标志
• （随着项目的进行逐步添加）

在游戏逻辑中，我缓存了一些（100？）原型散射的实例。它们中的大多数都作为字段存储在许多子系统中 我发现按值存储原型也非常方便。

问题

1. 除了显而易见的直接内存/ CPU成本外，是否有任何容易被忽视的＆＃34;当原型非常大时会发生的劣势？
2. 确定原型（传入工厂的定义）太大/复杂的标准是什么？什么是可以治愈它的补救措施/设计模式？
3. 原型应该通过句柄/指针存储在业务/游戏逻辑中吗？ （我有这个想法，因为人们倾向于使用指针作为大对象，但这是一个非常弱的原因。）

Answer 1

数目：

1. 除了显而易见的直接内存/ CPU成本外，原型非常大时会出现“容易被忽视”的缺点吗？

   对于一个图形对象，如果将其与副本一起放在不同的位置，则在更改对象时，必须更改锁定下的所有副本，否则会遇到不一致问题，这会增加代码复杂性和潜在的不一致问题。

2. 确定原型（进入工厂的定义）太大/太复杂的标准是什么？什么是可以治愈它的补救措施/设计模式？

   工厂模式用于创建对象。如果您发现工厂中的逻辑或代码太复杂，问题应该是您的对象结构而不是工厂模式。

3. 原型是否应该通过句柄/指针存储在业务/游戏逻辑中？ （我有这个想法，因为人们倾向于使用指针来表示大对象，但这是一个非常弱的原因。）

   对于您的情况，我建议使用P-Impl模式或智能指针模式来存储相同的对象，这可以大大减少复杂数据和对象数。