Teil 9: Vererbung. Prof. Dr. Herbert Fischer Fachhochschule Deggendorf Prof. Dr. Manfred Beham Fachhochschule Amberg-Weiden

Transkript

1 Teil 9: Vererbung Prof. Dr. Herbert Fischer Fachhochschule Deggendorf Prof. Dr. Manfred Beham Fachhochschule Amberg-Weiden

2 Inhaltsverzeichnis 9 Vererbung Motivation Deklaration und Zugriffsrechte Initialisierung Konstruktoren und Destruktoren Initialisierung durch Kopie Polymorphismus Standardkonversionen bei abgeleiteten Klassen Virtuelle Funktionen "pure virtual"-funktionen und abstrakte Klassen Komplexes Programmbeispiel zum Einsatz von Vererbung Zusammenfassung Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 2

3 9 Vererbung Wir kennen bereits den Begriff der Vererbung in der objektorientierten Softwareentwicklung. Mit Hilfe der Vererbung können wir einmal erstellte Programmteile wiederverwenden, indem wir die Elemente einer Klasse an andere Klassen weiterreichen. Damit muss nicht in jeder Klasse das Rad neu erfunden werden. Wenn wir allgemeingültige Konzepte in unseren Objekten erkennen, sollten wir diese auch nur einmalig in sogenannten Basisklassen realisieren. Wir werden in diesem Kapitel die C++ Mechanismen zur Vererbung kennen lernen und beispielhaft einsetzen. Wir werden folgende Fragen beantworten: Wie vererbt man die allgemeinen Eigenschaften eines Kontos an spezialisierte Konten? Was bedeutet der Begriff Polymorphismus und in diesem Zusammenhang virtual? Was ist eine abstrakte Klasse? 9.1 Motivation Aus Gründen einer wirtschaftlich effizienten Programmentwicklung und höherer Softwarequalität fordert die Softwareindustrie von ihren Programmen oder Programmteilen: Wiederverwendung, Möglichkeiten zur Anpassung und Erweiterung. Deshalb ermöglicht die OO Softwareentwicklung, sogenannte Klassenhierarchien zu erstellen. Diese Hierarchie entsteht dadurch, dass neue Klassen gebildet werden, indem auf schon vorhandene, allgemeinere Klassendeklarationen mit Hilfe der Vererbung oder Ableitung zurückgegriffen wird. Ein Beispiel, bei dem Vererbung vorteilhaft eingesetzt werden kann, sind die verschiedenartigen Bankkonten. Wir haben es mit Girokonten, Sparkonten, Aktiendepots, Cashkonten um nur einige zu nennen zu tun. Alle diese verschiedenartigen Konten haben etwas gemeinsam. Diese Gemeinsamkeit modellieren wir in einer generellen Kontoklasse und bezeichnen diese Klasse auch als Basisklasse. Mit Hilfe der Vererbung wollen wir diese allgemeinen Eigenschaften eines Kontos in spezielleren Kontoklassen wiederverwenden. Dadurch spart man eine Menge Arbeit, da grundlegende Attribute und Methoden, die für alle Konten gelten, nur einmalig entwickelt und getestet werden müssen. Dieses Vorgehen vermeidet auch Fehler, die beim mehrmaligen entwickeln gleicher Funktionalität entstehen können. Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 3

