Abstrakte Klasse

[pumuckl]

martin_salo schrieb:

~Fahrzeug() { //sollte wohl Fahhrad heissen
 :~Fahrzeug(); // Objekte der Basisklasse zerstören.
 delete abc;   
}

Den Basisklassen Destruktor brauchst du meines Wissens nicht aufzurufen, da die Basisklassen bestandteile immer zerstoert werden, und zwar nach Ausfuehrung des abgeleiteten Destruktors. damit wird auch sichergestellt, dass etwaige abhaengige Aktionen nicht auf ein schon zerstoertes Objekt zugreifen.

Bisher erkenne ich allerdings nicht, wie du in deiner Hauptklasse mit den Fahrzeugen umgehen willst. Wenn du schon bei SetFortbewegungsmittel zwischen den verschiedenen Typen unterscheidest, musst du das vermutlich auch bei der Verwendung in der Hauptklasse, und das widerum klingt nach unmengen von if-else kaskaden bzw. switch-cases

[muffmolch]

~Fahrzeug() { 
 :~Fahrzeug(); // Objekte der Basisklasse zerstören. 
 delete abc; 
}

funzt das übehaupt? ist das std-konform? kommt es da zur laufzeit nicht zu einem bösen absturz??
und überhaupt was soll das bringen???

allg.:

class Base{ 
public:
Base() {std::cout<<"Base"<<std::endl; }
virtual ~Base(){ std::cout<<"~Base"<<std::endl;} 
};

class D1 : public Base { 
D1 () {std::cout<<"D1 "<<std::endl; }
~D1(){ std::cout<<"~D1 "<<std::endl;}
 };

class D2 : public D1 { 
D2 () {std::cout<<"D2 "<<std::endl; }
~D2(){ std::cout<<"~D2 "<<std::endl;}  
};

int main()
{
  D2 d1;
std::cout<<std::endl;
}

--> output

Base
D1
D2

~D2
~D1
~Base

[martin_salo]

Zuerst war nur Auto da. Mein Aufgabe war das Programm auf Fahrrad zu erweitern. Das ist mir jetzt gelungen, ohne das ich den Code duplizieren musste (doppelter code in Fahrzeug ausgelagert). Mit den if Statements hast Du recht. Ich glaube aber nicht das ich da herum komme. Das Programm muß sich bei einem Fahrrad etwas anders verhalten.

Danke für den Tip mit dem Dekonstruktor.

[CStoll]

Da solltest du versuchen, dieses unterschiedliche Verhalten IN den Klassen zu verpacken - in Form von virtuellen Methoden (siehe mein Beispiel oben - sowohl auto als auch fahrrad haben eine Methode fahre(), aber jede Klasse hat eine andere Art, wie sie fahren will).

[martin_salo]

@muffmolch:
Ich wollte sicherstellen das der Dekonstruktor aufgerufen wird. Wenn er zweimal aufgerufen wird wird ein Objekt zweimal deleted. Ich habe den Aufruf aber mitlerweile entfernt.

[pumuckl]

Sei nicht schuechtern, zeig doch einfach dein Programm und was es macht (evtl gekuerzt aufs wesentliche)

martin_salo schrieb:

@muffmolch:
Ich wollte sicherstellen das der Dekonstruktor aufgerufen wird. Wenn er zweimal aufgerufen wird wird ein Objekt zweimal deleted.

Wenn du Glueck hast passiert nicht viel, aber wenn du im geerbten Destructor z.B. deletes stehen hast, wird beim zweiten mal delete aufgerufen mit einem Argument, das irgendwo aus dem bereits "zerstoerten" gelesen wird.

And we enter the dark shady realms of undefined behavior.

[martin_salo]

@CStoll: Meine Klassen stellen nur Datenobjekte dar die gefüllt werden. Sie haben nur ein Methode IsValid() die sagt ob das Klassenobjekt mit einem konsitentem Datensatz gefüllt wurde. Alle Datenklasse werden dann einer Klasse zur Verarbeitung gegeben. Würde ich alle Datenklassen mit der Verarbeitungsklasse zusammenlegen hätte ich eine Menge (für mich zu viele) Methoden.

