我现在正在做的一件事与游戏有一些相似之处。出于说明的目的,我将使用一个虚构的假设游戏中的示例来解释我的问题。
让我们称之为DeathBlaster 4: The Deathening 吧。在 DB4 中,您有许多在移动时Ship
会定期随机遇到的对象Phenomena
。一个给定的在遇到它的时候Phenomenon
可能有零个、一个或多个。例如,我们可能有四种和三种。Effects
Ship
Ships
Phenomena
现象 =========================================== 船舶重力井黑洞星云场 ------------ -------------------------------------- ---- 红船 +20% 速度 -50% 力量 -50% 护盾 BlueShip 无效果 无敌死亡 各种效果 绿船 -20% 速度死亡 +50% 护盾 船上现象 YellowShip 死亡 +50% 功率无效果
此外,Effects
还可以相互交互。例如,GreenShip
同时在 aGravityWell
和 a中的 a 可能会在生成的和NebulaField
之间产生某种协同作用。在这种情况下,协同效应本身就是一种——例如,这种相互作用可能会产生一种。除了作用于 a的集合之外,不需要任何信息来解决最终结果应该是什么。SpeedEffect
ShieldEffect
Effect
PowerLevelSynergyEffect
Effects
Ship
您可能会开始看到这里出现的问题。作为一种天真的第一方法,要么每个Ship
人都必须知道如何处理每个人Phenomenon
,要么每个Phenomenon
人都必须知道每个人Ship
。这显然是不可接受的,因此我们想将这些责任转移到其他地方。显然这里至少有一个外部类,可能是一个Mediator
或Visitor
某种。
但是最好的方法是什么?理想的解决方案可能具有以下属性:
Ship
添加一个新的就像添加一个新的一样容易Phenomenon
。- 不产生影响的交互是默认的,不需要额外的代码来表示。约定优于配置。
- 了解
Effects
彼此之间的交互方式,并能够管理这些交互以决定最终结果。
我想我已经决定了我的方法,但我很想听听最佳设计共识是什么。你会从哪里开始?你会探索哪些途径?
后续更新:谢谢大家的回复。这就是我最终要做的事情。我的主要观察是,相对于可能的×交互的数量,不同的数量Effects
似乎很小。即,虽然有许多可能的交互组合,但这些交互的结果种类数量较少。Phenomena
Ships
可以看到,比如表格中虽然有12种交互组合,但效果只有五种:速度修改、力量修改、护盾修改、无敌、死亡。
我引入了第三个类 ,InteractionResolver
来确定交互的结果。它包含一个映射Ship-Phenomenon
对的字典Effects
(基本上是一个执行效果的委托和一些元数据)。当计算交互的结果完成时,每一个都会Ship
被传递EffectStack
给它正在经历的对应。Effects
Ships
然后使用EffectStack
来确定它们的实际结果,方法是Effects
向它们现有的属性和属性添加修饰符。
我喜欢这个,因为:
Ship
s 永远不需要知道Phenomena
。Ship
-关系的复杂性Phenomena
被抽象为InteractionResolver
.- 如何解决多种可能复杂的效果的细节由
InteractionResolver
. 船只只需在必要时应用效果。 - 这可以进行其他有用的重构。例如,船舶处理效果的方式可以通过制作
EffectProcessorStrategy
. 默认可能是处理所有效果,但是,比如说,aBossShip
可能会通过使用不同的EffectProcessorStrategy
.