Probleme mit abgeleiteten Klassen

Hi,

ich habe ein Problem bei dem ich nicht weiter komme. Ich möchte Abgeleitete Klassen für einander austauschen.
Sprich ich habe zwei Basisklassen Document und Mask. Von denen habe ich die Klassen BookDocument, BookMask,
RecipeDocument, RecipeMask abgeleitet.
In meinem Programm möchte ich nach belieben die Abgeleiteten Klassen für einander austauschen.

Code:

---

class Document{};

class BookDocument: public Document{};

class RecipeDocument: public Document{};

class Mask{};

class BookMask: public Mask{};

class RecipeMask: public Mask{};

if(test == "recipe"){
    document = static_cast<RecipeDocument *>(document);
    document = new RecipeDocument;
               
    mask = static_cast<RecipeMask *>(mask);
    mask = new RecipeMask(document);
}
else if(test == "book"){
    document = static_cast<BookDocument *>(document);
    document = new BookDocument;
               
    mask = static_cast<BookMask *>(mask);
    mask = new BookMask(document);
}

---

Zum einen bekomme ich Probleme bei der Vorwärts Deklaration,

Code:

---

class BookDocument: public Document{
...
};

class Document;

---

Zum Anderen hat der static_cast nicht das gebracht was ich wollte.

Code:

---

    document = static_cast<RecipeDocument *>(document);

---

Und ich muss in jeder Methode der Abgeleiteten Klasse die Methode der Basis Klasse aufrufen:

Code:

---

void BookDocument::init(){

    Document::init();

}

---

Was auch nicht gerade schön ist.

Gern kann ich auch den Quellcode hinauf laden. Doch wollte ich es erst einmal übersichtlich belassen.

Ich bin jetzt wieder zu der braven Version zurück gekehrt:

Code:

---

class::class(){
    rdocument  = new RecipeDocument;
    rmask = new RecipeMask(document);

    bdocument = new BookDocument;
    bmask = new BookMask(bdocument);

}

void class::method(){
      if(test == "recipe")
            arbeite mit rdocument und rmask;
      else if(test == "book")
            arbeite mit bdocument und bmask;
}

---

Macht zwar deutlich mehr Aufwand, als ein Pointer auf das benötigte Element. Aber dafür Typsicherheit...

Ich bin mir nicht ganz sicher, welchen Effekt du zu erreichen versucht hast.

Die Casts im ersten Beitrag machen eigentlich keinen Sinn, auf beiden Seiten befindet sich die selbe Variable.

Nehmen wir an "document" ist vom Type "Document" dann ändert der Cast die Sichtbarkeit der Typinformation auf, z.B., BookDokument
Aber das wird nicht benutzt, denn das Resultat des Casts wird wieder nur auf "document" zugewiesen, was die sichtbare Typinformation wieder auf "Document" zurück bringt.

Danach wird überhaupt gleich eine neue Instanz angelegt, welchen Typ die alte Instanz hatte ist damit ohnehin nicht länger relevant.

Die Methode der Basisklasse musst du nur aufrufen, wenn du (a) die Methode in erster Linie ünerhaupt überschrieben hast und (b) du weiterhin die Funktionalität der Basisimplementierung ausgeführt haben möchtest.

Das von dir angeführte Beispiel, also dass die überschriebene Methode ohnehin nichts anderes macht als die Basisimplementierng, wäre gleich bedeutend damit, die Methode erst gar nicht zu überschreiben.

Wie gesagt lässt sich aus den vorhandenen Informationen leider nicht erkennen, welchen Effekt du gerne gehabt hättest.

Ciao,
_

Hi anda_skoa,

erst einmal vielen Dank für deine Hilfe. Mit dem cast hattest du Recht, er bringt wirklich nicht den Effekt den ich mir gewünscht hatte.
Mein Problem ist, das ich einen Pointer deklarieren muss. der für zwei verschiedene Klassen im Programm funktionieren soll.

Code:

---

Document *document;

---

im Verlauf des Programmes wird mehrmals eine Methode aufgerufen die den Pointer immer wieder neu füllen soll. Einmal mit RecipeDocument und ein anderes Mal mit Bookdocument.

Code:

---

