OOP II.

Präsentation zum Thema: "OOP II."—  Präsentation transkript:

1 OOP II

2 Modellierung einer "ist-ein"-Beziehung zwischen Datentypen
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Allgemeine Regeln I Modellierung einer "ist-ein"-Beziehung zwischen Datentypen manchmal ist ein Datentyp A ein Untertyp eines Obertyps B die Klasse A ist dann eine Erweiterung der Klasse B, d.h. alles was B hat hat auch A Syntax: class A extends B alle Methoden von B sind somit in A und über A-Objekte verwendbar A kann Methoden von B durch eigene (passendere) Methoden überschreiben

3 Von einer Klasse B können beliebig viele Klassen abgeleitet werden
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Allgemeine Regeln II Von einer Klasse B können beliebig viele Klassen abgeleitet werden eine Klasse A kann nur von einer Klasse erben (single inheritance) in einem Konstruktor von A wird implizit der argumentlose Konstruktor von B aufgerufen super() andere Konstruktoren können explizit mit super(...) (als erste Anweisung) angesprochen werden durch endgültige Klassen (final class) lässt sich die Vererbung / Ableitung verhindern Wiederverwendbarkeit: der Code der Basisklasse muss nicht neu programmiert werden

4 Allgemeine Regeln III Superklasse Subklasse
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Allgemeine Regeln III Superklasse Subklasse

5 Beispiel CCylinder->CCircle I
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Beispiel CCylinder->CCircle I

6 Beispiel CCylinder->CCircle II
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Beispiel CCylinder->CCircle II Klassenname, von der sich die Klasse ableitet Aufruf des Konstruktors der übergeordneten Klasse Zusätzliche neue Methoden der abgeleiteten Klasse

7 Beispiel CCylinder->CCircle III
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Beispiel CCylinder->CCircle III Methode der ursprünglichen Klasse Methode der abgeleiteten Klasse

8 Beispiel CCylinder->CCircle IV
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Beispiel CCylinder->CCircle IV Überschreiben der Methode der alten Klasse Verwenden der Methode der Klasse CCircle durch „super.“ (= Referenz auf die Superklasse)

9 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 “Super” I Ist kein Konstruktor definiert, dann wird automatisch ein Konstruktor OHNE Parameter erzeugt:

10 Konstruktoren werden nicht vererbt.
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 “Super” II Konstruktoren werden nicht vererbt. Konstruktoren der Basisklasse können mit super(...) aufgerufen werden. Ein solcher Aufruf von super(...) muss die erste Zeile der Konstruktordefinition sein

11 Damit auch den Aufwand, das Programm lesen und verstehen zu müssen
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Motivation Vererbung Es ist immer gut, mit der Typstruktur des Programms dicht an der realen Welt zu bleiben(Leichteres Verständnis) Man spart Tippaufwand Damit auch den Aufwand, das Programm lesen und verstehen zu müssen Wenn man was für alle Objekte ändern möchte, muss man die Änderung nur bei dem Eltern Objekt vornehmen

12 Private, Protected und Public I
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Private, Protected und Public I Zugriff erlaubt? Eigene Klasse Elternklasse Fremde Klasse = Tester(main) private ja protected public

13 Private, Protected und Public II
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Private, Protected und Public II Fehlermeldung: „ValuePriv has private access in Cparent“

