Question

我有一个程序，用户可以在其中创建Child对象列表。在他们添加了所有孩子之后，他们可以点击孩子并确定孩子是否调皮，如果是，则创建一个他们不能和他们坐在一起的列表。

我应该在基类中添加一个布尔值IsNaughty和一个列表，还是应该创建一个继承自Child的另一个名为NaughtyChild的类，并实现一个包含列表的ICantSitWith接口。然后，我必须将每个Naughty的孩子变成派生类。

到目前为止我有什么

public class Child
{
    private static int IdCount = 0;
    public string Name { get; set; }
    public int Id{ get;  }
    public Child(string name)
    {
        Name = name;
        IdCount++;
        Id = IdCount;


    }

    public override string ToString()
    {
        return Name;
    }

}

public class DisruptiveChild :Child , ICantSitWith
{

    public List<Child> CantSitNextToo { get; set; }

    public DisruptiveChild(string name, List<Child> cantSitNextToo):base(name)
    {

        CantSitNextToo = cantSitNextToo;
    }

    public DisruptiveChild(string name):base(name)
    {
        CantSitNextToo = null;
    }

}

Answer 1

:) 我会像现实一样走路。当你问“这个孩子能和SomeOne坐在一起吗？”答案是“是的，孩子他自己可以和AnyOne坐在一起，老师不希望他们坐在一起”。所以这是一个外部需求，我不会实现或将其合并到模型中。我会在业务层面实现它。

除非你严格按照老师的观点对类进行建模，否则当然集合“ICantSitWith”应该是基类的基石;）

Answer 2

您只想将方法添加到Child类。

有很多原因，但最引人注目的是你希望用户能够将一个好孩子变成一个顽皮的孩子。

在构造对象的类之后，您无法对其进行更改，因此您无法将非淘气的Child实例更改为NaughtyChild实例。您可以扔掉Child并创建一个新的NaughtyChild，但这会导致面向对象程序中的混淆和复杂化，其中每个对一个东西的引用都应该是对该东西的引用，直到他们被全部扔掉了。

请注意，这是一个简单概念 - 对象的类只确定该类所有实例的不可变特征...只是因为它适用于所有实例的班级，你不能改变它。不注意其他响应中模糊的直观推理。如果顽皮是可变的，那么它不是由面向对象模型中的类决定的。

Answer 3

在我看来，你应该更喜欢组合而不是继承，这样以后你就不会有一个难以管理的复杂继承层次结构。所以你应该有两个接口IChild和INaughtyChild。 INaughtyChild应该继承IChild接口。然后，您可以在两个单独的类中实现这两个接口，其中INaughtyChild实现可以使用IChild实现来实现常见功能。

我应该使用接口，继承还是只添加更多逻辑到基类

3 个答案: