是否存在相互排斥的装饰设计模式？
是否存在相互排斥的装饰设计模式？
提问于 2016-02-25 16:28:11
我们知道装潢工设计模式，但是有人会如何实现相互排斥的装饰者呢？
假设我有一个在游戏中实现武器修饰符的装饰模式。例如，装饰师会是“有毒的”，“被火迷住的”，“被冰迷住的”等等。现在假设我不想让我的武器同时被火和冰迷住(仅仅因为)，我该如何在我的装饰者模式中实现这个逻辑呢？
我需要打破它，还是让它变得难以辨认？
我现在最好的想法是在我的接口上有一个GetDecorations()方法，并在新的装饰类中使用它，以确保新的装饰不会违反任何限制。但这似乎违反了装饰原则“不知道”你可以被装饰.
回答 1
Software Engineering用户
回答已采纳
发布于 2016-02-25 16:45:35
装饰师通常会“包装”类并在某些地方添加行为。
如果您的例子，也许有一种方法，执行一个计算，以获得损害的武器造成。这将超过一个数字，也返回一个类型，也许是多重的: 10物理伤害，2冷伤害。
我会有一个武器的接口，它是由实际武器和你的装饰人员实现的。然后，我将为实际的武器和装饰器提供两个子接口:一个装饰器不能装饰另一个装饰器，因为它的构造函数不会接受这种类型。伪码：
class Damage {
// state is multiple pairs of damage amounts and damage types.
}
interface Weapon {
Damage getDamage();
}
interface RealWeapon : Weapon {}
interface WeaponDecorator : Weapon {}
class ColdEnchantment : WeaponDecorator {
ColdEnchantment(RealWeapon w) { ... }
}您可以依靠语言中的静态类型系统来防止编译时出现多个装饰器。
另一种方法是使魔法成为武器上的一个领域：
interface Enchantment {
// these are currently your decorators
}
interface Weapon [
Damage getDamage();
void setEnchantment(Enchantment e);
void removeEnchantment();
}这两种方法都适用于不同的设计:我建议在程序的全局图中考虑它们，并决定哪一种方法更干净。
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://softwareengineering.stackexchange.com/questions/311094
复制相关文章
相似问题
腾讯云开发者
