das ist mein erstes Posting, also bitte Nachsicht mit mir, falls ich irgendwelche alteingesessenen Gebräuche verletzte. Bemühe mich jedenfalls nicht aufzufallen.

Zu den Fragen: ich beschäftige mich erst kurz mit C++, aber jetzt ist folgende Ungereimtheit aufgetaucht.

1. Vererbung wird angepriesen mit der Möglichkeit in einer Basisklasse Grundeigentschaften/-methoden zu anzulegen, die dann die abgeleitete Klasse erbt und verwenden kann. Zusätzlich besteht dann die Möglichkeit in der abgeleiteten Klasse neue Methoden/Eigenschaften zu definieren, um die Funktionalität der Basisklasse speziellen Anforderungen gemäß zu erweiteren.
   OK! Verstanden.

2. Wenn ich jedoch über eine Base-Class-Pointer auf die abgeleitete Klasse zugreifen will, so funktioniert das nicht. Ich kann mit einem solchen Pointer nicht auf eine Methode zugreifen (bzw. der Compiler protestiert ), die ich einer abgeleiteten Klasse zum 1. Mal deklariert/definiert habe. Inzwischen weiß ich auch warum: der Zeigertyp (vom Typ "Basisklasse") bestimmt welche Methoden ansprechbar sind (eben nur jene in der "Basisklasse"), und nicht der Typ des Objektes, auf das gezeigt wird. Das heißt, grob gesagt, alle Methoden die ich über einen Basisklassen-Zeiger ansprechen will, müssen auch in der Basisklasse vorhanden (definiert) sein.
   Ok. Inzwischen auch verstanden.

Was ich allerdings nicht verstehe, welchen Sinn dann dieses Konzept der "Erweiterung der Funktionalität in den abgeleiteten Klassen" haben soll, wenn ich - wie unter 2) - beschrieben alle Funktionen, die in irgendwelchen abgeleiteten Klassen vorkommen, auch in der Basisklasse definieren MUSS, damit's funktioniert. Was ist wenn ich eine Methode in der Basisklasse gar nicht sinnvoll defnieren kann (und sie dementsprechend dort auch nicht brauche), weil irgendwelche Variablen die zur Methodenausführung nötig sind, erst in der abgeleiteten Klasse vorliegen??? Ich habe das so gelöst, indem ich die Methode einfach mit leerem {} Rumpf definiert habe. Aber ist das guter Stil??? Man könnte eine "pure virtual function" draus machen. Wenn ich das aber nicht will, weil die Basisklasse nicht abstrakt sein soll? Außerdem: eine "pure virtual function" müßte dann in allen abgeleiteten Klassen implementiert werden - was, wenn ich diese Funktion aber nur in einer meiner vielen abgeleiteten Klassen tatsächlich brauchen kann?
Oder überhaupt auf das Ansprechen über einen Basisklassenzeiger verzichten??

Ich hoffe ihr habt ein paar Antworten für mich
Danke

Die Basisklasse definiert die grösste Gemeinsamkeit der Schnittstellen.
Wenn du eine Funktion hast, die nicht in allen Subklassen sinnvoll ist, dann gehört sie nicht in die Basisklasse.
Die Möglichkeit leere Funktionen zu implementieren hast du, aber ob dies sinnvoll ist, ist die Frage. Du solltest dann dein Design überdenken.

Beispiel:
Fahrzeuge
-> Fahrrad
-> Auto

Ein Auto braucht natürlich einen Anlasser, das Fahrrad nicht. Aber wenn du in Fahrzeuge eine motor_anlassen(){} definierst, ist das verwirrend, den Fahrräder haben keine Motoren.
Wie machst du das? Du machst eine virtuelle Funktion in Fahrzeug losfahren(){}. In Fahrrad machst du dann weitere Funktionen aufsteigen(), antreten(), die von losfahren() aufgerufen werden, in Auto rufst du Funktionen wie einsteigen(), anschnallen(), motor_anlassen(), gang_einlegen() und gas_geben() auf. (Überspitzes Beispiel, aber ich denke es ist klar was ich meine)
Dann kannst du für alle Fahrzeuge losfahren() aufrufen, und du erhältst jeweils das angemessene Verhalten.

Sonst beschreib mal deinen konkreten Fall, vielleicht kann man dir dann weiterhelfen.

Zum beispiel hast du ein kleines nettes spielchen, wo es menschen, hunde, bäume, autos, gebäude und anderes lustiges zeug gibt.

Nun hast du da so eine welt, und fängst an, sie mit objekten zu füllen, die möglichst sinnvoll miteinander interagieren sollen.

Jetzt stellst du fest, dass alle objekte im spiel gewisse gemeinsamkeiten haben: zB sind sie sichtbar. Nun wäre es doof, die funktion, die für das zeichnen verantwortlich sind, bei jedem einzelnen hund und jedem einzelnen stein neuzuimplementieren.

Lösung: Basisklasse. Sagen wir mal "Sichtbar", mit der methode zeichnen().
Dann überlegst du weiter, und stellst fest, dass du zwar alle objekte siehst, aber nicht alle dich dran hindern, einfach hindurchzulaufen (rauchwolken, staub usw.) Man braucht also objekte, die miteinander kollidieren können, und welche, die es nicht können.