void class::method(){
      if(test == "recipe")
            document = new Recipedocument;
      else if(test == "book")
            document = new BookDocument;
}

void class::clear(){
      delete document;
}

---

Ich werde morgen früh, sagen wir besser morgen Vormittag ;), Den Quellcode mal hinaufladen. Ich könnte zwar auch jetzt schon auf das Programm verweisen, doch es würde nicht wirklich etwas bringen, da die Problematik noch nicht darin enthalten ist.

Das sollte so schon mal funktionieren, also die Basisklasse als Variablentype, getrenntes Erzeugen und einheitliches Löschen.

Ciao,
_

Tja, was soll ich sagen. Ich habe es ausprobiert und es funktioniert.

Wünsche Frohe Weihnachten!

Das Wichtigste für das Löschen mittels Basisklassenpointer ist, dass der Destruktor der Basisklasse virtual ist.

Ciao,
_

Hi,
frohes Neues! Hat leider nicht geklappt. Der Kompiler hatte es akzetiert da beide von der gleichen Klasse sind. Methoden der Kindklasse wurden aber nicht akzeptiert.
Ich habe jetzt einmal den Quellcode hinauf geladen:
Quellcode

Ich hoffe es macht die Sache nicht zu unübersichtlich.

Versionen:
0.4.0 (funktionierende Version mit nur einer Maske)
0.4.1 (mehrere Masken mit Eltern->Kind Beziehung)
aktuell: 0.4.1.2 (mehrere Masken zur besseren Übersicht ohne Eltern->Kind Beziehung)

wichtige Stellen:
MainWidget.h: 72 RecipeDocument *document;
MainWidget.cpp: 231 document = new AnimalDocument;
MainWidget.cpp: 238 document = new BookDocument;
MainWidget.cpp: 245 document = new RecipeDocument;
MainWidget.h: 54 enum BookType { EMPTY, ANIMAL, BOOK, RECIPE};

Ich konnte leider nicht so leicht erkennen, inwiefern sich die verschiedenen Dokumente unterscheiden.

Die start() Methode scheint immer das gleiche zu machen, ebenso readDocument().

In start() scheint dabei jeweils eine vom Dokumenttyp zugehörige Mask Instanz verwendet zu werden, die dann in ihren jeweiligen fill() Methoden unterschiedliche Sachen machen.

Für diesen Fall sehe das dann in etwa so aus

Code:

---

class Mask
{
public:
    virtual ~Mask() {}

    virtual void fill( QString file_content, QFileInfo fileinfo ) = 0;
};

---

Code:

---

class BookMask : public Mask
{
public:
    // Implementierung von BookMask::fill()
    void fill( QString file_content, QFileInfo fileinfo );
};

class RecipeMask : public Mask
{
public:
    // Implementierung von RecipeMask::fill()
    void fill( QString file_content, QFileInfo fileinfo );
};

---

Code:

---

class Document
{
public:
    virtual ~Document() { delete mask; }

    // die gemeinsame Implementierung
    void start();

protected:
    explicit Document(Mask *mask) : mask(mask) {}

    Mask *mask;   
};

---

Code:

---

class BookDocument : public Document
{
public:
    BookDocument() : Document(new BookMask) {}
};

class RecipeDocument : public Document
{
public:
    RecipeDocument() : Document(new RecipeMask) {}
};

---

Also die Implementierung von start() ist für alle Document Klassen identisch, den Unterschied macht die jeweilige Mask Klasse bzw dessen fill() Methode.

Das hier ist eine Art Basisfall, d.h. es gibt keine Gemeinsamkeiten von BookMask::fill() und RecipeMask::fill(), die Methode Mask::fill() ist daher "pure virtual" (virtual vorne und "= 0" am Ende).

Wenn der aufrufende Code das hier ist:

Code:

---

Document *document = new BookDocument();
document->start(....);

---

dann wird in mask->fill() aufgerufen. Nachdem "this" in diesem Fall ein BookDocument ist, ist "mask" ein BookMask, d.h. BookMask::fill() wird aufgerufen.

In deinem Code gibt es allerdings Gemeinsamkeiten, d.h. es gibt potentiell Möglichkeiten duplizierten Code zu vermeiden.
Dafür gibt es mehrere Ansätze, die oft auch kombiniert werden können.

