Question

我从未做过适当的课堂设计，所以请耐心等待。

假设我们有一个Project课程。然后，假设我们有一个ProjectGroup类，其成员与Project类相同，另外还有一个Project列表。

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

Answer 1

我不会打扰理论，因为你可能急于快速回答。所以这就是：

如果你的两个类实际上暗示它们应该通过继承相关联，那么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类型。

Answer 2

听起来你可能想要复合模式。 LeafProject和CompositeProject都实现了Project接口，CompositeProject还包含Project实例的集合。

Answer 3

如果项目成员列表对于projectgroup是唯一的，并且不适用于所有类型的项目，那么将项目作为超级/基类并从项目中派生项目组。

阶级设计'困境'

3 个答案:

修改