Die kollisionsabfrage will man natürlich nicht für 6784123 verschiedene solide objekte schreiben, deswegen leitet man von der klasse "Sichtbar" die klasse "Solid" ab.

Dann schaut man sich die objekte noch genauer an, und stellt fest, dass sich manche objekte bewegen und manche nicht: "Beweglich" klasse wird von "Solid" abgeleitet. Dann weiter dasselbe spielchen mit "Lebewesen" "Fahrzeug" usw usw usw.

Und letztendlich kanns du objekte diesen ganzen klassen zuordnen:
Wolken: sind nur sichtbar, und brauchen keine weiteren funktionen
Gebäude und Bäume: sind solide objekte. Man kann dagegenrennen und sich wehtun.
Autos: sind fahrzeuge. Die sind beweglich und lassen sich steuern.
Menschen und Hunde: sind lebewesen, auch beweglich wie fahrzeuge, nur deutlich empfindlicher gegen schlechtes wetter.

Das tolle an polymorphie ist, dass du jetzt jedes dieser recht unterschiedlicher objekte einheitlich ansprechen kannst, und die funktion zeichnen() aufrufen kannst.

Andererseits ist es nicht möglich, für all diese objekte die funktion fahren() aufzurufen, weil die ja für gebäude und bäume wenig sinn macht (du kannst die funktion nicht aufrufen, weil du sie nicht brauchst ). Die kannst du dann aber für alle fahrzeuge aufrufen, und musst dir keine sorgen darum machen, dass jemand versucht, diese undefinierte funktion für einen stein aufzurufen.

Deswegen darf man in der basisklasse auf keinen fall irgendwelche funktionen deklarieren, die nicht für alle abgeleiteten klassen sinn machen,

was, wenn ich diese Funktion aber nur in einer meiner vielen abgeleiteten Klassen tatsächlich brauchen kann?

somit hat so eine frage keinen sinn, weil eine basisklasse ja eben dazu da ist, um ein einheitliches interface für alle abgeleiteten klassen zu bieten.

ist n bisschen viel geworden...
naja, bei mir hat es mit diesem modell am besten geklappt, sich das alles bildlich vorzustellen, hoffentlich hilfts was...

edit: meine fresse, bin ich lahm :p

... (das heißt die Basisklasse bestimmt, welche Methoden es gibt (darum kommst du beim Polymorphismus nicht drumherum) und die konkrete abgeleitete Klasse entscheidet, was diese Methoden machen sollen).

Schluck, das meinte ich.
Am Beispiel von THx:

#include <iostream>
using namespace std;

class Fahrzeuge
{
    protected:
        int raeder;  

    public:
        Fahrzeuge(int rae):
            raeder(rae)
            {}

        virtual void displayRaeder() const  //kommt in allen Klassen vor
            {cout <<"Fahrzeug/Anzahl: " << raeder <<\n";}
};

class Fahrrad:public Fahrzeuge
{
    public:
        Fahrrad(int rae):
            Fahrzeuge(rae)
            {}

        virtual void displayRaeder() const
            {cout << "Fahrrad/Anzahl: " << raeder <<"\n";}

        virtual void makeNoise() const   //Funktion, die allein(!) Fahrrad haben soll
            {cout << "Klingeling...\n";}
};
int main()
{

    Fahrrad rad(2);
    rad.makeNoise();
    //1. Möglichkeit funktioniert wie zu erwarten problemlos

    Fahrzeuge *obj=new Fahrrad(2);
    obj->displayRaeder();  //funktioniert
    obj->makeNoise();  //funktioniert nicht, COMPILER-FEHLER
    return 0;
}

Wie gesagt, ich weiß warum /obj->makeNoise();/ nicht funktioniert, weil der Pointer vom Typ "Fahrzeuge" ist, und allein die Methoden der Fahrzeuge-Klasse angesprochen werden können. Damit es funktioniert, müßte ich die makeNoise()-Methode auch in der Basisklasse definieren, dann wär' sie ja wieder eine Methode der Basisklasse. Aber hier liegt mein Problem. Wenn mein Fahrzeuge-Klasse gar keinen Lärm machen soll und dementsprechend die makeNoise()-Methode dort unbrauchbar ist - was sollte ich als Rumpf ein solchen Methode angeben, außer eben einen leeren??. Wenn ich sie rein virtuell mache: virtual void makeNoise()=0, ok, aber was wenn ich ein Fahrzeuge-Objekt brauche? Oder nicht alle abgeleiteten Klassen die makeNoise() automtisch erben sollen (wie's ja bei rein virtuellen Funktionen der Fall ist, wenn ich das recht verstanden habe).

Darum auch die Überschrift. Der Polymorphismus zwingt mich hier Methoden in der Basisklasse zu "sammeln", die aber speziell auf die Anfordernisse ihrer abgeleiteten Klassen zugeschnitten sind und gar nicht in die Basisklasse passen!