4 Im Klassendiagramm werden die Beziehung zwischen der Basisklasse und den abgeleiteten Klassen durch Pfeile dargestellt. Die Pfeilspitze zeigt dabei in Richtung der Generalisierung. In der anderen Richtung haben wir demnach eine Spezialisierung. In den speziellen Konten müssen wir dann nur noch die Spezialitäten des jeweiligen Kontos realisieren. Also z.b. für das Girokonto: eine Geheimnummer,... und eine Methode prüft, die die eingegebene Nummer mit der Geheimnummer des Kontos vergleicht. Oder für das Sparkonto: eine Sperrfrist,... Durch die Vererbung wird sichergestellt, dass die Attribute und Methoden der Basisklasse auch in den abgeleiteten Klassen verfügbar sind wir sagen auch Attribute und Methoden werden vererbt. Die Beziehung zwischen abgeleiteter Klasse und Basisklasse lässt sich lesen mit ist ein. Also z.b. Girokonto ist ein Konto; ebenso wie Cashkonto ist ein Konto oder Sparkonto ist ein Konto. Wann sollte eine Klasse durch Vererbung gebildet werden? Eine Klasse ergibt sich als Spezialisierung oder Erweiterung einer vorhandenen (Girokonto). Eine Klasse vereint die Eigenschaften mehrerer vorhandener Klassen (Mehrfachvererbung). Zwei parallel entwickelte Klassen enthalten einen gemeinsamen Kern, der als Basisklasse verwendet werden kann. Vorteile: Die abgeleitete (neue) Klasse (Unterklasse, Kindklasse) erbt (fast) alle Eigenschaften - Attribute - Methoden von den bestehenden Klassen (Basisklassen, Oberklassen, Elternklassen), ohne daß diese angetastet oder neu übersetzt werden müssen. Diese Eigenschaften können in der abgeleiteten Klasse ergänzt oder auch verändert werden: - weitere Methoden oder Attribute hinzufügen - Methoden modifizieren Verschiedene Klassen in einer Hierarchie können eine gemeinsame, einheitliche Schnittstelle haben, was den Umgang mit Objekten dieser Klasse vereinfacht. Einschränkungen: Nicht vererbt werden: - Freundschaft mit einer anderen Klasse friend - Ein klassenspezifischer Zuweisungsoperator operator=() - Konstruktoren und Destruktoren 9.2 Deklaration und Zugriffsrechte Allgemeine C++ Syntax um eine Klasse abzuleiten: class AbgelKlasse : [virtual][private public protected] BasisKlasse, // Deklarationen für AbgelKlasse... Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 4

5 Der Name der abgeleiteten Klasse wird durch : vom Namen der Basisklasse(n) getrennt. Zugriffsrechte nach der Ableitung: Grundsätzlich erbt AbgelKlasse alle Komponenten von BasisKlasse, d.h. jede Instanz von AbgelKlasse enthält ein (anonymes) Objekt vom Typ BasisKlasse. Dieses Subobjekt wird noch vor den zusätzlichen Komponenten von AbgelKlasse durch impliziten Aufruf des Basisklassenkonstruktors erzeugt. Das Zugriffsrecht in der BasisKlasse und der Zugriffsmodifizierer (z.b. public oder private) bei der Ableitung bestimmen das Zugriffsrecht auf Komponenten von BasisKlasse in AbgelKlasse. private-komponenten von BasisKlasse sind in AbgelKlasse grundsätzlich nicht zugänglich. Ein Zugriff ist hier weiterhin nur über öffentliche Methoden von BasisKlasse möglich. Durch Ableitung von einer Klasse, kann man sich also nicht den Zugriff auf private Elemente erschleichen. public-ableitung: class AbgelKlasse : public BasisKlasse protected-komponenten von BasisKlasse sind auch in AbgelKlasse zugänglich jedoch nicht allgemein. public-komponenten der BasisKlasse sind auch in AbgelKlasse public. protected-ableitung: class AbgelKlasse : protected BasisKlasse public-komponenten von BasisKlasse werden zu protected-komponenten von AbgelKlasse. Auf sie kann von "außerhalb" nicht mehr zugegriffen werden. private-ableitung: class AbgelKlasse : [private] BasisKlasse Alle public- und protected-komponenten von BasisKlasse sind in AbgelKlasse private. Diese Form wird dann eingesetzt, wenn eine neue Schnittstelle in AbgelKlasse entstehen soll, d.h. die Implementierung wird vererbt (modelliert nicht "ist ein" sondern "ist implementiert durch"). Beachte: Es gilt immer das restriktivere Zugriffsrecht! Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 5