Beispiel: in den beiden fill() Methoden, die ich mir angesehen habe, sind "check version" und "get color" identisch.
Man könnte die also als Methoden in Mask (Basisklasse) hinzufügen

Code:

---

class Mask
{
protected:
  QString version;
  QColor color_cmb;

  void getVersion(QString file_content);
  void getColor(QString file_content);
};

---

Die fill() Methoden von BookMask und RecipeMask könnten dann so etwas machen

Code:

---

void BookMask::fill(QString file_content, QFileInfo fileinfo)
{
    getVersion();

    // get name

    getColor();

    // get book specific data
}

---

Hier ist "get name" innerhalb des ansich gleichen Teils. Wenn die Reihenfolge egal ist, kann man dass natürlich in den "specific" Teil ziehen und sowas machen

Code:

---

class Mask
{
public:
    virtual void fill( QString file_content, QFileInfo fileinfo )
    {
        getVersion();
        getColor();

        // usw
    }
};

class BookMask : public Mask
{
public:
    virtual void fill( QString file_content, QFileInfo fileinfo )
    {
        // get common data
        Mask::fill(file_content, fileinfo);

        // get book specific data
    }
};

---

Wieder unter Annahme des aufrufenden Codes von oben: Document::start() ruft mask->fill() auf. "mask" ist vom Typ BookMask, also wird BookMask::fill() ausgeführt. Das leitet erstmal auf Mask::fill() weiter und macht dann seinen Rest.

Wenn das nicht reicht, also wenn z.B. die Reihenfolge der Leseoperationen wichtig ist, z.B. "get name" zwar typspezifisch ist aber immer zwischen "get version" und "get color" gemacht werden muss, dann kann man das so lösen

Code:

---

class Mask
{
public:
    virtual void fill( QString file_content, QFileInfo fileinfo )
    {
        getVersion();
        getName();
        getColor();

        // usw
    }

protected:
    virtual void getName() = 0;
};

class BookMask : public Mask
{
public:
    virtual void fill( QString file_content, QFileInfo fileinfo )
    {
        // get common data
        Mask::fill(file_content, fileinfo);

        // get book specific data

protected:
    void getName()
    {
        // get name in book specific way
    }
};

---

In diesem Fall wird in Mask::fill() der Aufruf von getName() wieder zurück nach BookMask::getName() geleitet und danach mit dem gemeinsamen Code ("get version") weiter gemacht.

Ciao,
_

P.S.: ein paar generelle Anmerkungen: :)

* QFile kann am Stack, also ohne new, erzeugt werden wenn es nur innerhalb einer Methode benutzte wird. Das stellt sicher, dass das Objekt auch wieder zerstört wird, Derzeit hast du einige Leaks, z.b. buf_file in RecipeDocument::readDocument(), wenn das Öffnen fehlschlägt.

* Wenn es über mehrere Methoden hinweg genutzt wird, sollte es zumindest im Destructor der Klasse gelöscht werden.

* qDebug() << Q_FUNC_INFO << ....;

Hi anda_skoa,

erst einmal vielen Dank, das du dir die Mühe gemacht hast meinen Quellcode zu berichtigen!
Mit den Leaks hast du Recht, da hat QFile mir immer in Verbindung mit QTextStram Probleme bereitet.
Ich bin bei Version 0.4.1.2 von dem Ableiten von Klassen wieder weggegangen, da ich Glaubte für einen Drittten, der nur schnell Mal seine eigene Maske erstellen will, ist es so leichter. Gerne gehe ich wieder auf 0.4.1 zurück, ich kenne ja meinen Code.
Danke für die vielen Tips!

Zitat:

---

Zitat von dml

Ich bin bei Version 0.4.1.2 von dem Ableiten von Klassen wieder weggegangen, da ich Glaubte für einen Drittten, der nur schnell Mal seine eigene Maske erstellen will, ist es so leichter.

---

Beide Ansätze haben ihre Vor- und Nachteile.

EIne komplexe Ableitungshierachie kann schwer zu verstehen sein, oder sogar falsch verstanden werden. In deinem Fall ist das aber sehr überschaubar.

