我正在读这个wiki article关于组合继承,在示例中他们使用了一个抽象类。假设您想完全避免他们使用抽象类,而只使用具体类。我想知道,我的示例是否正确使用了构图。假设我有以下 IGameobject 接口(interface)。
public interface IGameObject
{
string Name {get;}
}
和下面的武器界面:
//Note the IGameObject getter
public interface IWeapon
{
int Damage {get; }
IGameObject gameObject {get;}
}
通常,在我的游戏中,武器是一个 IGameObject。然而,考虑到我们使用的是组合,根据维基文章,它是一种有一个关系。
现在,我可以在创建 Sword 对象时执行此操作:
public class Sword : IWeapon
{
private IWeapon weaponObject;
public Sword(IWeapon weapon)
{
this.weaponObject = weapon;
}
public int Damage
{
get
{
return this.weaponObject.Damage;
}
}
public IGameObject gameObject
{
get
{
return this.weaponObject.gameObject;
}
}
我现在可以将我的剑存储在一个集合中,例如,一个列表:
List<IWeapon> weapons = new List<IWeapon>();
weapons.add(swordObj)
并且仍然可以访问我的 IGameObject。
现在,我有 3 个问题:
- 我是否正确实现了合成?
- 我的 Sword 类是否也应该实现
IGameObject
接口(interface)? - 我的 IWeapon 包含一个
IGameObject getter
可以吗? (原因是,如果我将它存储为 IWeapon,没有 IGameObject getter,那么我将如何获取IGameObject
的详细信息?)
最佳答案
组合与继承是一个需要掌握的非常重要的原则,但是,与任何原则一样,只有正确应用它才会产生积极的效果。 为了正确应用它,您必须了解它是如何被发现的。
C vs I 被认为是因为开发人员在 OOP 上“进城”,尤其是在 C++ 等允许多重继承的语言中。正如您想象的那样,从设计角度来看,一切都很快走下坡路。
通过以下方式很容易想到这个原则: 作为 OOD 系统设计者,我们希望以最类似于我们想要模拟的领域的方式对领域对象关系进行建模 - 因此我们需要仔细仔细地查看这些关系。
每当您要继承时,请务必考虑继承是否紧密地描述了相关实体之间的现实世界关系。
在您的情况下,武器实际上是一个游戏对象,因此继承实际上是一个好主意,并且会在此过程中促进多态性。
这是 C vs I 如何在您的域中应用的示例:
interface IGameCharacter
{
ICollection<IWeapon> Weapons {get;}
ICollection<IGameCharacter> Party {get;}
}
关于c# - 组合优于继承——避免抽象类,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37596286/