Wie kann die blöde makeNoise() da irgendwie sinnvoll reinbringen, und trotzdem "polymorphisch" zu Werke gehen??

Danke

Da must du wohl an deinem Klassenkonzept selber feilen. Deine Darstellung der Polymorphie ist an sich schon korrekt.
Sollte eine Klasse nicht mit den Methoden der Basisklasse zusammenpassen, stellt sich erstmal die Frage ob diese Klasse überhaupt von der Basisklasse abgeleitet werden soll. Die zweite Frage ist ob zumindestens für Einzelfälle ein entsprechender Downcast sinnvoll ist, um auf spezielle Funktionen implementierender Klassenstufen zuzugreifen. Meistens lassen sich Probleme nur durch ein anderes, meistens komplexeres Klassendesign lösen.

In deinem Konkreten Beispiel wurde ich mich fragen ob wirklich ein Fahrzeug von sich aus Krach macht. Eher nicht, sondern erst wenn es gefahren wird. Deine Basisklasse sollte also anstelle von makeNoise() eine Methode virtuelle Methode drive() haben. Nun kannst du Fahrrad normal implementieren, aber bei Auto in der Implementation der Methode drive() noch die nur in Auto enthaltene Methode makeNoise() aufrufen.

Letzendlich wirst du beim umsetzen solcher realler, weitläufgen Probleme immer an Grenzen stoßen. Jedes Modell der Wirklichkeit muß zwangsläufig nur einen Bruchteil derselben zufrieden geben.

bis bald
akari

Polyphormismus hat den Zweck, dass du unterschiedliche Objekte gleich behandeln kannst.

vector<Fahrzeug*> vfz;
vfz.push_back(new Fahrrad);
vfz.push_back(new Auto);
for(size_t i=0;i<vfz.size();++i)
    vfz[i]->fahren();   //Alle Fahrzeuge können fahren

Wenn du nun etwas hast, das nur bestimmte abgeleitete Klassen können (wie eben z.B Motor anlassen) dann willst du die ja dann, wann du diese Methode brauchst, gar nicht gleich behandeln. Du könntest ja auch in deiner Autoklasse eine Methode tanken haben, die von einer andern Klasse Tankstelle aufgerufen wird. Aber du willst an Tankstelle ja sicher keine Fahrräder übergeben, also übergibst du ihr auch nur Autos und keine Fahrzeuge (da die Tankstelle ja nicht mit allen Fahrzeugen etwas anfangen kann)

Des weiteren, wie thx schon sagte, kann es ja sein, dass du die neuen Methoden nur in der Basisklasse selbst aufrufst (sie alo private machst)

Liegt in solchen Fällen nicht meist ein Designfehler vor?

Polyphormismus hat den Zweck, dass du unterschiedliche Objekte gleich behandeln kannst.

Ja, wahrscheinlich. Allerdings fällt mir auch nicht ein wie ich es sonst machen soll.

Hier die Grafik, die meine Frage auslöste! (Auf Seite 3!)

Wir haben generell die Klasse Konto, davon abgeleitet verschiedene Konten mit Spezialisierungen, zb. das Sparkonto mit einem Zinssatz der dazugehörigen Methode verzinse(). Wenn man normal Objekte der Klassen anlegt, ist das ja kein Problem. Aber wenn ich bei so einem Klassendesign mit Polymorphie arbeiten will [Konto *obj=new Sparkonto(...);] müßte ich die verzinse()-Methode schon in der Basisklasse Konto implementieren. Dort habe ich aber keinen Zinssatz!! (Die Variable wird ja auch erst in der abgeleiteten Klasse eingeführt).

Hat jemand eine Idee, wie man die drei Konten polymorphisch ansprechen kann. Ich hab keine.

Die Methode, die Methoden in der Basisklasse zu implementieren, und dann aus den abgeleiteten Klassen heraus aufzurufen (wie hier von einigen vorgeschlagen), funktioniert auch nicht. Dann regte sich der Compiler auf, daß die AUFRUFER-Methoden nicht in der Basisklasse implementiert sind. ("Mehtod xy is not a member of class z(=Basisklass)")

Wenn jemandem noch was einfällt, bitte melden. Bin dem Wahnsinn nahe.

Danke

Sobald dann die Zinsen an die Reihe kommen nutzt du Polymorphie nicht mehr. Wenn es in manchen Konten keine Verzinsung gibt wäre das ja auch sinnlos. Du würdest ja dann für nicht verzinsbare Konten Zinsen berechnen wollen.

Also wir nehmen mal an du hast alle Konten in einem std::vector<Konto> gespeichert. Da können also Sparkonten Girokonten usw drin sein. Willst du jetzt für ein Girokonto verzinsen aufrufen? Nein willst du nicht, weil ein Giro Konto keinen Zinsen kennt. Also wirst du die Konten sowieso nicht gleich behandeln in diesem Fall und eben keinen Polyphormismus nutzen.

(Sollte es halt jetzt wirklich sooo sehr stören dann setzt du eben eine virtuelle Methode verzinsen in die Basisklasse die dann einfach nichts macht, auszer in der Klasse Sparkonto, dann funktionnierts)