nehmen wir an ich möchte einer Methode ein Objekt entweder vom Typ Fahrrad oder Auto übergeben. Dann könnte ich doch die Basisklassen Fahrzeug erfinden, davon Auto und Fahrrad ableiten. Der Methode würde ich dann ein Fahrzeug übergeben. Mein Problem: Wie kriege ich es hin das nur Auto oder Fahrrad übergeben wird -> Es darf auf keinen Fall ein Fahrzeug übergeben werden. Im Internet steht ich muß in Fahrzeug eine Mathode als Pure Virtual definieren. Mir fällt aber keine Methode in Fahrzeug ein die von Auto/Fahrrad überschrieben werden. Ich könnte jetzt eine besthende Methode in Fahrzeug pure virtual machen und dann aus Fahrzeug den Methodenkörper nach Fahrrad/Auto den kopieren... wäre aber ein workaround.

Gibt es vielleicht ein einfachere Methode um eine Klasse in C++ abstract zu machen?

Vielen Dank

Martin

double getMaxVelocity()=0;

oder

Fahrzeug* clone()=0;

oder

std::string getName()=0;

und wenn du ansonsten keine gemeinsame methode kennst, die beide abgeleiteten klassen benötigen, dann ist das klassendesgin ohnehin fragwürdig

Im allgemeinen Fall sollte das Design etwa so aussehen:

class fahrzeug
{
public:
  virtual void fahre(...) = 0 ;// das Fahrzeug kann fahren - aber erst konkrete Klassen wissen, wie
  virtual ~fahrzeug();//Dtor
  ...
};

class fahrrad : public fahrzeug
{
  virtual void fahre(...)
  {
    steig_auf();
    ...tret-tret-keuch-keuch...
  }
  ...
};

class auto : public fahrzeug
{
  virtual void fahre(...)
  {
    starte_motor();
    gibt_gas();
    ...
  }
  ...
};

(und schon hast du etwas, was du pur virtuell anlegen kannst

PS: Und wenn alle Stricke reißen, kannst du immer noch einen pur virtuellen Destruktor definieren.

Und einen Funktionsrumpf zu kopieren ist verdoppeln von Informationen, was bei Veraenderungen stark fehleranfaellig ist. Sinvoller ist es, in den abgeleiteten Funktionen die geerbte aufzurufen. Zusammen sieht das dann so aus:

class Fahrzeug
{
public:
  /*pure*/ virtual ~Fahrzeug() = 0 {};
  /*pure*/ virtual void Fahre() = 0 
    { cout << "brrrrmmm...." << endl; }
}

class Auto : public Fahrzeug
{
  ~Auto() {}; //virtual kann man weglassen, wenns in der Elternklasse deklariert wurde...
  virtual void Fahre() //muss man aber nicht
    { Fahrzeug::Fahre(); } //geerbte Methode aufrufen
}

Kleine Merkregel fuer Klassenhierarchien die im Zusammenhang mit Polymorphie verwendet werden sollen:
normaler Destruktor: man sollte nicht ableiten.
virtual Destruktor: man darf ableiten.
pure virtual Destruktor: man MUSS ableiten.

Zu dem Design: Da könntet Ihr recht haben. Denn meine nächste Frage wäre wie ich in der Methode die ein Fahrzeug bekommt herausbekommen würde was übergeben worden ist.

Methoden der Klasse Fahrzeug:
SetSpeed()
GetSpeed()
SetPrice()
GetPrice()
...

Methoden der Klasse Fahrrad:
SetLenkradGepäckträger()
GetLenkradGepäckträger()

Methoden der Klasse Auto:
SetAnhängerkupplung()
GetAnhängerkupplung()

In den Methoden der Klasse Fahrzeug steckt eine Menge Code zur Überprüfung drin. Deshalb soll dieser nur einmal auftreten. In meiner Hauptapplikation muß aber ein komplettes Fahrzeug da sein. Fahrrad oder Auto. Wie würde ich nun herausbekommen was mir übergeben wurde?

In den Methoden der Klasse Fahrzeug steckt eine Menge Code zur Überprüfung drin. Deshalb soll dieser nur einmal auftreten. In meiner Hauptapplikation muß aber ein komplettes Fahrzeug da sein. Fahrrad oder Auto. Wie würde ich nun herausbekommen was mir übergeben wurde?

Ohne typecasts oder typeid (die meist unschoen sind) garnicht. Normalerweise solltest du auch nicht die Typinformation verlieren, wenn du wissen musst, womit du nun genau arbeitest. Lediglich Funktionen, denen egal ist, ob sie nun mit einem Fahrrad oder einem Auto arbeiten, koennen einfach ein Fahrzeug akzeptieren.

void RenoviereAnhaengerkupplung(Auto& a) 
{ 
  // Es waere sinnlos, das bei einem Fahrzeug zu machen, weil nur Autos sowas haben
}

void KLemmeAufGepaecktraeger(Fahrrad& f, Gepaeckstueck& g) {
  // geht bei Fahrzeugen allgemein nicht, nur bei Fahrraedern
}

void Verkaufe(Fahrzeug& f) 
{ 
  f.SetPrice(); //geht fuer alle fahrzeuge...
}

Nur wenn du beispielsweise einen Haufen fahrzeuge in einen Container geworfen hast und sie hinterher auseinanderosrtieren musst, ist es wichtig, den Typ wieder rauszufinden.

Ich mache zwei Methoden in meinem Hauptobjekt:
Anstatt:
SetFortbewegungsmittel(Fahrzeug &Obj);
Mache ich:
SetFortbewegungsmittel(Auto &Obj);
SetFortbewegungsmittel(Fahrrad &Obj);

Und Auto/Fahrrad leite ich wie bisher von Fahrzeug ab. In SetFortbewegungsmittel() kann ich dann kein Fahrzeug mehr übergeben...

class Fahrzeug {
SetSpeed() {// Mit Code}
GetSpeed() {// Mit Code}
SetPrice() {// Mit Code}
GetPrice() {// Mit Code}
...
virtual ~Fahrzeug()=0; // Damit Fahrzeug nicht instanziiert werden kann.
}

// Rumpf zum Dekonstruktor:
Fahrzeug:~Fahrzeug() { // Dieser Dekonstruktor wird aufgerufen bei der Zerstörung eines Autos/Fahrrads.
delete obj1;
delete obj2;
...
}

Die Klassen Fahrrad und Auto haben alle Getter und Setter von Fahrzeug und zusätzlich ein paar Extra Methoden:

Beispielsweise Methoden der Klasse Fahrrad:

class Fahrrad : public Fahrzeug {
SetLenkradGepäckträger()  {// Mit Code}
GetLenkradGepäckträger()  {// Mit Code}

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

In meiner Hauptklasse habe ich dann zwei Methoden:

SetFortbewegungsmittel(Fahrrad &F) {
}

SetFortbewegungsmittel(Auto &A) {
}

Ich muß eh beide Objekte unterschiedlich behandeln. Wenn jetzt noch ein Motorrad hinzukommt hat es auch extra Daten Getter/Setter, so dass ich in meiner Hauptklasse sowieso eine neue Methode machen muß.

~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

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

Danke für den Tip mit dem Dekonstruktor.

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.

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.

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.

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.

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.

class XMLFormat : public BaseFormat {...}

Es funktioniert auch wenn ich es weglasse...