6 Tip: In der Definition von AbgelKlasse läßt sich das Zugriffsrecht einzelner Komponenten von BasisKlasse gezielt beeinflussen: class AbgelKlasse : <mod> BasisKlasse... [private public protected]: BasisKlasse::KomponentenName; // alte using BasisKlasse::KomponentenName; // neue Schreibw.... Beispiel: class AbgelKlasse : BasisKlasse... public: Basisklasse::Attribut ;... //defaultmäßig private abgeleitet //Attribut ist nun wieder public 9.3 Initialisierung Wenn wir nun ein Objekt einer abgeleiteten Klasse also z.b. Girokonto anlegen, stellt sich die Frage, wie werden dabei die ererbten Attribute der Klasse Konto initialisiert. Dazu gibt es genaue Regeln für die Konstruktoren abgeleiteter Klassen Konstruktoren und Destruktoren In einem Test wollen wir den Aufruf der Konstruktoren und Destructoren durch eingebaute Ausgaben während des Programmlaufs sichtbar machen: class Konto private: int KtoNr; //... public: // Defaultkonstruktor Konto () : KtoNr(999) cout << "Konto(), KtoNr: " << KtoNr << endl; // Parameterkonstruktor Konto (int knr) : KtoNr(kNr) cout << "Konto(int), KtoNr: " << KtoNr << endl; // Destruktor ~Konto() Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 6

7 cout << "~Konto(), KtoNr: " << KtoNr << endl; class Girokonto : public Konto private: float Dispo; //... public: Girokonto () : Dispo(2000) cout << "- Girokonto(), Disp.: " << Dispo << endl; Girokonto (float d) : Dispo(d) cout << "- Girokonto(float), Disp.: " << Dispo << endl; Girokonto (int knr, float d) : Konto(kNr), Dispo(d) cout << "- Girokonto(int,float), Disp.: " << Dispo << endl; ~Girokonto () cout << "- ~Girokonto(), Disp.: " << Dispo << endl; void main() Girokonto a, b(5500.0), c(123,1000.0); Ausgabe: Konto(), KtoNr: Girokonto(), Disp.: 2000 Konto(), KtoNr: Girokonto(float), Disp.: 5500 Konto(int), KtoNr: Girokonto(int,float), Disp.: ~Girokonto(), Disp.: 1000 ~Konto(), KtoNr: ~Girokonto(), Disp.: 5500 ~Konto(), KtoNr: ~Girokonto(), Disp.: 2000 ~Konto(), KtoNr: 999 Press any key to continue Erkenntnisse: Komponenten von Basisklassen können nur über ihre Konstruktoren initialisiert werden. Der Konstruktoraufruf erfolgt entweder implizit: Defaultkonstruktor (falls vorhanden) oder muß explizit erfolgen: in der Initialisierungsliste Ein expliziter Konstruktoraufruf muß erfolgen, wenn Parameter übergeben werden sollen. Die Parameter müssen bei der Definition der abgeleiteten Klasse in der Initialisierungsliste unter dem Namen der Klasse angegeben werden. Girokonto (int knr, float d) : Konto(kNr), Dispo(d) Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 7