Auf der anderen Seite kann die Notwendigkeit, gemeinsamen Code zu kopieren auch schlecht sein. Zum Beispiel wird dann vielleicht Code kopiert und eingesetzt, der zwar scheinbar funnktioniert aber ungeahnte Nebeneffekte hat.

Oder wenn Fehler in solchen Codesegmenten gefunden werden, müssen sie in allen Kopien ebenfalls gefunden und behoben werden.

Eine dritte Möglichkeit ist, gemeinsamen Code unabhängig von Vererbung auszulagern und dann Aufrufe zu delegieren.

Nehmen wir als Beispiel BookMask::fill(). Dort hast du im Wesentlichen zwei Arten von Funktionalität:
* extrahieren aus dem Dateiinhalt
* Füllen von Widgets

In einer der Varianten habe ich einzelne Kombinationen davon in protected Methoden der Basisklasse ausgelagert, z.B. getColor().

Diese Methode würde dabei sowohl das Extrahieren der Farbe, als auch das Setzen am ColorListEditor machen.

Wir könnten das aber auch anders trennen, also z.B. so

Code:

---

class CommonDataParser
{
public:
    explicit CommonDataParser(QString file_content) : file_content(file_content) {}

    QString getVersion() const;
    QColor getColor() const;

private:
    const QString file_content;
};

QString CommonDataParser::getVersion() const
{
    static QRegExp exp(".*<version>(.*)</version>.*");
                  if (exp.exactMatch(file_content)){
                            return exp.cap(1);
                  }
    return QString();
}

QColor CommonDataParser::getColor() const
{
    static QRegExp exp(".*body. color: (#......); background-color: #......;.*");

    QColor color;
                  if (exp.exactMatch(file_content))
                            color.setNamedColor(exp.cap(1));

    if (!color.isValid())
        color = Qt::black;

    return color;
}

---

BookMask::fill() kann dann einfach ein Objekt davon erzeugen und benutzen

Code:

---

void BookMask::fill(QString file_content, QFileInfo fileinfo)
{
    CommonContentParser parser(file_content);

    version = parser.getVersion();
    color_cmb->setColor(parser.getColor());
}

---

Das lässt sich natürlich auch mit Ableitungen von Mask oder Document kombinieren.

Einer der Vorteile dieser Auslagerung ist, dass man die ausgelagerte Funktionalität leichter testen kann, z.B. in automatischen Unittests mittels QTestLib.

Ciao,
_

Stimmt, die getSaveString() Methode aufzuteilen, daran hatte ich gestern auch noch gedacht. Doch vorher wollte ich über den QXMLParser nachdenken. Denn den Bereich XML habe ich noch ausgelassen und Trickse das Html-Dokument eigentlich nur ein bisschen aus. Das ist vorher noch von mir nachzuprüfen.
Beim Quellcode bin ich auch wieder zu der Vererbung zurückgekehrt. Das Projekt basiert auf OOP und wer eine eigene Maske erstellen will, muss das auch können und nicht wie du schon sagtest halb.

Es gibt leider noch ein kleines Problem mit der Typumwandlung. Das Ableiten der Klassen hat wirklich sehr geholfen, doch weiß ich noch nicht wie ich das Objekt umwandeln kann.

Code:

---

mainwidget.cpp 318;                case RECIPE:
mainwidget.cpp 319;                      qDebug()<<"\nRecipeDocument";
mainwidget.cpp 320;//                      mask    = rmask;
mainwidget.cpp 321;//                      document = rdocument;
mainwidget.cpp 322;//                      mask = dynamic_cast<RecipeMask*>(mask);
mainwidget.cpp 323;//                      document dynamic_cast<RecipeDocument*>(document);
mainwidget.cpp 324;                      mask    = (RecipeMask*) mask;
mainwidget.cpp 325;                      document = (RecipeDocument*) document;
mainwidget.cpp 326;                     
mainwidget.cpp 327;                      break;

---

Es soll weiterhin das selbe Objekt sein und nicht auf ein Anderes zeigen.

Edit:
Nun gut, ich wollte etwas zusammenführen was nicht zusammen gehört. Bei einer theoretischen Umwandlung, müsste dennoch z.B. initialisiert werden. Ich rede mich jetzt mal einfach mit mangelnder Erfahrung herraus.

Ich bin mir nicht ganz sicher, was du erreichen möchtest. Der Codeausschnitt gibt dazu zu wenig Informationen.

