继承或枚举

时间:2010-06-24 07:51:15

标签: c# inheritance modeling

我必须为应用程序构建新模型,而不是更好的方法:

使用继承或使用enum作为对象类型:

例如:

图书

class Book
{
public string Name {get;set;}

public string Author {get;set;}

public int NumberOfPages {get;set;}

}

public class Encyclopedie:Book
{

}

public class Novel:Book
{

}

或更好地使用:

class Book
{

public BookType Type {get;set;}

public string Name {get;set;}

public string Author {get;set;}

public int NumberOfPages {get;set;}

}

public enum BookType
{
Encyclopedie = 0,
Novel = 1,
...
}

8 个答案:

答案 0 :(得分:22)

如果不同类型存在显着差异(如何处理它们并对其进行处理),请使用继承。也就是说,如果你要使用多态,你应该使用继承。

如果您只需要一种区分不同类型书籍的方法,请使用Enum。

答案 1 :(得分:3)

在真正的面向对象系统中,对象的类型对客户端是透明的。所以处理书籍的代码不应该知道书的类型是什么,而只是调用书上的方法。

因此,如果您需要在本书中实现不同的行为以响应方法调用,请扩展Book并覆盖其某些方法。如果你不这样做,那就不要了。

考虑到你的子类的空体,它们的表现方式与书籍相同。所以你只是用一些额外的数据来标记这本书 - 百科全书和小说之间的区别对于这本书而言并不比精装本或软背或大字版或标准版本更重要 - 客户可能会以不同的方式使用这些,而且每本书都是大的印刷书籍或它是一本标准的印刷书籍,但这些都是本书的所有属性而非本质区别。

我没有必要使用这本书的枚举,因为你可能想要添加更多的数据 - 我要么使用松散的标记系统,所以你可以用一组种类来标记一本书 - 所以你会有一本书标记为{'儿童','鸟类','百科全书',} - 或允许角色中的结构 - 所以在需要时创建'儿童鸟类百科全书',但没有固定的枚举。

答案 2 :(得分:2)

我会说第二个会更好,因为你并没有真正扩展你的百科全书中的书类,没有额外的属性或功能你需要给一种书籍类型而不是另一种。

答案 3 :(得分:2)

“最佳”是主观的,严重依赖于类/模型的目的。 你的目标是什么?你想要达到什么目标?

最好在这一点上我可以说,当派生类具有一些相当独特的属性时,继承是有用的 - 比如Encyclopedie具有解释它实际上是哪种类型的Encyclopedie的属性,并且这些属性不属于任何方式属于一部小说。

答案 4 :(得分:0)

这取决于。如果您需要使用多态性,第一种解决方案会更好。从我个人的角度来看,我更喜欢使用继承。

答案 5 :(得分:0)

如果不同类型的书籍具有不同的属性,您应该明确使用继承模型。这也允许多态,通常更好

如果它们都具有相同的属性,那么你也可以使用枚举。但这一切都取决于应用程序。

答案 6 :(得分:0)

我认为你应该根据这本书的“目的”来做出这个选择。如果书籍不需要任何额外的东西(方法和属性....)枚举应该就够了。如果你必须为每本书创建一个共同的行为,而对每种书类型更具体的东西,你显然需要继承(抽象类“书”和具体类)。

答案 7 :(得分:-1)

使用枚举“输入”你的对象听起来有点像“旧C风格”的编程。

我的意思是,没关系,但是当继承可用时(你正在使用C#),它通常是更好的选择。例如,在序列化/反序列化数据时,枚举通常会引入一些“麻烦”:如果旧版本的应用程序使用BookType具有未知项目的“较新”场景,该怎么办? (向后/向前兼容性可能是您的应用程序的要求)

当然,你可以用“if-then-else”来处理这个问题,但在我看来,继承似乎是一个更清晰的选择。

再见!