不久前,我在重构一些游戏战斗代码时决定尝试装饰器模式。战斗者可以拥有各种被动能力,也可能是不同类型的生物。我认为装饰器可以让我在运行时以各种组合添加行为,因此我不需要数百个子类。
我几乎已经完成了 15 个左右的被动能力装饰器,在测试中我发现了一些东西 - 装饰器模式的一个相当明显的缺点,我很惊讶我以前没有听说过。
为了让装饰器正常工作,必须在最外面的装饰器上调用它们的方法。如果“基类”(包装的对象)调用它自己的方法之一,则该方法将不会是修饰的重载,因为无法将调用“虚拟化”到包装器。人工子类的整个概念崩溃了。
这是一件大事。我的战斗人员有类似的方法TakeHit
进而调用自己的Damage
方法。但装修的Damage
根本没有被叫到。
也许我选择了错误的模式或者在它的应用中过于热心。对于这种情况下更合适的模式,或者解决此缺陷的方法,您有什么建议吗?我重构的代码只是将所有被动能力散布在里面的战斗代码中if
块看似随机的地方,所以这就是我想把它打破的原因。
编辑:一些代码
public function TakeHit($attacker, $quality, $damage)
{
$damage -= $this->DamageReduction($damage);
$damage = round($damage);
if ($damage < 1) $damage = 1;
$this->Damage($damage);
if ($damage > 0)
{
$this->wasHit = true;
}
return $damage;
}
这个方法是在基础中Combatant
class. DamageReduction
and Damage
可以并且在各种装饰器中都被覆盖,例如将伤害减少四分之一的被动,或者将一些伤害反射回攻击者的被动。
class Logic_Combatant_Metal extends Logic_Combatant_Decorator
{
public function TakeHit($attacker, $quality, $damage)
{
$actual = parent::TakeHit($attacker, $quality, $damage);
$reflect = $this->MetalReflect($actual);
if ($reflect > 0)
{
Data_Combat_Event::Create(Data_Combat_Event::METAL_REFLECT, $target->ID(), $attacker->ID(), $reflect);
$attacker->Damage($reflect);
}
return $actual;
}
private function MetalReflect($damage)
{
$reflect = $damage * ((($this->Attunement() / 100) * (METAL_REFLECT_MAX - METAL_REFLECT_MIN)) + METAL_REFLECT_MIN);
$reflect = ceil($reflect);
return $reflect;
}
}
但同样,这些装饰器方法永远不会被调用,因为它们不是从外部调用的,而是在基类内部调用的。