8 Eine direkte Initialisierung ohne Konstruktoraufruf geerbter Attribute über die Initialisierungsliste ist nicht möglich! Reihenfolge der Konstruktion: Basisklassen in der Reihenfolge ihrer Deklaration in der Ableitungsliste (nicht in der Initialisierungsliste), danach die Member der abgeleiteten Klasse in der Reihenfolge ihrer Deklaration. Reihenfolge der Destruktion: genau umgekehrt Initialisierung durch Kopie Für das Verständnis dieses Abschnitts ist der Begriff des Copy-Konstruktors nötig, der erst in der nächsten Folge (Folge 10, Überladen von Operatoren) vollständig eingeführt wird. Ein Copy-Konstruktor ist immer dann nötig, falls ein Objekt einer abgeleiteten Klasse durch Kopie initialisiert wird, z.b. in der Form void main() Girokonto Objekt1(123,2000.0); Girokonto Objekt2 = Objekt1;... so lassen sich vier Fälle unterscheiden: 1. Die Basisklasse und die abgeleitete Klasse definieren keinen Copy-Konstruktor (siehe Folge 10): Es erfolgt eine elementweise Kopie der Komponenten von Objekt1 nach Objekt2 über die standardmäßig zur Verfügung gestellten Copy-Konstruktoren (Basisklassenanteil zuerst). 2. Für die Basisklasse wurde ein Copy-Konstruktor definiert, für die abgeleitete Klasse jedoch nicht. Konto(const Konto & rbobjekt) : KtoNr(rBObjekt.KtoNr) Der Basisklassenanteil wird automatisch durch den Copy-Konstruktor der Basisklasse initialisiert. Weitere Member des abgel. Objektes werden durch elementweise Kopie initialisiert. 3. Die abgeleitete Klasse definiert einen Copy-Konstruktor, die Basisklasse jedoch nicht. a) Girokonto(const Girokonto & rgobjekt) : Dispo(rGObjekt.Dispo) Für den Basisklassenanteil wird der Standardkonstruktor aufgerufen. b) Girokonto(const Girokonto & rgobjekt) : Konto(rGObjekt) Dispo(rGObjekt.Dispo) Der Basisklassenanteil wird durch elementweise Kopie initialisiert. Die Member des abgeleiteten Objektes werden durch den angegeben Copy-Konstruktor initialisiert. 4. Beide Klassen definieren Copy-Konstruktoren. Auch hier ist der Copy-Konstruktor der Basisklasse explizit im Copy-Konstruktor der abgeleiteten Klasse aufzurufen (Fall 3b). Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 8

9 9.4 Polymorphismus Manchmal ist es sinnvoll, wenn sich eine bestimmte Methode einer Klasse unterschiedlich verhält, je nachdem in welchem Zusammenhang unsere Klasse eingesetzt wird. Es ist möglich, dass die Methode einer Klasse höchst unterschiedliche Ergebnisse produziert und damit die Vielgestaltigkeit also den Polymorphismus der Klasse hervorruft. Eine Klasse, die Methoden dieser Art besitzt, bezeichnen wir als polymorphe Klasse. Ein sinnvolles Beispiel für eine derartige Methode wäre das Drucken eines Kontoauszugs. Betrachten wir dazu nochmals unser Klassendiagramm mit den verschiedenen Kontotypen und überlegen uns, wie ein Kontoauszug gedruckt werden könnte. Sicher soll der Ausdruck für ein Sparkonto andere Details beinhalten als der Ausdruck für ein Girokonto. Wir werden also allen unseren Kontotypen eine eigene, spezielle Methode print spendieren. Auch für die Basisklasse Konto wäre eine Methode print denkbar: Konto::print class Konto public: //... void print () const cout << "KtoNr: " << KtoNr << endl; cout << "Stand: " << Stand << endl << endl; Girokonto::print #include konto.h class Girokonto : public Konto public: //... void print () const cout << "Giro KtoNr: " << getktonr() << endl; cout << "Stand: " << getstand() << endl; cout << "Dispo: " << Dispo << endl << endl; Datei: main.cpp #include girokonto.h int main () Konto * kp = new Konto(111); GiroKonto * gp = new Girokonto(222); kp->print(); gp->print(); return 0; Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 9

