继承或枚举

发布于 2024-09-07 00:25:59 字数 539 浏览 10 评论 0原文

我必须为应用程序构建新模型,但我不知道哪个更好:

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

例如:

书籍

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,
...
}

I must structure new model for application and I don't what is better:

using inheritance or using enum as type of object:

For example :

Books

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
{

}

or better use:

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,
...
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

不交电费瞎发啥光 2024-09-14 00:25:59

如果不同类型有显着差异(如何处理和对待它们),请使用继承。也就是说,如果您要使用多态性,则应该使用继承。

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

Use inheritance if the different types have significant differences (how you process them and treat them). That is, if you are going to use polymorphism at all, you should use inheritance.

If you only need a way to distinguish different types of books, go with the Enum.

痕至 2024-09-14 00:25:59

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

因此,如果您需要在 Book 中实现不同的行为来响应方法调用,请扩展 Book 并重写它的一些方法。如果你不这样做,那就不要。

鉴于您的子类是空的,它们的行为在各方面都与书籍相同。因此,您只是用一些附加数据来标记这本书 - 百科全书和小说之间的区别对于这本书来说并不比精装本或平装本或大印刷版或标准印刷版更重要 - 客户可能会以不同的方式使用这些数据,并且每本书要么是一本大书纸质书或者是标准纸质书,但这些都是书的属性而不是本质区别。

我不需要对书籍类型使用枚举,因为您可能想要添加更多数据 - 我要么使用松散的标记系统,这样您就可以用一系列类型来标记一本书 - 这样您就会有一本书标记为 { 'children's', 'ornithological', 'encyclopaedia', } - 或允许角色中的结构 - 因此在需要时创建 'children's ornithological encyclopaedia' 角色,但没有固定的枚举。

In true object oriented systems, the type of the object is transparent to the client. So the code which handles books should not know what the type of the book is, but only invoke methods on books.

So if you need to implement different behaviour within the book in response to the method invocation, extend Book and override some of its methods. If you don't, then don't.

It appears, given the empty bodies of your subclasses, that they behave in every way the same as books. So you are merely tagging the book with some additional data - the difference between Encyclopaedia and Novel is no more essential to the book than hardback or softback or large print or standard print - a client may use these differently, and each book either is a large print book or it is a standard print book, but these are all attributes of the book rather than essential differences.

I wouldn't necessary use an enum for the book kind, since you may want to add more data - I'd either use a loose tagging system, so you can tag a book with a collection of kinds - so you would have a book tagged as { 'children's', 'ornithological', 'encyclopaedia', } - or allow structure in the roles - so there is a role for 'children's ornithological encyclopaedia' created when it is required, but no fixed enumeration.

清音悠歌 2024-09-14 00:25:59

我想说第二个会更好,因为您并没有真正扩展百科全书中的书籍类,您不需要为一种书籍类型提供​​相对于另一种书籍类型的附加属性或功能。

I would say that the 2nd would be better as you are not really extending the book class in your Encyclopaedia, there are no additional properties or functionality you need to give one book type over another.

流云如水 2024-09-14 00:25:59

“最好”是主观的,很大程度上取决于类/模型的目的。
你的目标是什么?你想实现什么目标?

在这一点上,我最多可以说,当派生类具有一些相当独特的属性时,继承是有用的 - 例如百科全书具有解释它实际上是什么类型的百科全书的属性,并且这些属性无论如何都不属于小说。

"best" is subjective and heavily depending on the purpose of the class / model.
What is your goal? What do you want to achieve?

At best at this point I can say is, inheritance is useful when the derived class has some fairly unique properties - like Encyclopedie has properties explaining which type of Encyclopedie it actually is and those properties do not, in any way, belong to a novel.

童话里做英雄 2024-09-14 00:25:59

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

It really depends. The first solution is better if you need to use Polymorphism. From my personal opinion, I prefer using inheritance.

若言繁花未落 2024-09-14 00:25:59

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

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

If the different types of books will have different attributes you should definately use an inheritance model. This also allows for polymorphism, which is usually better

If they will all have the same attributes, you might as well go with the enum. But it all depends on the application.

清风无影 2024-09-14 00:25:59

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

I think you should make this choice based on what the book "purpose" is. If the books don't need any additional stuff (methods and properties....) enum should be enough. If you have to create a common behavior for every book and something else more specific for each book type you obviously need inheritance (abstract class "book", and concrete classes).

还给你自由 2024-09-14 00:25:59

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

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

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

再见!

using an enum to "type" your object sounds a bit of "old C-style" programming.

I mean, it is ok, but when inheritance is available (you're using C#) it is generally a better choice. An enum generally introduces some "trouble" for example when serializing/deserializing data: what if an old version of your application uses a "newer" scenario in which a BookType has an unknown item? (backward/forward compatibility could be a requirement for your app)

Of course, you can handle this with a bounch of "if-then-else" but inheritance seems a cleaner choice in my point of view.

Bye!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文