Ich nehme an, du hast eine Variable mit dem Basistyp, also z.B. Document *document.
Der zeigt in Falle von RECIPE auf eine Instanz von RecipeDocument.

An einer bestimmten Stelle möchtest du mit diesem abgeleiteten Typ arbeiten, z.B. mit Funktionen die in RecipeDocument deklariert sind und in Document nicht vorhanden sind.

Code:

---

class Document
{
public:
    virtual ~Document() {}
};

class RecipeDocument : public Document
{
public:
    void printCalories(); // nur in RecipeDocument, nicht in Document
};

---

Code:

---

Document *document = new RecipeDocument;

// arbeiten mit den Methoden von Document

// Fallunterscheidung für Spezialanforderungen

switch (type) {
    case RECIPE:
        static_cast<RecipeDocument*>(document)->printCalories();
        break;
}

// oder für mehrere Aufrufe

switch (type) {
    case RECIPE: {
        RecipeDocument *recipe = static_cast<RecipeDocument*>(document);
        recipe->printCalories();
        // andere RecipeDocument spezifische Aufrufe
        break;
    }
}

---

Oder wenn z.B. der Typ nicht bekannt ist

Code:

---

RecipeDocument *recipeDocument = dynamic_cast<RecipeDocument*>(document);
if (receipeDocument != 0) {
    recipeDocument->printCalories();
}

---

Als generelle Empfehlung würde ich auf den Einsatz von Casts im C-Stil verzichten, also sowas

Code:

---

(RecipeDocument*)document

---

Ciao,
_

Mein Problem war, das ich ein Objekt nach Bedarf umwandeln wollte:

Code:

---

mask    = (RecipeMask) mask;
...
 mask    = (BookMask) mask;

---

Doch das ist schon logisch nicht möglich. Da bei einer Typumwandlung der neue Typ eh neu aufgebaut werden muss. Also einen Konstruktor durchläuft.
Hinzu kam, das das Signal erst nach Abarbeitung des Slots beendet wird und ich genau in dem Slot das Objekt löschen und neu initialisieren wollte.
Da fehlt mir halt noch die Übung, aber danke das Du mir den cast noch einmal genauer erklärt hast.
Auch sind die Mehtodenbezeichnungen MainWidget:newDocument() falsch ind irreführend. Mir fällt derzeit keine richtige Bezeichnung ein, sie müssten in etwa MainWidget::newDocumentAndMask() heissen.

Zitat:

---

Zitat von dml

Mein Problem war, das ich ein Objekt nach Bedarf umwandeln wollte:

Code:

---

mask    = (RecipeMask) mask;
...
 mask    = (BookMask) mask;

---

Doch das ist schon logisch nicht möglich.

---

Das ist schon möglich, nur muss man sich das Resultat des Casts merken, d.h. die Typinformation nicht gleich wieder verwerfen so wie da in diesem Beispiel der Fall ist.

Was du hier hast sind quasi zwei Teile:
1) der Cast, z.b. (BookMask*)mask, besser static_cast<BookMask*>(mask);

2) eine Zuweisung: mask = resultat_des_cast

Nach (1) "sieht" der Compiler den gecasteten Typ, also BookMask*.
"mask" ist aber vom Typ Mask*, d.h. nach (2) "sieht" der Compiler wieder nur die Typinformation Mask*

Zitat:

---

Zitat von dml

Da bei einer Typumwandlung der neue Typ eh neu aufgebaut werden muss. Also einen Konstruktor durchläuft.

---

Nein. Der Pointercast ändert nichts am Objekt selbst, er verändert lediglich wie der Compiler das Objekt hinter dem Pointer betrachtet.

Code:

---

BookMask *bookMask = new BookMask;

Mask *mask = bookMask;

BookMask *bookMask2 = bookMask;
BookMask *bookMask3 = static_cast<BookMask*>(mask);

---

Alle view Pointer zeigen auf das selbe Objekt.

Zitat:

---

Zitat von dml

Hinzu kam, das das Signal erst nach Abarbeitung des Slots beendet wird und ich genau in dem Slot das Objekt löschen und neu initialisieren wollte.

---

Das sollte schon klappen. Der Code, der das Signal aussendet arbeitet davor und danach nur mit dem Basistyp, oder?