10 Frage: Was gibt dieses Beispielprogramm aus? KtoNr: 111 Stand: 0.0 Giro KtoNr: 222 Stand: 0.0 Dispo: Das war zu erwarten. Für ein Objekt vom Typ Konto wird auch die Methode Konto::print und für ein Girokonto Girokonto::print aufgerufen. Der Typ eines Objekts entscheidet also, welche Methode aufzurufen ist. Das gilt auch für Zeigervariablen, denn auch sie haben einen Typ, nämlich den Typ des Objekts, auf das sie verweisen. Deshalb kann bereits der Compiler bei der Erstellung des Programms entscheiden, welche Methode aufzurufen ist. Wir bezeichnen diesen Vorgang auch als statisches Binden Standardkonversionen bei abgeleiteten Klassen Die Verhältnisse werden etwas unübersichtlicher, wenn wir den Typ eines Zeigers in einen anderen Typ wandeln. Normalerweise kann der Typ eines Objekts nicht einfach geändert werden. Wir können deshalb nicht einfach einer Variablen vom Typ Girokonto ein Sparkonto zuweisen. Ein Girokonto ist andersartig als Objekte vom Typ der Klasse Sparkonto. Schließlich fehlen dem Sparkonto wichtige Attribute, die nur Girokonto besitzt. Wenn wir mit abgeleiteten Klassen arbeiten, ist aber unter bestimmten Umständen eine Typkonvertierung möglich. Und zwar kann eine spezielle Klasse auf die generelle Klasse konvertiert werden. Implizite Typkonvertierung: Beachte: Ein Objekt, ein Zeiger oder eine Referenz einer abgeleiteten Klasse kann einem Objekt, einem Zeiger oder einer Referenz seiner Basisklasse zugewiesen werden. Dabei findet eine implizite Typkonvertierung statt (gilt nicht umgekehrt). Bei Objekten gehen die zusätzlichen Daten der abgeleiteten Klasse verloren, der Basisklassenanteil wird kopiert. In folgendem Beispiel legen wir ein Objekt vom Typ Girokonto an und weisen den Zeiger auf dieses Objekt einer Variablen vom Typ Zeiger auf Konto zu. Also eigentlich zwei unterschiedliche Klassen, aber diese Umwandlung ist möglich., weil Girokonto ist ein Konto. Und deshalb darf auch ein Konto-Zeiger auf ein Girokonto verweisen. Wir haben also gar keine Konvertierung des Objekts selbst vorgenommen, sondern lediglich einen andersartigen Verweis auf das Objekt Girokonto. Beispiel: main1.cpp #include girokonto.h int main () GiroKonto * gp = new Girokonto(222); Konto * kp = gp; // implizite Typkonvertierung: Girokonto zu Konto kp->print(); Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 10

11 return 0; Frage: Was gibt dieses Beispielprogramm aus? KtoNr: 222 Stand: 0.0 Das ist eigentlich nicht überraschend. Die Regel, dass der Datentyp des Objekts die zugehörige Methode bestimmt gilt auch hier. Also ein Zeiger auf Konto => Methode Konto::print von Konto. Beachte: Der statische Zeigertyp bestimmt die aufzurufende Methode! Dieses Verhalten ist aber nicht immer erwünscht. Wir hatten doch eigentlich in diesem Beispiel ein Objekt vom Typ Girokonto, es wird aber die Methode der Klasse Konto aufgerufen also ein allgemeiner nichtssagender Kontoauszug gedruckt. Dieses Verhalten können wir grundlegend ändern, wenn wir unsere print-methode virtuell deklarieren Virtuelle Funktionen Ziel: Verwendung "allgemeiner" Zeiger zur Verwaltung unterschiedlicher Objekte einer Klassenhierarchie, wobei die (in den abgeleiteten Klassen gleichnamigen) Methoden des Objektes angesprochen werden, auf das gerade gezeigt wird (Nicht der Zeigertyp bestimmt die Methode, sondern der Objekttyp!). Lösung: Um dies zu gewährleisten, müssen die relevanten (nicht statischen) Methoden zumindest in der Basisklasse mit dem Schlüsselwort virtual als dynamisch bindbar gekennzeichnet werden. Virtuelle print Methode class Konto //... wie gehabt virtual void print () const cout << "KtoNr: " << KtoNr << endl; cout << "Stand: " << Stand << endl << endl; Die einzige Veränderung an unserer Klasse Konto ist das Schlüsselwort virtual vor der Deklaration der Methode print(). Wir verwenden das Beispielprogramm main2.cpp aus vorigem Abschnitt unverändert und stellen uns die Frage: Was wird ausgegeben? Beispiel: #include girokonto.h Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 11

