当前位置：文江博客话题详情

类设计“困境”

发布于 2024-09-13 02:52:50 字数 299 浏览 2 评论 0原文

我从来没有做过适当的类设计，所以请耐心等待。

假设我们有一个 Project 类。然后，假设我们有一个 ProjectGroup 类，它具有与 Project 类相同的成员，以及一个 Project 列表。

ProjectGroup 应该是 Project 的超类，还是 ProjectGroup 是 Project 的特化，前者应该是后者？

原文

分享到QQ

分享到微博

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

发布评论

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

赠我空喜 2024-09-20 02:52:50

我不会用理论来打扰您，因为您可能急于获得快速答案。所以事情是这样的：

如果您的两个类实际上暗示它们应该通过继承相关，那么 ProjectGroup 应该从 Project 类继承。这就是 C# 中的样子：

public class ProjectGroup: Project ...

如果不是，但它们使用一些公共类成员（定义它们的状态和该状态上的一些功能），那么我将编写一个接口并在两个类中实现它。再次 C# 代码：

public interface ICommonState ...

public class Project: ICommonState ...

public class ProjectGroup: ICommonState
{
    IEnumerable<ICommonState> projects
    ...
}

编辑

如果您的类实际上是 Project 和 ProjectGroup 并且它们都具有 ID 和 Name 等属性共同点（例如），它们仍然不应该被继承。它们只是碰巧具有相同名称的属性，但它们基本上是不同的实体。

它们都可以

实现 ICommonEntity 接口 - 当它们具有相同的状态+功能但功能行为不同时使用它
从 CommonEntity 类继承 - 当功能时使用它完全相同；这样您将遵循DRY（不要重复自己）哲学，

因此您的组件可能是一个接口或一个类（当使用复合模式时）。

当实体暗示彼此相关时，两个类之间的直接继承更合适。就像User 和Person 类一样。它们可以通过任何一种方式继承。根据业务场景而定。

class User: Person

如果您有一个包含联系人的应用程序，就会出现这种情况。他们中的一些人也是这个应用程序的用户。

class Person: User

这将是一个您可以注册为用户的网站。如果您还填写了一些个人详细信息，您的用户数据将成为 Person 类型。

I won't bother you with theory, because you're probably in a hurry to get a quick answer. So here it goes:

If your two classes are actually implying they should be related by inheritance then ProjectGroup should inherit from Project class. This is how it would look like in C#:

public class ProjectGroup: Project ...

If they are not, but they use some common class members (that define their state and some functionality over that state), then I'd write an interface and implement it in both classes. C# code again:

public interface ICommonState ...

public class Project: ICommonState ...

public class ProjectGroup: ICommonState
{
    IEnumerable<ICommonState> projects
    ...
}

Edit

If your classes are actually Project and ProjectGroup and they both have properties like ID and Name in common (for instance), they still shouldn't be inherited. They just happen to have properties with the same name, but they are basically different entities.

They could both either

implement an ICommonEntity interface - use it when they have the same state+functionality but functionality behaves differently in each of them
inherit from CommonEntity class - use it when functionality is completely identical; this way you'll follow the DRY (don't repeat yourself) philosophy

So your component may be an interface or a class (when using composite pattern).

Direct inheritance between two classes is more suitable where entities imply on being in relation to each other. Like User and Person classes. They can be inherited either way. Depending on the business scenario.