Es widerspricht vielleicht etwas dem OO Ansatz Daten und Funktionen zusammenzufügen, für mich ist es aber schön übersichtlich.

class Fortbewegung {
SetFahrzeug(Auto A);
SetFahrzeug(Fahrrad F);
AddInsasse(Person P);

DoFortbewegung() throw (UngueltigeAngaben);

IsValid() throw (UngueltigeAngaben);
}

Den Code kann ich nicht zeigen. Nur soviel es geht um ein Dateiformat in XML wo unterschiedliche Objekte abgespeichert werden. class Fortbewegung ist in Wirklichkeit class DateiformatXYZ.

[CStoll]

martin_salo schrieb:

Es widerspricht vielleicht etwas dem OO Ansatz Daten und Funktionen zusammenzufügen, für mich ist es aber schön übersichtlich.

Nein, es widerspricht dem OOP-Ansatz, Daten und Methoden zu trennen. Da kannst du gleich auf Objektorientierung verzichten. Und glaub mir, spätestens wenn du weitere Fahrzeugtypen dazubekommst, bleibt von der Übersichtlichkeit nichts mehr übrig.

[martin_salo]

@CStoll: Hatte mich da verschrieben. Bei OO werden natürlich Daten und Funktionen zusammengelegt.

Was ich ändern könnte wäre bei Fahrzeug ein Unterobjekt mit Namen Spezialisierung zu setzen. Spezialisierung wäre dann ein Objekt vom Typ Auto oder Fahrrad. Da müsste ich den Anwendern meines Dateiformates aber wieder eine Menge beibringen. Sie müssten Objekte hierarchisch zusammenbauen. Auto in Fahrzeug packen und Fahrzeug dann in Dateiformat.
Alles hat seine Vor- und Nachteile.

[CStoll]

Und geholfen hast du mit dem Design niemandem - du hast nur deine Fallunterscheidungen von der Klasse Dateiformat in die Klass Fahrzeug verlagert.

Nochmal: Wenn du objektorientiert arbeiten willst, dann bitte richtig - die Klasse Fahrzeug definiert eine feste Schnittstelle von Operationen (für dich von mir aus 'lies_ein()' und 'gib_aus()' als abstrakte Methoden) und die abgeleiteten Klassen überschreiben diese Methoden und bauen dort ihre eigene Art ein, sich einzulesen bzw. auszugeben.

[martin_salo]

@CStoll: Hm. Da Auto und Fahrrad in Wirklichkeit XML Objekte sind müsste ich jedem Objekt die Methoden lies_ein/WriteToXML und gib_aus/ReadFromXml geben. Und die XmlFile Klasse würde dann jedes der Objekte über die Methoden in das File schreiben oder davon lesen. Ok

[martin_salo]

Eine kleine Nachfrage: Was macht das public?

class XMLFormat : public BaseFormat {...}

Es funktioniert auch wenn ich es weglasse...

[CStoll]

'public' besagt, daß du öffentlich von der angegebenen Klasse ableitest - wenn du das weglässt, nimmt der Compiler 'private' an und du kannst von außen nicht mehr auf BaseFormat-Methoden zugreifen.

[martin_salo]

Danke

[Simon2]

Hi,

also ich habe den Eindruck, dass das Ganze nichts mit "Fahrzeug, Auto, Fahrrad, ..." zu tun hat, sondern es eher mit "XMLDataObject". Wenn "Fahrzeug/Auto/Fahrrad" nichts mit ihren physischen Pendants gemein haben (und über "Fahrzeug" weiß man nichts außer, dass es fahren kann), solltest Du auch andere Klassen wählen.
"write()" und "read()" sind jedenfalls keine fahrzeugtypischen Eigenschaften....

Gruß,

Simon2.

[martin_salo]

Fahrzeug und Auto sind doch nur die Beispiel aus den Büchern. Bei mir sind das dann XMLFileMyCompanyFormat und dann die Datenobjekte ApplicationABC...

[Simon2]

OK, war mir nicht klar ... ich sah halt nur so Aussagen wie "neee 'fahren()' hat die nicht" und so...

Gruß,

Simon2.