12 int main () GiroKonto * gp = new Girokonto(222); Konto * kp = gp; // implizite Typkonvertierung: Girokonto zu Konto kp->print(); return 0; Das ist jetzt etwas vollkommen neues. Der Typ der Zeigervariablen bestimmt nun nicht mehr die aufzurufende Methode, sondern der tatsächlich vorliegende Objekttyp entscheidet, welche Methode aufgerufen wird. Denn obwohl kp ein Zeiger auf Konto ist, wird die Methode Girokonto::print aufgerufen. Hier kann auch nicht mehr der Compiler bereits die Methodenauswahl treffen, sondern es muss zur Laufzeit des Programms, die richtige Methode gewählt werden. Wir bezeichnen diesen Vorgang im Gegensatz zum statischen Binden auch als late binding. Bei virtuellen Methoden können wir also noch nicht vorhersagen, welche Funktion tatsächlich ausgeführt wird. Das man das richtige Verhalten für die Methode print der Klasse Konto erhält unabhängig davon, welche Art von Konto man eigentlich benutzt, wird Polymorphismus genannt. Eine Klasse mit virtuellen Methoden wird polymorphe Klasse genannt. Um polymorphes Verhalten in C++ zu erzielen, müssen die aufgerufenen Methoden virtuell sein. Hinweise zur Verwendung von virtual: virtual darf nur innerhalb der Klassendefinition angegeben werden. virtual muß in der Basisklasse angegeben werden und sollte in den davon abgeleiteten Klassen wiederholt werden (virtual vererbt sich). Eine Klasse, in der eine virtuelle Methode vorhanden ist (durch Deklaration oder Vererbung), heißt auch polymorphe Klasse. Eine virtuelle Methode kann (sollte aber nicht) in einer abgeleiteten Klasse durch eine gleichnamige Methode mit unterschiedlichen Parametern überschrieben werden. In diesem Fall wird der "virtual- Mechanismus" nicht ausgelöst, die neue Methode überdeckt die virtuelle Methode. virtual wirkt nur, wenn die so gekennzeichnete Methode in der abgeleiteten Klasse exakt die gleiche Schnittstelle (Rückgabetyp + Signatur) besitzt. Ausnahme: Ist der Rückgabetyp eine Referenz oder ein Zeiger auf die Basisklasse, dann darf der Rückgabetyp in der abgeleiteten Klasse eine Referenz oder ein Zeiger auf die abgeleitete Klasse sein. Beachte: Eine als virtual deklarierte Methode in einer Basisklasse definiert explizit eine Schnittstelle für alle davon abgeleiteten Klassen. Nicht virtuelle Methoden sollten in abgeleiteten Klassen nicht überschrieben werden! Für besonders Interessierte: Der virtual Mechanismus Die Ermittlung der Adresse der virtuellen Funktion, die über einen Basisklassenzeiger aufgerufen wird, erfolgt erst zur Laufzeit. Das Schlüsselwort virtual bewirkt: Jedes Objekt einer polymorphen Klasse enthält zusätzlich einen Zeiger vptr, den virtual table pointer. Dieser zeigt auf eine Adresstabelle, in der Verweise auf alle dynamisch bindbaren Methoden der Klasse aufgenommen sind. Diese virtuelle Methodentabelle VMT oder virtual function table VFT wird für jede polymorphe Klasse in einer Hierarchie angelegt. Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 12