14 Abstrakte Methoden werden nur deklariert aber nicht implementiert
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Abstrakte Klassen I Abstrakte Methoden werden nur deklariert aber nicht implementiert Methoden ohne Implementierung werden als abstrakt bezeichnet Eine Klasse, die abstrakte Methoden enthält, muss selbst als abstrakt deklariert werden abstract class abstractClass { abstract void abstractMethod(); void concreteMethod(){ System.out.println("This is a concrete method."); } Abstrakte Klassen können konkrete (implementierte) Methoden enthalten

15 Die abgeleitete Klasse sieht wie folgt aus:
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Abstrakte Klassen II Die abgeleitete Klasse sieht wie folgt aus: class derivedClass extends abstractClass{ public void abstractMethod(){ System.out.println("This is an implementation"); }

16 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Abstrakte Klassen III Abstrakte Klassen sind NICHT instanzierbar, der Compiler verbietet dann die Erzeugung von Objekten dieser Klasse, d.h. new abstractClass (...) gibt einen Fehler aus Die abgeleiteten Klassen müssen entweder alle abstrakte Methoden implementieren oder selbst abstrakt sein! Abstrakte Klassen sind nützlich als gemeinsame Schnittstelle für ihre Unterklassen(abgeleitete Klassen) Wenn man z.B. eine abstrakte Klasse für geometrische Objekte in der Ebene definiert (Kreise, Rechtecke, etc.), so wurde es Sinn machen, eine Methode zur Berechnung des Flächeninhaltes vorzusehen. Man kann die Flächenberechnung aber für allgemeine geometrische Objekte nicht sinnvoll implementieren(das geht nur für die Subklassen, d.h. konkrete Formen).

17 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Abstrakte Klassen IV Eine abstrakte Klasse muss nicht unbedingt nur abstrakte Methoden haben: Manche Methoden lassen sich vielleicht schon auf der allgemeinen Ebene implementieren. Falls eine abstrakte Klasse nur abstrakte Methoden und keine Attribute hat, sollte man eventuell ein “Interface” zu verwenden Damit man mit der abstrakten Klasse etwas anfangen kann, muss es eine Unterklasse geben, in der die abstrakten Methoden überschrieben (und damit tatsächlich implementiert) sind. Wenn eine Subklasse nicht alle ererbten abstrakten Methoden überschreibt, muss sie selbst „abstract” sein.

18 Ein Interface ist eine abstrakte Klasse mit nur abstrakten Methoden.
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Interfaces I Java verwendet “Single Inheritance”, d.h. jede Klasse kann maximal eine Oberklasse haben(C++, lassen “Multiple Inheritance” ). Ein Interface ist eine abstrakte Klasse mit nur abstrakten Methoden. Es ist angegeben, welche Methoden mit welchen Argument- und Resultat-Typen es geben muss, aber es ist keine Implementierung für diese Methoden angegeben, d.h. kein Methoden-Rumpf Eine Klasse kann nur eine Oberklasse haben, aber beliebig viele Interfaces implementieren

19 void changeCadence(int newValue); void changeGear(int newValue);
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Interfaces I Ein Interface ist eine Gruppe von zusammenhängenden Methoden ohne Implementierungen interface Bicycle { void changeCadence(int newValue); void changeGear(int newValue); void speedUp(int increment); void applyBrakes(int decrement); }

20 Mit dem Schlüsselwort implements wird die Klasse implementiert
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Interfaces II Mit dem Schlüsselwort implements wird die Klasse implementiert class ACMEBicycle implements Bicycle { int cadence = 0, speed = 0, gear = 1; public void changeCadence(int newValue) { cadence = newValue; } public void changeGear(int newValue) { gear = newValue; public void speedUp(int increment) { speed = speed + increment; public void applyBrakes(int decrement) { speed = speed - decrement; ALLE Methode von Bicycle müssen implementiert werden!

21 Abstrakte Klassen versus Interfaces
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Abstrakte Klassen versus Interfaces Beide deklarieren Methoden, die die implementierenden bzw. erbenden Klassen realisieren müssen. Von beiden kann kein Objekt erzeugt werden. Eine Klasse kann beliebig viele Schnittstellen besitzen, aber nur eine Oberklasse. Abstrakte Klassen können eigenen Programmcode besitzen, was bei Interfaces (Schnittstellen) nicht möglich ist. Müssen Interfaces nachträglich geändert werden, dann müssen alle implementierenden Klassen, die neuen Methoden nachimplementieren. Dies ist bei abstrakten Klassen nicht der Fall Mit public class CClass implements interface1, interface2; kann man Klassen aus zwei Interfaces implementieren

22 Überschreiben von Methoden I
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden I class CPerson { private String vorname; private String nachname; Person(String v, String n) { vorname = v; nachname = n; } String vorname() { return vorname; } String nachname() { return nachname; } void print() { System.out.print(vorname + " " + nachname); Elternklasse Cperson mit Attributen name, vorname und Methode print

23 Überschreiben von Methoden II
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden II Man kann in einer Subklasse eine Methode neu definieren, die in der Oberklasse bereits definiert ist. In diesem Fall wird die ererbte Methode überschrieben(“Overriding”) Z.B. könnte man in der Subklasse Lehrer die Methode print() so definieren, dass sie nach dem Namen “(Lehrer für Fächer)” mit ausgibt. Für die Objekte der Subklasse wird jetzt also eine andere Implementierung der Methode print() verwendet als für die Objekte der Oberklasse

24 Überschreiben von Methoden III
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden III class CTeacher extends CPerson { private String fach; CTeacher(String vorname, String nachname, String fach) { super(vorname, nachname); this.fach = fach; } String fach() { return this.fach; void print() { super.print(); System.out.print("Lehrer fuer "+ this.fach); Overriding Methode der Oberklasse

25 Überschreiben von Methoden IV – Regeln – Unterschied Überladen
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden IV – Regeln – Unterschied Überladen Eine Methode der Oberklasse wird nur dann an die Unterklasse vererbt, wenn sie dort nicht überschrieben wird Sie wird überschrieben, wenn in der Unterklasse eine Methode mit gleichem Namen und gleicher Anzahl sowie gleichen Typen der Argumente definiert wird Die Namen der Argumente spielen keine Rolle, aber die Argument-Typen müssen genau gleich sein, sonst handelt es sich um Überladen, nicht überschreiben, d.h. es gibt beide Methoden in der Unterklasse Der Zugriffsschutz darf in der Unterklasse schwächer sein(z.B. protected in der Oberklasse, public in der Unterklasse.)

26 Überschreiben von Methoden V – Zuweisung an übergeordnete Instanz
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden V – Zuweisung an übergeordnete Instanz CTeacher myTeacher = new CTeacher("Mister", "Big", "Science"); CPerson myPerson = myTeacher; myPerson.print(); Die statisch deklarierte Variable Cperson(statisch=kein new!) „enthält“ die Variable myTeacher, die die Methode print mit Ausgabe des Faches kennt In C++ musste man die Methode dazu “virtual” deklarieren. In Java sind alle Methoden automatisch “virtual” (und es gibt dieses Schlüsselwort nicht)

27 Überschreiben von Methoden VI - @Override
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden VI Wenn man eine Methode überschreiben will, ist empfohlen, die „Annotation“ @Override zu verwenden: class CTeacher extends CPerson { ... @Override void print() { ... } } Für den Leser des Programms ist klarer, was passiert. Der Compiler gibt eine Warnung bzw. Fehlermeldung aus, wenn doch kein Überschreiben vorliegt.

28 Überschreiben von Methoden VI - Polymorphie
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden VI - Polymorphie Allgemein heißt eine Methode/Funktion “polymorph”(“vielgestaltig”), wenn sie für unterschiedliche Klassen(Datentypen) unterschiedliche Implementierungen hat. Dies wurde eigentlich „überladene“ Methoden einschließen, aber in der objektorientierten Programmierung ist es üblich, nur Methoden, die in einer Subklasse überschrieben werden, als polymorph zu bezeichnen.

29 Überschreiben von Methoden VI - final
7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 7! = 1*2*3*4*5*6*7 2! = 1*2 1! = 1 0! = 1 Überschreiben von Methoden VI - final Mit dem Schlüsselwort final vor einer Methode verbietet man das Überschreiben dieser Methode final vor einer Klasse verbietet, dass Subklassen dieser Klasse definiert werden