Abstrakte Klasse
-
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.
-
@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.
-
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.
-
@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
-
Eine kleine Nachfrage: Was macht das public?
class XMLFormat : public BaseFormat {...}Es funktioniert auch wenn ich es weglasse...
-
'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.
-
Danke
-
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.
-
Fahrzeug und Auto sind doch nur die Beispiel aus den Büchern. Bei mir sind das dann XMLFileMyCompanyFormat und dann die Datenobjekte ApplicationABC...
-
OK, war mir nicht klar ... ich sah halt nur so Aussagen wie "neee 'fahren()' hat die nicht" und so...
Gruß,
Simon2.