13 Wird für ein Objekt über einen Zeiger oder eine Referenz eine virtuelle Methode aufgerufen, so erfolgt dies indirekt über den vptr, der auf die zugehörigen Methoden des referenzierten Objektes verweist. Da nur ein existierendes Objekt über einen vptr verfügt, dürfen statische Methoden nicht virtual deklariert werden, da sie ja objektunabhängig existieren und aufgerufen werden können. Auch Konstruktoren können nicht virtual sein, da sie für "noch nicht" existierende Objekte aufgerufen werden. Beachte: Falls eine Klasse virtuelle Methoden deklariert, sollte auch der Destruktor als virtual deklariert werden "pure virtual"-funktionen und abstrakte Klassen Man kann in C++ noch einen Schritt weiter gehen und virtual deklarierte Funktionen in der Basisklasse gar nicht mehr realisieren. Wir bezeichnen eine lediglich deklarierte aber nicht definierte virtuelle Funktion als pure-virtual-function. In der Basisklasse wird dann nur noch ein Konzept festgelegt, d.h. eine Art Designvorschrift, in der angegeben wird, welche Methoden überlagert werden müssen und wie deren Schnittstelle auszusehen hat, dann braucht für diese Methoden auch keine Implementierung angegeben werden. Pure virtual print Methode: class Konto //... wie gehabt virtual void print () const = 0; // keine Implementierung in der Basisklass Von der Klasse Konto kann dann keine Instanz gebildet werden. Sie wird deshalb als abstrakte Klasse bezeichnet. Zeiger und Referenzen auf eine abstrakte Klasse können jedoch definiert werden. pure virtual functions werden vererbt. D.h. eine von einer abstrakten Klasse abgeleitete Klasse ist nur dann nicht mehr abstrakt, wenn sie für alle pure virtual functions eine Implementierung angibt. Eine abgeleitete Klasse kann durch eigene pur virtual functions erst zur abstrakten Klasse werden. Beachte: Abstrakte Klassen sollten ebenfalls mit einem virtuellen Destruktor ausgestattet werden Komplexes Programmbeispiel zum Einsatz von Vererbung Im folgenden Beispiel soll veranschaulicht werden, wie vorteilhaft Vererbung gerade bei großen Softwareprojekten eingesetzt werden kann, wenn mehrere Entwickler möglichst unabhängig voneinander ein Problem bearbeiten sollen. Polymorphismus ist deshalb ein wesentliches Element der OO- Softwareentwicklung. Wir wollen nochmals eine Liste von Konten entwickeln, aber diesmal von einem sehr weitblickenden Entwickler, und wir wollen versuchen, die Designentscheidungen dieses Entwicklers nachzuvollziehen. Zuerst einmal muss er natürlich berücksichtigen, das verschiedenartige Konten in einer Liste aufgenommen werden. Denn es gibt ja Girokonten, Sparkonten, etc. Ein sehr weitblickender Entwickler würde noch einen Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 13

14 Schritt weiter gehen und seine Liste nicht nur auf Konten beschränken. Er würde daher Listen von allen möglichen Objekten aufbauen also z.b. Adressen, Kundenkontakte, Transaktionen, usw. Der sehr weit blickende Entwickler würde sich also die Frage stellen, was haben alle Objekte gemeinsam, die in meine Liste aufgenommen werden sollen. Diese Gemeinsamkeit würde er dann Konzept nennen. Und er würde fordern: Alle Objekte, die in meine Liste wollen, müssen dieses Konzept realisieren. Ein Konzept wird in C++ durch eine Klasse beschrieben. Damit haben wir eine viel allgemeinere und meines Erachtens auch bessere Definition für die Klassen in C++: Eine Klasse beschreibt ein Konzept Die Klasse Element Wir nennen unser allgemeines Konzept für Objekte, die in eine Liste aufgenommen werden können, Element. Das wird auch der Name der Klasse. Wir überlegen uns zuerst nur, was sollen unsere Listenelemente können: Sich durch Ankoppeln an bestehende Elemente in einer Liste verketten: insert Einen Ausdruck erzeugen: print. Damit wollen wir einen Ausdruck der gesamten Liste ausgeben. Diese beiden Methoden beschreiben unser jetzt ein sehr allgemeines Konzept für unsere Klasse Element. Damit ergibt sich die Klassendefinition wie folgt: // Klasse für Listenelemente class Element friend class List; private: Element* next; // Verkettungszeiger public: Element () : next(0) virtual void print () const = 0; // pure virtual function protected: inline void insert (Element* e); Die reine Deklaration ist noch nicht sehr hilfreich, wir müssen die Methoden auch noch realisieren. Die Methode insert können wir bereits realisieren. Sie wissen, wir benötigen einen Verkettungszeiger, der ein wichtiger Bestandteil unseres Konzepts Listenelement ist. Das Ankoppeln erfolgt durch geeignete Veränderung der Verkettungszeiger: //... // Dieses Element nach einem Element an der Position pos ankoppeln void Element::insert (Element* pos) next = pos->next; pos->next = this; Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 14