Ciao,
_

Zitat:

---

Code:

---

BookMask *bookMask = new BookMask;

Mask *mask = bookMask;

BookMask *bookMask2 = bookMask;
BookMask *bookMask3 = static_cast<BookMask*>(mask);

---

---

Es sieht ganz stark danach aus, das dessen Typ dann Mask ist. Wenn das so ist, ist meine Grundannahme von Typumwandlung falsch.

Code:

---

class MainWidget : public QWidget {
        ....
        Mask                *mask;
        Document        *document;
}

---

Werden immer Mask und Document sein. ich kann zwar Objekte abgeleiteter Klasse hinnein casten, doch am Ende werden es immer die Basisklassen Mask und Document bleiben. Und da liegt mein Fehler, ich brauchte es genau anders herrum.
Mit new kann ich Ihnen einen neuen Typ zuweisen, doch stecke ich dann in dem Problem des Signals dessen Herrausgeber ich ja noch löschen muss. welches ich mit deleteLater() versuchen werde zu lösen. Und nach meiner ersten Testung auch funktioniert hat. :)

Code:

---

void MainWidget::setDocumentClass( ){
qDebug()<<"void MainWidget::setDocumentClass()";

        qDebug()<<"doctype=" << doctype;
       
        qDebug()<<"document="<<document<<"|\tmask="<<mask;
        switch(doctype){
/*         
                case ANIMAL:
                      qDebug()<<"\ndocument = new AnimalDocument;";
                              document = (AnimalDocument) new AnimalDocument;
                      if(!document->start( absolute_document_path ))
                                doctype = EMPTY;
                      else
                                mask->fill(document->getFileContent(), document->getFileInfo());
                      break;
*/
                case BOOK:
                      qDebug()<<"\nBookDocument";
                     
                      disconnect(mask, 0, 0, 0);
                      mask->deleteLater();
                      mask = new BookMask;
                     
                      disconnect(document, 0, 0, 0);
                      document->deleteLater();
                      document = new BookDocument;

                      break;
                     
                case RECIPE:
                      qDebug()<<"\n\n\nRecipeDocument";

                      disconnect(mask, 0, 0, 0);
                      mask->deleteLater();
                      mask = new RecipeMask;
                     
                      disconnect(document, 0, 0, 0);
                      document->deleteLater();
                      document = new RecipeDocument;

                      break;
                     
                default:
                      qDebug()<<"\n\nNo DocType found!";
                      qDebug()<<"Document";
                      mask    = mask;
                      document = document;
                     
                      break;
        }
               
        connect( mask, SIGNAL(SigDocTypeChanged( int )),
                this, SLOT(DocumentTypeChanged( int )) );
       
        connect( document, SIGNAL(saved( QString )),
                this, SLOT(loadDocument( QString )) );

        connect( mask, SIGNAL(SigSave()),
                this, SLOT(saveDocument()));
       
        qDebug()<<"document="<<document<<"|\tmask="<<mask;
}

---

Zitat:

---

Zitat von dml

Es sieht ganz stark danach aus, das dessen Typ dann Mask ist.

---

Der Typ der Variable "mask" ist Mask* (also Pointer auf Mask). Das Objekt hinter dem Pointer ist nach wie vor vom Typ BookMask.

Zitat:

---

Zitat von dml

Werden immer Mask und Document sein. ich kann zwar Objekte abgeleiteter Klasse hinnein casten, doch am Ende werden es immer die Basisklassen Mask und Document bleiben. Und da liegt mein Fehler, ich brauchte es genau anders herrum.

---

Ansich wird Polymorphie so angewandt, dass man möglichst wenig oft wissen muss, mit welchen Subtyp man gerade zu tun hat.

Wie sieht denn ein Beispiel für eine Fallunterscheidung bei dir aus, abgesehen von der Erzeugung der Instanzen?

Zitat:

---

Zitat von dml

Mit new kann ich Ihnen einen neuen Typ zuweisen, doch stecke ich dann in dem Problem des Signals dessen Herrausgeber ich ja noch löschen muss. welches ich mit deleteLater() versuchen werde zu lösen. Und nach meiner ersten Testung auch funktioniert hat. :)

---

