Ist es eine schlechte Form, auf einen abgeleiteten Typ in einem Basistyp zu verweisen?

Question

Ich habe eine Kategorie/Datei Baumstruktur. Beide Kategorien und Dateien können Eltern haben, daher habe ich sie aus einer gemeinsamen Basisklasse mit einer Parent-Eigenschaft abgeleitet. Da alle Eltern offensichtlich immer Kategorien sind (Dateien können keine Eltern sein), scheint es sinnvoll zu sein, die Parent-Eigenschaft des Knotens zum CategoryNode-Typ zu machen.

Ist es eine schlechte Form für die Basisklasse, auf die abgeleitete Klasse zu verweisen? Wenn ja warum? Was ist eine bessere Möglichkeit, dies zu strukturieren, wenn ja?

class Node { 
    public CategoryNode Parent {get; set;} 
} 

class File : Node { 
    ... 
} 

class CategoryNode : Node { 
    ... 
} 

Answer 1

Wenn die Eigenschaft Parent ist eigentlich eine gemeinsame Eigenschaften aller Nachkommen und immer der Art CategoryNode, es ist kein Problem. Semantisch gesehen ist es korrekt und technisch ist es auch korrekt, sobald Sie in derselben Bibliothek bleiben (um zirkuläre Referenzen zu vermeiden).

Dies kann ein Problem sein, wenn Sie Code wie folgt schreiben:

// BAD CODE 
if(myProp is subclassA) 
{ ... 
} 
else if (myProp is syubclassB) 
{ ... 
} 

Dieser Code ist schlecht, weil Sie den Vorteil der Vererbung verlieren.

Auch im .NET Framework gibt es solche Konstrukte. Das erste Beispiel, das mir in den Sinn kommt, ist die -Eigenschaft.

XElement erbt XObject und XObject veröffentlicht eine Eigenschaft des Typs XElement. Genau wie Ihr Snippet.

Answer 2

Die Basisklasse sollte nicht wissen, wer davon abgeleitet wird.

Wenn Sie einen solchen Fall haben, wollen Sie wahrscheinlich keine Vererbung. Sie sollten nur eine Form der Kopplung verwenden.

Die Datei und CategoryNode sollte in Ihrem Fall ein Node-Mitglied enthalten.

Answer 3

Andere Optionen bestehen darin, die Klassenhierarchie zu ändern, um den CategoryNode zu einer Stammklasse (a) zu machen, oder den Eigenschaftstyp in Node (b) zu ändern.

Beide Möglichkeiten sind nicht gut: (a) Datei wird alle Funktionen haben, die CategoryNode hat, die es nicht benötigt. (b) Es wird den Objekttyp (der immer CategoryNode ist) ausblenden. Dies kann zu ungültigen Besetzungsfehlern an anderer Stelle in Ihrem Code führen. Zum Beispiel, wenn Sie vergessen, gibt es immer eine CategoryNode-Instanz.

In Anbetracht dessen glaube ich, dass der aktuelle Code in Ordnung ist.

Answer 4

Sie tun könnte ...

interface IParent { 
    ... 
} 

class Node { 
    public IParent Parent {get; set;} 
} 

class File : Node { 
    ... 
} 

class CategoryNode : Node, IParent { 
    ... 
} 

Auf diese Weise müssen Sie nicht auf ein abgeleitetes Objekt in der Basisklasse beziehen müssen, plus, Sie flexibler sind in dem, was ein Elternteil tatsächlich werden kann , falls Sie zu einem späteren Zeitpunkt weitere Objekttypen erhalten. Außerdem kann jede Funktionalität, die nur für ein Elternelement relevant ist, in dieser Schnittstelle deklariert werden.