Feststellen, ob Typ des Objekt die Ableitung eines anderen ist

markus.r

7H3 N4C3R schrieb:

Das ist aber wiederum ein Bruch mit dem Liskov-Substitution-Principle.

Wenn ich das richtig verstanden habe, dass das "Liskov-Substitution-Principle" auch als "ist-ein"-Regel bekannt ist, dann stimme ich zu, dass ich die Klasse B etwas voreilig in das Beispiel eingefuehrt.
In dem realen Projekt ist das selbstverstaendlich nicht der Fall.

Ich veranschauliche das Problem mal anders.
Es geht hier um das Sortieren von Autos.

class Fahrzeug {};
class Sportwagen : Fahrzeug {};
class Porsche : Sportwagen {};
class Ferrari : Sportwagen {};
class Traktor : Fahrzeug {};

//und nun die Listen
list<Fahrzeug*> parkplatz;
list<Sportwagen*> parkplatz_golfplatz;
list<Porsche*> prosche_haendler;
list<Traktor*> acker;

7H3 N4C3R schrieb:

Die Problembeschreibung klingt ein wenig nach einem GUI mit Baumansicht, in der Drag and Drop möglich sein soll

Exakt das ist eine Teilanwendung davon, sehr gut "hellgesehen":-)

7H3 N4C3R

Beim LSP (oder ganz grundsätzlich bei öffentlicher Vererbung) geht das "ist ein" gleichher mit "verhält sich wie ein".

Deine GUI könntest du als ein Kompositum darstellen. Wenn etwas in einen Knoten eingefügt werden soll, wir von diesem eine virtuelle accept( T*) Methode aufgerufen. Je nach Knotenklasse entscheidet diese, ob sie das übergebene Objekt akzeptiert oder ob es abwiesen wird.

Beispiel:

class Base
{
public:
  virtual void accept( Base*) = 0; 
};

class A : public Base
{
public:
  virtual void accept( Base* b)
  {
    if( !dynamic_cast<A*>(b)) {
      throw std::runtime_error( "Du kommst hier net rein.");
    }
  }
};

So musst du nur noch jeder Knotenklasse beibrigen, was sie akzeptiert und was nicht. Allerdings wird es wieder schwieriger mit der Listenbildung, da du dir im Baum jetzt erstmal alle Blätter suchen musst und daraus dann die Liste formen. Und natürlich kann jeder Knoten selbst entweder ein Blatt oder eine Liste sein. Das bringt ein Kompositum nunmal so mit sich.

markus.r

Eigentlich ist diese Idee nicht so kompliziert bei mir umzusetzen, da die Knoten in der Baumansicht sich lediglich auf das echte davon völlig unabhaengige Datenmodell referenzieren.

Der Angleich wird über eine Controller-View-Modell-Implementierung vollzogen.
Die Baumsicht ist nur eine von diversen Views auf das Modell.
Das Modell habe ich bisher so passiv wie moeglich gehalten aus verschiedenen Gruenden. D.h. es werden bisher Operationen auf das Modell, welche im Wesentlichen STL-Operationen sind, nicht nochmal gekapselt, da diese (zumindest) zur Compile-Zeit typsicherheit komfrortabel sicherstellen.

Vielleicht muss ich diesen Ansatz überdenken.

PS: Vielen dank für die freudliche und hochwertige Hilfe.