Ja, deleteLater() ist dafür bestens geeignet. Das echte Löschen des Objekts wird über die Eventloop "verzögert" ausgeführt.


Übrigens, das disconnect() kannst du auch kürzer so schreiben

Code:

---

mask->disconnect();

---

Ciao,
_

Zitat:

---

Das Objekt hinter dem Pointer ist nach wie vor vom Typ BookMask.

---

Ja aber ich hatte dabei das gleiche Objekt verwendet, weshalb es nur Mask bzw. Document sein konnte.
Ein Beispiel in meiner Applikation ist ganz einfach:

Code:

---

void MainWidget::setDocumentClass( ){
qDebug()<<"void MainWidget::setDocumentClass()";

        qDebug()<<"doctype=" << doctype;
       
        qDebug()<<"document="<<document<<"|\tmask="<<mask;
        switch(doctype){
/*         
                case ANIMAL:
                      qDebug()<<"\ndocument = new AnimalDocument;";
                              document = (AnimalDocument) new AnimalDocument;
                      if(!document->start( absolute_document_path ))
                                doctype = EMPTY;
                      else
                                mask->fill(document->getFileContent(), document->getFileInfo());
                      break;
*/
                case BOOK:
                      qDebug()<<"\nBookDocument";
                      mask    = (BookMask*) mask;
                      document = (BookDocument*) document;

                      break;
                     
                case RECIPE:
                      qDebug()<<"\nRecipeDocument";
                      mask    = (RecipeMask*) mask;
                      document = (RecipeDocument*) document;
                     
                      break;
                     
                default:
                      qDebug()<<"\n\nNo DocType found!";
                      qDebug()<<"Document";
                      mask    = mask;
                      document = document;
                     
                      break;
        }
               
       
        qDebug()<<"document="<<document<<"|\tmask="<<mask;
}

---

anwenden, und man erkennt an qDebug() das der Typ gleich geblieben ist. Wenn man in der Applikation auf Dokument->Bearbeiten drückt, müssten auch nur die Elemente der Basisklasse Mask und nicht der abgeleiteten Klasse BookMask, RecipeMask angezeigit werden.

Ein Risiko bleibt aber noch, da die Verbindung während des disconnect() Befehles noch aktiv ist. Ich glaube das es funktioniert Da es sonst noch die Methode diconnectLater() geben würde.

Das ist in dem Fall kein Beispiel das ich meinte, hier wird nichts mit den Objekten gemacht.

Ich meinte ein Beispiel, wo du je nach Typ das Mask oder Document Objekt anders behandelst.
D.h. entweder anderen Code durchläufst oder Methoden der Objekte aufrufst, die nicht in der Basisklasse deklariert sind.

Ciao,
_

Code:

---

void MainWidget::loadDocument( QString absolute_document_path ){

        ...
        setDocumentClass();
        ...
                mask->fill(document->getFileContent(), document->getFileInfo());
        ...
}

void RecipeMask::fill( QString file_content, QFileInfo fileinfo ){
        ...
        //////////////////////
        // get preparation  //
        //////////////////////
        ...
                this->preparation_te->setText( exp.cap(1) );
        ...
}

---

Preparation ist nur in der abgeleiteten Klasse RecipeMask enthalten. Vom Methodenaufruf unterscheidet sich der Code nicht.

Natürlich kann man jetzt sagen, das man eine SuperMaske hätte erstellen können und je nach Anwendungsfall die Members darstellen und auswerten.

Code:

---

class BookMask: public Mask{
        ... 
        QTextEdit              *description_te;
        ...
}

class RecipeMask: public Mask{
        ... 
        QTextEdit              *description_te;
        ...
}

---

Doch finde ich es so viel übersichtlicher.

Aber die Methode fill() ist doch bereits in Mask deklariert (virtual) und wird von den Subklassen nur anders implementiert.

D.h. der Aufruf in MainWidget::loadDocument() wird bereits durch den Polymorphismus auf den jeweiligen Code umgeleitet.

Code:

---

Mask *mask = new RecipeMask;

mask->fill(...); // Aufruf von RecipeMask::fill();

mask = new BookMask;

mask->fill(...); // Aufruf von BookMask::fill();

---

