2016-05-10 5 views
0

Ich habe ein Programm, wo der Benutzer eine Liste von Child-Objekte erstellt. Nachdem sie alle Kinder hinzugefügt haben, können sie auf das Kind klicken und entscheiden, ob dieses Kind unartig ist und wenn ja, erstellen Sie eine Liste, mit der sie nicht zusammen sitzen können.Sollte ich eine Schnittstelle, Vererbung oder einfach mehr Logik zur Basisklasse hinzufügen

Soll ich eine boolesche IsNaughty und eine Liste zur Basisklasse hinzufügen, oder sollte ich eine andere Klasse namens NaughtyChild erstellen, die von Child erbt, und eine ICantSitWith-Schnittstelle implementiert, die eine Liste enthält. Ich müsste dann jedes unartige Kind in die abgeleitete Klasse verwandeln.

Was ich bisher

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; 
    } 

}

+0

Es gibt keine Schwarz-Weiß-Regeln, aber im Allgemeinen würde ich ein Design vermeiden, bei dem man ein "Child" -Objekt wegwerfen muss, um ein "DisruptiveChild" -Objekt zu erzeugen. Betrachten Sie stattdessen vielleicht ein Design, bei dem die Beziehungen zwischen Kindern als eigene Entitäten und nicht als Eigenschaften der Kinder selbst modelliert werden. –

+3

Weder. Sie sollten einen Kompositionsansatz favorisieren, der "has-a" Behaviorismen anstelle von "is-a" Vererbung zu Ihren Objekten bringt. –

Antwort

1

:) hätte ich ähnliche Art und Weise gehen, wie es in Wirklichkeit ist. Wenn du fragst "Kann dieses Kind mit SomeOne sitzen?" Die Antwort lautet: "Ja, das Kind selbst kann bei AnyOne sitzen, der Lehrer möchte nicht, dass sie zusammensitzen". Es ist also ein externes Bedürfnis und ich würde es nicht implementieren oder in das Modell integrieren. Ich würde es auf der Geschäftsebene implementieren.

Es sei denn, Sie die Klassen modellieren streng aus der Sicht des Lehrers, dann natürlich die Kollektion „ICantSitWith“ sollte ein Grundstein auf der Basisklasse sein;)

1

Sie wollen nur Methoden hinzufügen, um das Kind Klasse.

Es gibt viele Gründe, aber die überzeugendste ist, dass der Benutzer in der Lage sein soll, ein nettes Kind in ein unartiges Kind zu verwandeln.

Sie können die Klasse eines Objekts nicht ändern, nachdem es erstellt wurde. Daher können Sie eine nicht unartige untergeordnete Instanz nicht in eine NaughtyChild-Instanz ändern. Du könntest das Kind wegwerfen und ein neues NaughtyChild erstellen, aber das würde zu Verwirrung und Komplikationen in einem objektorientierten Programm führen, wo jeder Verweis auf ein Ding erwartet wird, eine Referenz auf dieses Ding zu sein, bis sie alle sind weggeworfen.

Hinweis, dass dies ein einfache Konzept - die Klasse eines Objekts bestimmt nur unveränderlich Eigenschaften aller Instanzen dieser Klasse ... nur weil es für alle Instanzen der Klasse gilt und Sie können es nicht ändern . Achte nicht auf die verschwommene intuitive Argumentation in anderen Antworten. Wenn Ungewissheit veränderlich ist, dann wird sie nicht durch die Klasse in einem objektorientierten Modell bestimmt.

+0

Dies scheint die einfachste und die Lösung, mit der ich gehe, Danke. –

0

In meiner Openion sollten Sie Komposition über Vererbung bevorzugen, damit Sie später nicht mit einer komplexen Vererbungshierarchie enden, die schwer zu verwalten ist. Sie sollten also zwei Interfaces IChild und INaughtyChild haben. INaughtyChild sollte von IChild Interface erben. Anschließend können Sie die zwei Schnittstellen in zwei separaten Klassen implementieren, wobei die INaughtyChild-Implementierung die IChild-Implementierung für allgemeine Funktionen verwenden kann.

Verwandte Themen