15 Wie sollen wir aber die Methode print realisieren, wenn wir noch gar nicht wissen können, welche Objekte jemals in unsere Liste eingefügt werden? Wir können diese Methode in unsrem allgemeinen Konzept gar nicht realisieren. Wir haben sie lediglich in unser Konzept aufgenommen, um zu fordern, dass alle Elemente, die in unsere Liste aufgenommen werden, diese Methode realisieren müssen. Deshalb deklarieren wir diese Methode virtuell. Damit ist sichergestellt, das die passende print-methode der Objekte aufgerufen wird, die später einmal in unserer Liste sind. Objekte unserer Klasse Element sind allerdings ziemlich sinnlos. Man kann sie zwar in einer Liste verketten; sie tragen aber keinerlei Information. Deshalb können wir auch die print Methode gar nicht realisieren und aus diesem Grund deklarieren wir sie einfach als pure virtual function, was durch das = 0 am Ende der Deklaration kenntlich gemacht wird. Pur virtuell bedeutet also, dass in der Basisklasse keine Realisierung dieser Funktion existiert. Eine Klasse, die pure virtual functions besitzt, wird zur abstrakten Klasse. Von einer abstrakten Klasse können keine Objekte angelegt werden. Sie dient vielmehr als Beschreibung für ein Konzept, das durch Vererbung in den abgeleiteten Klassen vervollständigt werden muss. Wir haben jetzt eine abstrakte Klasse definiert, die das grundlegende Konzept für alle möglichen Listenelemente festlegt. Die Klasse List Für unseren weitblickenden Programmierer bedeutet dies: Er kann bereits eine Liste programmieren, ohne zu wissen, welche Objekte jemals in dieser Liste aufgenommen werden. Andere Programmierer könnten diese Liste verwenden, um ihre eigenen Objekte darin zu speichern. Die Programmierer müssten sich gar nicht gegenseitig kennen, denn alles was sie von der Liste benötigen, ist das Konzept der Elemente: #include element.h // Liste mit Dummyelement für den Kopf der Liste class List private Element head; public: void insert (Element* ep) ep->insert (&head); void print () const Element *ep; for (ep = head.next; ep!= 0; ep = ep->next) ep->print (); //!!! Verwendung einer pure virtual Funktion Dieses Beispiel zeigt, wir können bereits die vollständige Listenklasse implementieren, obwohl wir noch gar nicht wissen, welche Elemente in die Liste eingefügt werden. Wir verwenden einfach ein abstraktes Konzept für die Elemente und können bereits die noch nicht definierten pure virtual Funktionen aufrufen. Funktionsfähig wird die Liste aber erst, sobald wir konkrete Klassen von unserem abstrakten Element Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 15

16 ableiten und in die Liste einfügen. Welche Klassen das sein werden, braucht uns hier noch nicht zu interessieren. Eine Liste von Konten Wenn wir unsere Konten also in einer Liste ablegen wollen, müssen wir die Klasse Konto von der Klasse Element ableiten und wir dürfen nicht vergessen die Methode print zu implementieren, denn sonst bleibt auch die Klasse Konto abstrakt und wir könnten keine Konten anlegen. Sie sehen hier den Quelltext der Klasse Konto. Sie wir public von Element abgeleitet und sie realisiert die virtuelle print Methode. Damit ist Konto keine abstrakte Klasse mehr und wir können Objekte vom Typ Konto anlegen: #include element.h // Konto (allgemein) class Konto : public Element private: int KtoNr; float Stand; public: virtual void print () const cout << KtoNr: << KtoNr <<, DM << Stand << endl;... // weitere Methoden Zusammenfassend können wir also sagen: Die Klasse Konto realisiert das Konzept Element. Damit können Objekte vom Typ Konto Bestandteil unserer Liste werden. Dazu ein Ausschnitt aus dem Hauptprogramm: #include konto.h #include list.h int main () List l; Konto* kp = new Konto (32168, 0.0); // füge Konto ein l.insert (kp); //... // gebe Liste aus l.print () //... Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 16

17 9.5 Zusammenfassung Nachfolgende Tabelle fasst die wesentlichen Eigenschaften von (speziellen) Memberfunktionen, Operatoren und friends bezüglich Vererbbarkeit und anderen Eigenschaften zusammen: Prof. Dr. Manfred Beham, FH Amberg-Weiden Seite 17