Für den Aufruf von fill() ist es bedeutungslos auf welche Subklasse mask gerade veweißt, zur Laufzeit wird die Implementierung der jeweiligen Subklasse ausgeführt.

Wenn wir diesen Codeschnippsel kurz umschreiben

Code:

---

switch (doctype) {
    case RECIPE:
        mask = new RecipeMask;
        break;

    case BOOK:
        mask = new BookMask;
        break;
}

mask->fill(...);

---

dann ist im Falle von doctype == RECIPE in der letzten Zeile ein Aufruf von RecipeMask::fill(), im Falle von doctype == BOOK ein Aufruf von BookMask::fill(), usw.

Ciao,
_

In der Hoffnung Dich nicht inzwischen zu Nerven.
Du hattest Recht der QDebug Befehl gibt Mask( , name="RecipeMask") herraus, ist also weiterhin vom Typ Mask.
Das bringt mich zu dem Problem:

Code:

---

Document::saveDocument( Mask *mask );
RecipeDocument::saveDocument( RecipeMask *rmask );

---

aufgrund seines Parameters kann ich die Methode nicht als virtual deklarieren und so wird Document::saveDocument ausgeführt. Hast Du dafür vielleicht einen kleinen Tip für mich? Oder sollte ich dann doch besser eine große Maske erstellen die kleine Probleme mehr bereitet?
Bzw: Wenn ich Maske wieder in Document einfüge muss ich eine Menge leerer virtueller Methoden in der Basisklasse schreiben, damit der Compiler alle Methoden der abgeleiteten Klassen akzeptiert.

Zitat:

---

Zitat von dml

In der Hoffnung Dich nicht inzwischen zu Nerven.

---

Nope, find ich cool :)

Zitat:

---

Zitat von dml

Das bringt mich zu dem Problem:

Code:

---

Document::saveDocument( Mask *mask );
RecipeDocument::saveDocument( RecipeMask *rmask );

---

---

Am ehesten so

Code:

---

class Document
{
public:
    virtual void saveDocument( Mask *mask ) = 0;
};

---

Code:

---

class RecipeDocument : public Document
{
public:
    void saveDocument( Mask *mask ) = 0;
};

void RecipeDocument::saveDocument( Mask *mask )
{
    RecipeMask *ourMask = dynamic_cast<RecipeMask*>( mask );
    if ( ourMask == 0 ) {
        // mask not of our type, log error or tell user, etc.
        return;
    }

    // use ourMask
}

---

Wenn Mask direkt oder indirekt von QQbject abgeleitet ist, kann man statt dynamic_cast auch qobject_cast benutzen.

Zitat:

---

Zitat von dml

Bzw: Wenn ich Maske wieder in Document einfüge muss ich eine Menge leerer virtueller Methoden in der Basisklasse schreiben, damit der Compiler alle Methoden der abgeleiteten Klassen akzeptiert.

---

Ich kann mich jetzt nicht mehr so gut an den vollständigen Code erinnern, aber wenn Document die jeweiligen Daten enthält bzw bearbeitet und Mask die entsprechende GUI ist, könnte es eventuell andersrum besser gehen.

D.h. wenn die jeweilige Mask sich ein entsprechendes Document erzeugt und hält.

Generell müssen Methoden in der Basisklasse nicht "leer" implementiert werden, wenn sie von allen Subklassen ohnehin verschieden implementiert werden müssen. In diesen Fällen reicht es, die Methoden als "pure virtual" zu deklarieren, also virtual vorne und = 0 hinten.

Das Ziel dabei ist, dass im Rest des Programms möglichst wenig, idealweise gar nicht, zwischen den Subklassen unterschieden werden muss, sondern das durch den Mechanismus des Methodenüberschreibens intern gehandhabt wird,

Ciao,
_

Ich kann nur sagen Perfekt, vielen Dank! Jetzt wo es da steht ist es so logisch, doch bin ich nicht darauf gekommen. Ich hätte leere virutal methode() in die Basisklasse geschrieben, was nicht dem Sinn der Ableitung entstprochen hätte.
= 0; funktioniert hierbei nicht, denn die Methode der Basisklasse garantiert, das Objekte (Name, Buchtitlel, Kategorien,...) die für das Funktionieren des Documentes unabdingbar sind, enthalten sind.