Grundlagen der Informatik 1

Grundlagen der Informatik 1
Thema 13: Vererbung, Funktionsvorlagen, Späte Bindung Prof. Dr. Max Mühlhäuser Dr. Guido Rößling

Inhaltsverzeichnis Wozu Vererbung? Inkrementelles Programmieren
Definition neuer Objekttypen in Java Grundlagen des Package acm.graphics Modellierung eines Grafiksystems Abstrakte Klassen Schnittstellen Überschreiben bestehender Definitionen Späte Bindung der Methodenimplementierungen beim Operationsaufruf

Wozu Vererbung? In T12 haben wir eine Begriffshierarchie definiert
Kunde und Mitarbeiter sind spezielle Personen Manager und Verwalter sind wiederum spezielle Mitarbeiter Einfamilienhaus und Mehrfamilienhaus sind ein spezielles Haus Die Oberbegriffe (Haus, Person) haben bestimmte Eigenschaften, die alle Unterbegriffe ebenfalls haben Person: z.B. Name, Vorname, Telefonnummer, … Mitarbeiter: Büro Haus: Anschrift, Kaufpreis, Status, … Wir wollen das in Java ebenfalls nutzen Attribute wie die obigen sollen nicht mehrfach definiert werden Gemeinsame Methoden sollen nur einmal implementiert werden setName(String), setGivenName(String), setPhoneNumber(String),…

Motivation für neue Objekttypen
Die Klasse Person steht für allgemeine Personen Im Kontext der Immobilienverwaltung können wir erst mit konkreten Personen arbeiten, die eine Funktion haben Die also Manager, Verwalter oder Kunden sind Wir wollen aber nicht immer konkret sagen, welche Art Person wir erwarten Methode getPhoneNumber(Person p) hängt nicht davon ab, welche Art Person wir haben Wir wollen diese Methode nicht mehrfach implementieren Hier soll „jede Art Person“ zum Typ Person passen! Gleichzeitig haben die Untertypen spezielle Funktionen getListOfManagedClients() vs. getListOfHouses() etc.

Vereinbarkeit verschiedener Klassen
Mitarbeiter, Verwalter, Kunde, … sind eigene Klassen Um die unterschiedliche Funktionalität sauber zu realisieren Dennoch sollen sie wo nötig „zu Person passen“ ( getName()) Gemeinsame Methoden nur einmal implementieren Vermeidet Redundanz im Code Reduziert die Anzahl der Fehlerquellen Verbessert die Wartbarkeit und Wiederverwendbarkeit Passendes Konzept: Vererbung Wir sagen „Klasse Mitarbeiter erbt von Klasse Person“ Oder kürzer: Mitarbeiter erbt von Person

Grundregeln der Vererbung I
Regel 1: Vererbung beschreibt eine Spezialisierung Der Erbe ist eine speziellere Form seines Vorfahren Ein Kunde ist eine spezielle Person Umgekehrt ist der Vorfahr eine Verallgemeinerung seiner Erben Eine Person ist eine Verallgemeinerung für Kunde, Mitarbeiter, … Regel 2: Vererbung beschreibt eine „ist-ein“ Beziehung Ein Kunde ist eine (spezielle Art) Person Ein Mehrfamilienhaus ist ein (spezielles) Haus Vererbung ist keine „hat-ein“ Beziehung! Ein Kunde hat ein (oder mehr als ein) Haus Ein Kunde ist aber kein Haus Für hat ein verwenden wir Attribute: die Klasse Kunde hat als Attribut eine Liste von Häusern

Grundregeln der Vererbung II
Regel 3: Eine Klasse erbt alle Methoden und Attribute ihres Vorfahren Sie kann weitere Methoden oder Attribute definieren So hat ein Mitarbeiter noch eine Büronummer, die Person nicht hat Regel 4: Geerbte Methoden können neu definiert werden Die Implementierung der Methode wird dabei überschrieben Mehr dazu später in diesem Foliensatz Regel 5: Das grundsätzliche Verhalten des Erben in einer geerbten Methode sollte zu dem des Vorfahren passen „Unerwünschte“ Methoden kann man nicht „wegdefinieren“ Man sollte sie auch nicht durch Überschreiben mit leerem Körper („mache nichts“) „anpassen“ Beispiel: Kunde liefert bei getGivenName() immer nur null Die Abfrage des Vornamens einer Person kann nun Probleme erzeugen

Unser Ziel: Neue Objekttypen
Wir beschäftigen uns im Folgenden mit neuen Objekttypen Definition neuer Typen von Objekten Erzeugung und Benutzung neuer Instanzen (Objekte, Exemplare) dieser Typen Spezifikation allgemeiner Typen ohne direkte Funktionalität Anpassen geerbter Methoden durch Überschreiben

Motivation für neue Objekttypen
Motivation / Vorteile: Komplexere Aktionen pro Befehl Nähe zur natürlichen Sprache Einfacher zu verstehen und ggf. zu korrigieren Mentales Modell Design Modell niedriger Abstraktions- versatz schmale Repräsentations- Lücke Compiler Maschinenebene modulare Struktur des Programms

Spezifikation neuer Objekttypen
Neue Objekttypen werden inkrementell definiert Über ihre Unterschiede zu existierenden Typen  Spezialisierung von generelleren Konzepten Ein Manager ist eine spezielle Art Angestellter Anderer Ansatz: Gemeinsamkeiten verschiedener Objekttypen in einen gemeinsamen Super-Typ abstrahieren Übergeordnete / Untergeordnete Konzepte Rechtecke und Dreiecke sind untergeordnete Konzepte von grafischen Objekten (können z.B. gezeichnet werden) Eine neue Programmkomponente N wird konstruiert, indem man spezifiziert, wie sie sich von einer bestehenden Komponente B unterscheidet, ohne B dabei zu modifizieren. „semantic gap“ = Die Lücke zwischen gesprochener Sprache (Aufgabenbeschreibung) und Programm

Inkrementelles Programmieren: Analogie
Übereinander liegende Folien B N Stellen Sie sich vor, Sie haben die Folie B (Basis) auf dem Projektor und wollen daraus die Figur der Folie N (Neu) konstruieren, ohne dabei die Figur in B zu zerstören. Dafür würden Sie Folie M (Modifizierung) darüber legen. M Am Ende gibt es sowohl B als auch N. Durch Auflegen von M wird B nur „virtuell“ (nicht physisch) modifiziert.

Inkrementelles Programmieren: Analogie
Arbeit- / Kostenminimierung: Nur die Differenz muss neu gezeichnet werden. B wird wieder verwendet. Fehlervermeidung: B ist benutzt und getestet worden. Beim Neu-Zeichnen könnten Fehler entstehen. Vorteile B M N Ähnliche Vorteile erwarten wir von der inkrementellen Programmierung in der Softwareentwicklung: Software ist teuer. Wiederholte Entwicklung ist zu aufwändig. Wiederverwendbarkeit ist ein wichtiges Thema in der Softwareindustrie.

Sprachunterstützung für inkrementelles Programmieren
Notwendige Sprachkonstrukte: Definition neuer Klassen als Erben existierender Klassen durch Vererbung  das wahre neue Konzept von OOP Definition neuer Operationen und/oder Instanzvariablen Überschreiben von ererbten Operationen (Verhalten)

Definition neuer Objekttypen in Java: Person
public class Person extends Object { String name; String givenName; String address; String phoneNr; // Konstruktor for Person objects public Person(String pName, String pGivenName, String pAddress, String pPhone) { name = pName; givenName = pGivenName; address = pAddress; phoneNr = pPhoneNr; } public String getName() { // returns the Person‘s name return name; // Methods getGivenName(), setName(String) etc. Schlüsselwort für Vererbung

Definition neuer Objekttypen in Java
class <Subklasse> extends <Basisklasse> { [Liste neuer Attribute] [Liste von Konstruktoren] [Liste neuer Methoden] } Die neue Klasse „erbt“ alle Methoden und Attribute der Basisklasse und kann zusätzlich neue definieren. class Client extends Person { // ... } Ein Client ist zunächst mal eine Person. Er hat alle Eigenschaften und bietet alle Dienste einer Person an.

Definition neuer Objekttypen
public class Client extends Person { House house; // only one house for now... public Client(String name, String givenName, String address, String phone, House house) { setName(name); setGivenName(givenName); setAddress(address); setPhoneNumber(phone); this.house = house; } Vorläufige Fassung Bei der Definition neuer Dienste können bestehende Dienste benutzt werden: setName etc. von Person. this bezeichnet in Java das ausführende Objekt. Wenn klar ist, dass es um einen Methodenaufruf an this handelt, kann this auch weggelassen werden. Andere OO Sprachen haben ähnliche spezielle Bezeichner, z.B. self in Smalltalk. „this.house“ ist das Attribut des Objekts, nicht der Parameter.

Abstecher: Benennung neuer Methoden
Bedeutung und Korrektheit neuer Methoden Java versteht Methodennamen nicht, sondern führt aus Die folgende Methode ist korrekt, aber nicht erwartungskonform—und verwirrt damit Nutzer! public void getMyName() { System.err.println(myHouse); } Diese Methode sollte eher „printHouseInfo()“ heißen Folge: Intentionsfehler im Programm – Programm reagiert nicht wie erwartet. Methoden immer gemäß ihrer Bedeutung benennen!

Konstruktoren und neue Objekttypen
Erben müssen einen Konstruktor der Oberklasse aufrufen Eine Unterklasse, die keinen Konstruktor definiert, hat implizit einen parameterlosen Konstruktor, der den parameterlosen Konstruktor der Oberklasse aufruft. public class Mitarbeiter extends Person { // Implementierung ohne expliziten Konstruktor } Schlüsselwort für Zugriff auf Element des Vorfahren, hier: Konstruktor public class Mitarbeiter extends Person { Mitarbeiter() { super(); } // ... Das geht aber nur, wenn die Oberklasse einen parameterlosen Konstruktor definiert – sonst Compilefehler! (Passiert hier…)

Konstruktoren und neue Objekttypen
public class Mitarbeiter extends Person { int officeNumber; // office number public Mitarbeiter(String name, String givenName, String address, String phone, int officeNr) { super(name, givenName, address, phone); setOfficeNumber(officeNr); } // more features... // Beispiel: Instanziierung eines Mitarbeiters Mitarbeiter mueller = new Mitarbeiter("Mueller", "Tim", "Hauptstr. 10, Darmstadt", " ", 10); Person hat nur einen Konstruktor mit 4 Parametern Achtung: Anders als Methoden werden Konstruktoren nicht vererbt! Deswegen muss in Mitarbeiter ein expliziter Konstruktor implementiert werden, der den 4-parametrigen Konstruktor von Person aufruft.

Abstecher: Modellierungssprache
Modellierungssprache: eine grafische Notation (Sprache), in der wir Design-Modelle schreiben. Abstrakter als Programmiersprachen. Im Normalfall nicht ausführbar. Teile des Codes können aber aus dem Modell generiert werden. Kleiner Abstraktions-sprung Design Modell Mentales Modell modulare Struktur des Programms Kleine Repräsentations- lücke „semantic gap“ = Die Lücke zwischen gesprochener Sprache (Aufgabenbeschreibung) und Programm Maschinen-Level Compiler

Abstecher: Unified Modeling Language (UML)
Sprache und Notation für die visuelle Entwurfsbeschreibung von Modellen für Softwaresysteme Festlegung, wie ein Softwaresystem konstruiert werden soll Visualisierung, die auch für nicht-Informatiker leicht verständlich ist Dokumentation von Software Besonders wichtig, wenn ein großes System im Team entworfen wird UML bietet eine Sammlung von Diagrammtypen an, um bestimmte Aspekte der Software zu beschreiben Anwendungsfalldiagramm: Was kann welcher Akteur mit dem System machen? Klassendiagramm: Beschreibt Beziehungen zwischen Klassen Verhaltensdiagramme: Beschreiben, wie sich das System verhalten soll. Implementierungsdiagramme: Beziehungen zwischen Komponenten Wir betrachten im folgenden zunächst nur das Klassendiagramm Buch zur Einführung in OOSE und die UML: Bernd Oestereich: Objekt-Orientierte Softwareentwicklung, Oldenbourg Verlag. ISBN

Das UML Klassendiagramm
UML Notation für „Klasse“ Person Klassendiagramm: Klasseneigenschaften Attribute Methoden Beziehungen: Vererbung (Teil-von) (Abhängigkeiten) name: String … setName(String): void ... UML Notation für „erbt“ getOfficeNr(): int setOfficeNr(): void Mitarbeiter return officeNr; Vererbung ist eine transitive Relation: Manager erbt alles, was Mitarbeiter erbt (z.B. setName(String)) UML Notation für Methoden-Implementierung getSupervisedList(): … Manager

Modellierung eines Grafiksystems
Im Folgenden verlassen wir die Immobilienverwaltung Für OO-Modellierung zwar „praktisch “, aber nicht sehr interessant Stattdessen wollen wir ein Grafiksystem modellieren Bestehend aus einer Zeichenfläche und grafischen Objekten Linie, Rechteck, Oval, Polygon, … Wir kehren dafür zur Package ACM JTF zurück Siehe Foliensatz T11, Stichwort „GraphicsProgram“ Wir werden für die Modellierung ACM JTF nutzen Nehmen uns aber Zeit, selbst eine gute Modellierung zu finden Diese ist nicht unbedingt deckungsgleich mit ACM JTF Es hat niemand behauptet, das Package sei perfekt…

Nutzung von ACM JTF Grafik
ACM JTF bietet mehr als Console, Dialog und Grafikausgabe Ein (fast) komplettes Grafiksystem zum Zeichnen von Objekten Objekte werden in der Reihe ihres Erscheinens gezeichnet: Als Basis dient wieder das bewährte „GraphicsProgram“ Wir nutzen aber zusätzliche Klassen für Grafikobjekte Kreisbögen, Texte, Linien, Ovale, Rechtecke, Polygone

Grundkonzepte für Grafik mit ACM JTF
Für die Erstellung von Grafiken mit ACM JTF gilt: Genutzt wird das gleiche Ausgabefenster wie in „HelloGraphics“ Das Koordinatensystem beginnt oben links mit (0,0) Die x-Achse wächst nach rechts, die y-Achse nach unten Jede Koordinate entspricht einem Bildschirmpunkt (Pixel) Als Koordinaten können int und double Werte genutzt werden Grundkonzepte zur Erstellung von Grafiken Die Klasse GCanvas ist die Zeichenfläche Die Klasse GObject ist die Basisklasse für alle grafischen Objekte Zum Zeichnen wird ein grafisches Objekt dem GCanvas hinzugefügt Dazu dient die Methode add(GObject) der Klasse GCanvas Diese Methode ist in jedem GraphicsProgram direkt nutzbar Betrachten wir zunächst die grafischen Objekte…

Grafische Objekte: Klasse GObject
GObject ist die Basisklasse für alle Grafikobjekte So wie Person die Basisklasse für Mitarbeiter, Kunde war (T12) Besonders wichtige Methoden: double getX(), double getY(), GPoint getLocation() Liefert die X- bzw. Y-Koordinate des Objekts bzw. die Position als Punkt void setLocation(double x, double y), void setLocation(GPoint p) Setzt die Koordinate des Objekts als (x, y) oder über definierten Punkt double getWidth(), double getHeight() Liefert die Breite bzw. Höhe des Objekts GDimension getSize() Liefert die Größe des Objekts als GDimension-Objekt GRectangle getBoundingBox() Liefert das kleinste Rechteck, das das Objekt vollständig umfasst

Verschieben eines Objekts: void move(double dx, double dy), void setLocation(GPoint p) Verschiebt das Objekt um (dx, dy) bzw. setzt es an Punkt p Ruft intern setLocation(getX() + dx, getY() + dy) auf void movePolar(double r, double theta) Verschiebt das Objekt um r Einheiten Richtung theta (Winkelgrad) Farbe des Objekts auslesen oder setzen: void setColor(Color c), Color getColor() Siehe die Java-Dokumentation von java.awt.Color Meist langen die folgenden vordefinierten konstanten Farbwerte: Color.BLACK, Color.RED, Color.BLUE, Color.DARK_GRAY, Color.YELLOW, Color.MAGENTA, Color.GRAY, Color.GREEN, Color.ORANGE, Color.LIGHT_GRAY, Color.CYAN, Color.PINK, Color.WHITE Am Anfang der Klasse muss „import java.awt.Color;“ stehen

Beeinflussung der Zeichenreihenfolge Normalerweise werden „neue“ Objekte vorne gezeichnet Um das anzupassen, gibt es vier Methoden: void sendToFront(), void sendToBack() Ordnet das Objekt ganz vorne bzw. ganz hinten an void sendForward(), void sendBackward() Bringt das Objekt eine Ebene nach vorne bzw. nach hinten Testen, ob ein Punkt im Objekt enthalten ist boolean contains(double x, double y) boolean contains(GPoint p) Liefert true, wenn der Punkt im Objekt liegt, sonst false

Anzeigefläche: GCanvas
GraphicsProgram umfasst schon einen GCanvas Wesentliche Methoden in beiden Klassen: void add(GObject go) Fügt das Objekt go zum GCanvas hinzu an der Position von go void add(GObject go, double x, double y) void add(GObject go, GPoint p) Fügt das Objekt go zum GCanvas an angegebener Position hinzu void remove(GObject go) Entfernt das grafische Objekt go vom GCanvas void removeAll() Entfernt alle grafischen Objekte vom GCanvas int getWidth(), int getHeight() Liefert die Breite bzw. Höhe des GCanvas

Anzeigefläche: GCanvas
void setBackground(Color bgColor) Setzt die Hintergrundfarbe auf bgColor GObject getElementAt(double x, double y) GObject getElementAt(GPoint p) Liefert das oberste Element, zu dem Punkt (x, y) bzw. p gehört Ruft contains(x, y) bzw. contains(p) auf allen Objekten auf Beispiel (T11, Folie 20): // Anlege eines Objekts: GLabel fuer Texte GLabel label = new GLabel("hello, world"); // neuer Text // Schriftart zuweisen label.setFont("SansSerif-100"); // Font: ohne Serifen // Position berechnen und zum GCanvas hinzufuegen double x = (getWidth() - label.getWidth()) / 2; // mittig double y = (getHeight() + label.getAscent()) / 2; // mittig add(label, x, y); // Text hinzufuegen zum GCanvas

Beispiel: zwei Objekte auf der Zeichenfläche
import java.awt.Color; // fuer Farben import acm.graphics.GOval; // fuer das Oval import acm.graphics.GRect; // fuer das Rechteck import acm.program.GraphicsProgram; // Hauptklasse public class FeltBoard extends GraphicsProgram { public void run() {/** Runs the program */ GRect rect = new GRect(100, 50, 100, 100 / PHI); // Rechteck def. rect.setFilled(true); // ist gefuellt... rect.setColor(Color.RED); // ...mit Farbe rot add(rect); // zum GCanvas hinzu GOval oval = new GOval(150, / PHI, 100, 100 / PHI); oval.setFilled(true); // ebenfalls gefuellt... oval.setColor(Color.GREEN); // aber gruen add(oval); // zum GCanvas hinzu }

Beispiel: zwei Objekte auf der Zeichenfläche
/** Constant representing the golden ratio */ public static final double PHI = 1.618; /* Standard Java entry point */ /* This method can be eliminated in most Java environments */ public static void main(String[] args) { new FeltBoard().start(args); } Ausgabe (siehe Folie 27): Da das Rechteck „älter“ ist, liegt es hinter dem später eingefügten Oval.

Vorhandene Unterklassen von GObject
GLine: Linie aus zwei Punkten GLine(double x1, double y1, double x2, double y2) Legt die Linie von (x1, y1) nach (x2, y2) an GPoint getStartPoint() GPoint getEndPoint() Liefert den Start- bzw. Endpunkt der Linie GOval: ovale Form GOval(double x, double y, double w, double h) Oval mit linker oberer Ecke (x, y) und Radien w bzw. h GLabel: Text GLabel(String text, double x, double y) Text „text“ beginnend an Punkt (x, y) mit Basislinie y

GArc: Kreisbogen; wie Oval, aber mit Start-/Endwinkel GArc(double x, double y, double w, double h, double start, double sweep) Bogen mit linker oberer Ecke der Bounding Box an (x, y), Radien w bzw. h, Startwinkel start und Umfang sweep in Grad Weitere Methoden zum Abfragen oder Setzen der Winkel GPolygon: Polygon mit beliebig vielen Knoten GPolygon(double x, double y) Legt Polygon an Startposition ohne Knoten an GPolygon(GPoint[] points) Legt Polygon mit Startknoten aus dem Array an addEdge(double x, double y) Fügt Kante vom letzten Knoten zu (x, y) hinzu void markAsComplete() Polygon als „fertig“ markieren; kein Hinzufügen mehr möglich

GRect: Rechteck in drei Varianten GRect(double x, double y, double w, double h) Legt Rechteck mit Knoten (x,y) und (x+w, y+h) an G3DRect(double x, double y, double w, double h) Legt Rechteck mit „3D-Effekt“ an Zusatzparameter: boolean raised; wenn true, „erhöht“ gezeichnet GRoundRect(double x, double y, double w, double h) Rechteck mit abgerundeten Ecken Zusatzparameter: double arcSize – Größe des Bogens der Kanten double arcWidth, double arcHeight – Individuelle Bogengröße GImage: Einbinden von Bildern GImage(Image image, double x, double y) Legt ein Bild an; vorerst nicht weiter betrachtet

Exkurs: Zeichnen von GObject-Instanzen
Das Zeichnen von GObject-Instanzen erfolgt intern Methode void paint(Graphics g), definiert in Klasse GObject Graphics ist eine umfangreiche Klasse aus java.awt Bitte konsultieren Sie die Java API Dokumentation für Details! Zeichnen des Rechtecks (leicht vereinfacht) mit Graphics: public void paint(Graphics g) { // Zeichne Rechteck ab (x, y) mit Breite u. Hoehe g.drawRect(getX(), getY(), getWidth(),getHeight()); } Zeichnen eines Quadrats (leicht vereinfacht) mit Graphics: // Zeichne Quadrat ab (x, y) mit passender Groesse g.drawRect(getX(), getY(), size, size);

Finden der „passenden“ Vererbungshierarchie
Die Bestimmung der „passenden“ Modellierung ist nicht immer offensichtlich Als Beispiel betrachten wir die folgenden Klassen als Teil eines Zeichensystems: Punkt (GPoint) Rechteck (GRect) Gegebenfalls zusätzlich noch die Klasse Quadrat (GSquare) Wir betrachten nun verschiedene Modellierungen Dabei begründen wir, warum die Modellierung (nicht) „gut“ ist

Modellierung I: Punkt als Basisklasse
Keine gute Modellierung GPoint GRect Überlegung: „jedes grafische Objekt besteht aus mindestens einem Punkt“ Regel 1 der Vererbung: der Erbe ist eine Spezialisierung Ist ein „Rechteck ein spezieller Punkt“? Was wir eigentlich meinten, war: ein Rechteck hat (mindestens) einen Punkt Nutze einen GPoint als Attribut, nicht als Oberklasse Siehe Regel 2 der Vererbung: „ist-ein“ vs. „hat-ein“

Modellierung II: Punkt neben Rechteck
Punkt sollte nicht die Basisklasse von Rechteck sein Andere grafische Objekte scheiden ebenso aus wie Punkt Wir definieren eine allgemeine Basisklasse „GObject“ Diese repräsentiert kein konkretes Objekt Konkrete Methoden wie paint lassen wir in GObject leer Sammelt gemeinsame Funktionalität aller grafischen Objekte Die konkreten Aufgaben, etwa das Zeichnen, leisten die Erben GObject GPoint GRect

Modellierung III: Rechteck und Quadrat
Wie modellieren wir Rechteck und Quadrat? Ein Quadrat ist spezieller als ein Rechteck Daher könnten wir Quadrat als Erbe von Rechteck deklarieren GObject GPoint GRect Ist das eine gute Modellierung? GSquare

Modellierung III: Rechteck als Basis für Quadrat
Achtung: Regel 3 und 5 der Vererbung 3: „Neue Klasse erbt alle Methoden und Attribute der Basisklasse“ 5: „Verhalten überschriebener Methode muss zu Vorfahr passen“ Quadrat erbt also alle Attribute und Methoden von Rechteck Damit auch die beiden Punkte oben links, unten rechts Sowie Methoden wie setWidth(double), setHeight(double) Wie stellen wir sicher, dass die Form quadratisch ist? Wie ändern wir die Methode zur Änderung der Größe? Rechteck: zwei Zahlen oder ein Dimension-Objekt Quadrat: eine Zahl Die geerbte Methode von Rechteck muss es weiterhin geben Wir können Sie höchstens „umschreiben“: public void setSize(double w, double h) { setSize((w + h) / 2); } Entspricht nicht der Vorstellung des Benutzers  Regel 5

Modellierung IV: Rechteck erbt von Quadrat
Wie ist es umgekehrt: Rechteck erbt von Quadrat? Rechteck übernimmt Größe und „fügt zweite Größenangabe hinzu“ void setSize(double size) { setSize(size, size); } Prinzipiell ist das möglich und verstößt nicht gegen Regel 3 und 5 Aber: ein Rechteck ist eine Verallgemeinerung von Quadrat, eben keine Spezialisierung! Diese Vererbung ist also auch nicht geeignet Daher ordnen wir GSquare parallel zu GPoint, GRect ein

Verwendung neuer Objekttypen
Wir erweitern unsere Klasse FeltBoard (Folie 34-35): // Code bis Ende Methode "run" wie bisher add(oval); // zum GCanvas hinzu // neu: es kommt ein GSquare hinzu GSquare square = new GSquare(120, 80, 60); square.setColor(Color.BLACK); add(square); // Rest wie gehabt...

Funktionsvorlagen & Abstrakte Klassen
Betrachten wir die Klasse GObject einmal genauer Die Klassen GPoint, GRect und GSquare erben von GObject Dazu zählt auch die Methode void paint(Graphics g) Wie implementiert man diese Methode für ein allgemeines GObject? Wir wissen hier gar nicht, was für eine Art von Objekt dies sein soll! Für solche Fällen können Klassen Operationen deklarieren, die in der Klasse nicht implementiert werden. Solche Operationen werden abstrakte Methoden genannt. Klassen, die mindestens eine abstrakte Methode deklarieren, werden abstrakte Klassen genannt. Im Folgenden werden wir zeigen, wie abstrakte Klassen Wiederverwendung unterstützen, wenn ähnliche, aber nicht identische Aufgaben implementiert werden.

Abstrakte Klassen: GObject
GObject repräsentiert beliebige grafische Objekte Also nichts konkretes wie einen Kreis, Quadrat, nur eine Vorlage GObject liefert allgemeine Funktionalität für alle Erben Setzen und Abfragen der Koordinate und Farbe Abfragen der Grenzen (bounds) Zeichnen des Objekts mittels paint(Graphics) Nicht alle Methoden können implementiert werden Wie kann man eine „Vorlage“ zeichnen? Als Kreis, Quadrat, …? Wie kann man für eine Vorlage die Grenzen angeben? Wie geht man mit dieser Situation um? Was wollen wir? Jeder konkrete Erbe muss die beiden Methoden implementieren Die Überprüfung muss durch Java forciert werden, nicht nur durch (eventuell ignorierte) Kommentare im Quelltext

Behandlung nicht-konkreter Methoden
Möglichkeit 1: wir lassen diese Methoden in GObject leer public void paint(Graphics g) { } Die Methode ist implementiert, aber ohne Funktionalität Erben sollten paint implementieren, Java erzwingt das aber nicht Möglichkeit 2: wir implementieren sie „irgendwie“ Z.B. mit Ausgabe einer Fehlermeldung bei Aufruf, „damit der Erbe sieht, dass das falsch war“ Klassen compilieren normal, der Endkunde sieht dann die Fehler Wenn die Konsole nicht einfach minimiert wurde… Das Programm verhält sich u.U. falsch Je nach Implementierung von getBounds() liefert getElementsAt() die falschen Objekte

Abstrakte Methoden und Klassen in Java
Eine „nicht-konkrete“ Methode heißt abstrakt Markiert in Java durch abstract vor dem Rückgabetyp Abstrakte Methoden werden nur deklariert Statt den geschweiften Klammern steht ein Semikolon ; public abstract void paint(Graphics g); Eine Klasse mit mindestens einer abstrakten Methode muss ebenfalls als abstract deklariert werden public abstract class GObject { ... } Da die Klasse damit unvollständig ist, kann kein Objekt dieses Typs angelegt werden GObject go = new GObject(); // Fehler!

Abstrakte Klassen und ihre Erben
Der Erbe einer abstrakten Klasse… erbt die Deklarationen aller abstrakten Methode(n) kann abstrakte Methoden implementieren Siehe getBounds() und paint(Graphics) in GSquare Falls nicht alle abstrakten Methoden implementiert werden, bleibt auch der Erbe abstract Selbst wenn die Methode nicht explizit im Klassenquelltext als „abstract“ auftaucht, wir also etwa „getBounds()“ in GSquare einfach weglassen Die konkrete Implementierung aller abstrakten Methoden erzeugt eine vollständig implementierte Klasse… …von der dann konkrete Instanzen als Objekt existieren können

Nutzung abstrakter Klassen
Denken wir kurz an den Code auf Folie 35f zurück: // ... public void run() { // s. Folie 35 und 36 GRect rect = new GRect(100, 50, 100, 100 / PHI); rect.setFilled(true); rect.setColor(Color.RED); add(rect); GOval oval = new GOval(150, /PHI, 100, 100/PHI); oval.setFilled(true); oval.setColor(Color.GREEN); add(oval); } Die markierte Methode setColor wurde unverändert aus GObject geerbt Methode add ruft (unsichtbar) die Methode paint auf

Abstrakte Klassen Gemeinsamkeiten in der gemeinsamen Superklasse GObject Methode contains(double, double) testet, ob ein Punkt im Objekt enthalten ist; nutzt getBounds() getBounds() ist aber abstrakt abstract class GObject extends Object{ //Konstruktor (versteckt) boolean contains(double x, double y){ return getBounds().contains(x, y); } abstract GRectangle getBounds(); Schablone-Operation (engl. „template method“. Ruft primitive abstrakte Operationen auf Unimplementierte Operation. Wird hier nur deklariert; bedeutet „alle GObjects bieten den Dienst getBounds() an“. Es ist aber nicht möglich, eine gemeinsame Implementierung anzugeben.

Erben von abstrakten Klassen
GRect und GSquare instanziieren die Vorlage unterschiedlich class GRect extends GObject{ double frameWidth, frameHeight; // Konstruktor etc... GRectangle getBounds() { return new GRectangle(getX(), getY(), frameWidth + 1, frameHeight + 1); } Nutze Breite und Höhe für das Ergebnis class GSquare extends GObject{ double frameSize; // Konstruktor etc... GRectangle getBounds() { return new GRectangle(getX(), getY(), frameSize + 1, frameSize + 1); } Nutze die Größe beide Mal für das Ergebnis

Abstrakte Klassen in UML
UML-Notation für abstrakte Klassen UML-Notation für abstrakte Methoden GObject contains(double, double): boolean getBounds(): GRectangle GRect getBounds(): GRectangle GSquare getBounds(): GRectangle

Modellierung V: Entkopplung der Klassen
Analog zu Punkt und Rechteck können wir Rechteck und Quadrat entkoppeln Ist das eine gute Modellierung? GObject GPoint GRect GSquare Das funktioniert problemlos Gemeinsamkeiten von Rectangle und Square verschwinden Beispielsweise können beide gefüllt sein und eine Füllfarbe besitzen Ein Punkt hingegen hat die Funktionalität nicht.

Implementierung von GSquare
Worauf ist beim Implementieren von GSquare zu achten? Die Methode drawRect erwartet vier Parameter vom Typ int  Runden der Koordinaten und Konvertieren nach int Wir müssen Konstruktoren für GSquare definiert Sonst kann kein neues Objekt angelegt werden! Wir definieren zwei Konstruktoren: Angabe nur der Größe—die Startkoordinate ist damit (0, 0) Angabe von Startpunkt und Größe Die Lösung der meisten dieser Probleme ist einfach Siehe die beiden nächsten Folien für den Code

Kompletter Code für GSquare
package acm.graphics; // Gehoert zum Package acm.graphics import java.awt.Graphics; // benoetigt fuer paint(Graphics) public class GSquare extends GObject { // abgeleitet von GObject private double frameSize; // Groesse des Quadrats public GSquare(double size) { // Anlegen ohne Koord. -> (0, 0) this(0, 0, size); // Anderen Konstruktor aufrufen } public GSquare(double x, double y, double size) { frameeSize = size; // Groesse speichern setLocation(x, y); // Position setzen (von GObject) public double getSquareSize() { // Groesse des Quadrats liefern return frameSize; // Groesse zurueckgeben

Kompletter Code für GSquare
public GRectangle getBounds() { // Box berechnen return new GRectangle(getX(), getY(), frameSize+1, frameSize + 1); } public void paint(Graphics g) { // Zeichnen g.drawRect((int)GMath.round(getX()), (int)Math.round(getY()), (int)Math.round(frameSize), (int)Math.round(frameSize)); Entsprechend können weitere Typen definiert werden wie GTriangle

Modellierung VI: Abstraktes GFillableObject
Wir können eine abstrakte Klasse für gefüllte Objekte definieren mit folgenden Eigenschaften: boolean isFilled Color fillColor boolean isFilled(), void setFilled(boolean filled) Color getFillColor(), void setFillColor(Color c) Alle Methoden sind implementierbar und vererbbar GObject GPoint GFillableObject Ist das eine gute Modellierung? GRect GSquare

Modellierung VI: Abstraktes GFillableObject
Prinzipiell ist diese Struktur sauber und funktioniert Aber: alle gefüllten Strukturen müssen nun von der Klasse GFillableObject oder einer Subklasse erben Wir können also nicht (sauber!) etwas entwerfen, … … dass über eine Füllfarbe verfügt und optional gefüllt ist … dass das Setzen der Füllfarbe und des Status erlaubt … also identisch aussieht zu einem Erben von GFillableObject … … aber nicht von GFillableObject erbt Etwa, weil es eine Spezialisierung eines anderen Typs ist Damit verbauen wir uns den Weg für spätere Klassen Wir brauchen ein passendes Konzept, mit dem wir die Einfachvererbung von Java „umgehen“ können Auch wenn dies eventuell etwas Code-Redundanz erzeugt. Beispiel: wir wollen ein immer gefülltes Rechteck erstellen. Kann dieses von GRect erben?  Dann wäre die Füllung „abschaltbar“!

Schnittstellen (engl. Interfaces)
Schnittstellen deklarieren Operationen (Dienste), ohne diese zu implementieren Eine Schnittstelle besteht nur aus Operationen-Signaturen: Rückgabetyp, Name der Operation, Liste der formalen Parameter und deren Typen Funktionale Abstraktion: das Was, aber nicht das Wie Trennung der Typdeklaration von Implementierung Java syntax +operation(): void <<interface>> AnInterface UML Notation interface AnInterface { public void operation(); }

Implementierung der Schnittstellen
Eine Klasse, die eine Schnittstelle implementiert: muss entweder alle dort deklarierten Operationen implementieren oder als abstract deklariert werden Die implementierenden Operationen behalten die Signatur der Schnittstelle bei und müssen public sein kann zusätzliche Operationen definieren Mehrere Java-Klassen können dieselbe Schnittstelle auf verschiedene Weisen implementieren. In Java kann eine Klasse mehrere Schnittstellen implementieren. Aber nur von einer Klasse erben!

Implementierung der Schnittstellen
<<interface>> AnInterface ClientClass <<interface>> AnotherInterface ruft auf operation(): void UML Notation für implements AnInterface wird von ImplClass1 und ImplClass2 implementiert. ImplClass1 ImplClass2 +operation(): void +operation(): void class ImplClass1 implements AnInterface { public void operation () { // ... }

Schnittstellenvererbung
i n t e r f a c e Jede Schnittstelle kann von einer oder mehreren Superschnittstellen erben (Schlüsselwort extends). Eine Klasse AClass, die eine Schnittstelle B implementiert, muss alle darin (und in den Superschnittstellen) deklarierten Operationen implementieren. Sonst ist AClass weiter abstract A operation1() operation2() i n t e r f a c e B operation3() interface B extends A { public void operation3(); } AClass operation1() operation2() operation3()

Variablen vom Schnittstellentyp
Analog zu Variablen vom Klassentyp können auch Variablen vom Schnittstellentyp deklariert werden Achtung: Schnittstellentypen können nicht instanziiert werden! class AnInterfaceClient { AnInterface aVariableName; // ... void someOperation() { aVariableName = new AnInterface(); aVariableName = new ImplClass1(); aVariableName.operation(); } Fehler OK Eine Klasse, die Schnittstellentypen für die Deklaration einiger Variablen verwendet, kann wieder verwendet werden, solange die Variablen Objekte enthalten, deren Klassen die Schnittstelle implementieren.

Schnittstellen und (abstrakte) Klassen
Abstrakte Klassen  gemeinsame Funktionalität ist zu definieren Schnittstellen  es gibt einen gemeinsamen Typ, aber kein gemeinsames Verhalten Eine Klasse kann nur von einer direkten Superklasse erben (Einfachvererbung)  der Missbrauch abstrakter Klassen als Schnittstellen hat einen wichtigen Effekt! Randnotiz: Es gibt Programmiersprachen, in denen eine Klasse von mehreren Superklassen erben kann (Mehrfachvererbung). Hierbei treten oft Probleme mit Namenskonflikten auf, wenn gleiche Namen über verschiedene Vererbungspfade geerbt werden. Bis dato gibt es keine zufriedenstellende Implementierung

Schnittstellen und (abstrakte) Klassen
Einfachvererbung zwingt Objekten ein einzelnes Klassifikationsschema auf. Die Nutzung von Schnittstellen entspannt diese Situation etwas: Rechtecke kann man füllen und skalieren Quadrate kann man füllen, aber nicht skalieren Punkte kann man weder füllen noch skalieren interface GFillable { // for fillable objects boolean isFilled(); void setFilled(boolean b); Color getFillColor(); void setFillColor(Color fillColor); } interface GScalable { // for scaling by one or separate factors void scale(double factor); void scale(double scaleX, double scaleY); class GRect extends GObject implements GFillable, GScalable ... class GSquare extends GObject implements GFillable... class GPoint extends GObject...

Modellierung VII: Nutzung von Schnittstellen
Wir deklarieren eine Schnittstelle GFillable Diese deklariert die Methoden zum Abfragen und Setzen des Füllstatus und der Füllfarbe Konsequenzen für Implementierer von GFillable: Die Methoden müssen selbst implementiert werden  Redundanz Dafür besteht freie Wahl bei der Oberklasse  Flexibilität GSquare <<interface>> GFillable GPoint GRect GObject

Modellierung: Fazit Die Wahl der „richtigen“ Oberklasse ist nicht offensichtlich Je nach Ziel und Kontext fällt die Wahl verschieden aus Mehrere Modellierungen waren nicht ratsam Modellierung I: Punkt als Basisklasse für Rechteck Ein Rechteck ist kein Punkt, sondern hat (mehr als) einen Punkt Modellierung II: Konkrete Klasse GObject mit leerem paint() Es gibt keine Garantie, dass alle Erben diese Methode implementieren Modellierung III: Quadrat erbt von Rechteck Einige der geerbten Attribute und Methoden sind „überflüssig“ und können für Probleme sorgen, etwa setWidth(double) Modellierung IV: Rechteck erbt von Quadrat Rechteck ist Verallgemeinerung, keine Spezialisierung, von Quadrat Modellierung VI: abstrakte Klasse GFillableObject Durchaus denkbar, schränkt aber die Vererbung sehr ein

Überschreibung ererbter Methoden
Methodenüberschreibung (engl. „method overriding“) geschieht, wenn zwei Methoden mit dem selben Namen, der gleichen Parameterzahl, und den gleichen Parametertypen in verschiedenen Klassen definiert werden, und eine die Superklasse der anderen ist. Synonym für Verdecken Warum ist das sinnvoll? Weil das Verhalten vorhandener Typen nur beinahe dem gewünschten entspricht. Spezialisierung ist nicht reine Erweiterung… Rechtecke und Quadrate erben die Fähigkeit gezeichnet zu werden von einem gemeinsamen Vorfahren, werden aber auf verschiedene Art gezeichnet… B M N

Überschreiben ererbter Methoden
Die Methode paint in GRect nutzt die Methoden getColor(), getFillColor() class GRect extends GObject implements ...{ // Konstruktor etc... void paint(Graphics g) { Rectangle r = getAWTBounds(); if (isFilled()) { g.setColor(getFillColor()); g.fillRect(r.x, r.y, r.width, r.height); g.setColor(getColor()); } g.drawRect(r.x, r.y, r.width, r.height); Wir schreiben ein „komisches Rechteck“, das diese Methoden modifiziert class GStrangeRect extends GRect { // Konstruktor etc. Color getFillColor() { setColor(Color.BLUE); // ! return super.getFillColor(); } Erwähne, dass in diesem Fall ein if-Block von Nöten ist Was passiert hier?

Überschreiben geerbter Methoden
„Alte“ Methode sind außerhalb der Neudefinition nicht zugreifbar! Verwendung der gerade überschriebenen Operation (z.B. der paint-Operation für den Obertyp) innerhalb der Neudefinition durch super Informell gesprochen: „rufe die getFillColor() Version der GRect Variante von mir auf“ class GStrangeRect extends GRect { // ... Color getFillColor () { setColor(Color.BLUE); return super.getFillColor(); } Erwähne, dass in diesem Fall ein if-Block von Nöten ist Technisch gesprochen: „Führe die erste Implementierung von getFillColor() aus, die entlang der Kette meiner Ahnen existiert.“

Auswahl einer Methode beim Operationsaufruf
Bei dem Aufruf einer Operation OP an einem Objekt obj vom Typ ObjType muss eine entsprechende Methode ausgewählt und ausgeführt werden („method dispatch“). In OO Sprachen werden die Operationsnamen dynamisch an Methoden gebunden. class GStrangeRect extends GRect { // Konstruktor etc. … // Verfaerbt sich vor dem Zeichnen void getFillColor() { setColor(Color.BLUE); return super.getFillColor(); } Achtung! Was passiert beim Aufruf von paint(g)?

Überschreiben von getFillColor() in GStrangeRect führt dazu, dass auch paint() sich seltsam verhält, wenn GStrangeRect es ausführt. Die Frage ist, warum? public void run() { // inside FeltBoard (slide 35+) GRect rect = new GRect(100, 50, 100, 100 / PHI); rect.setFilled(true); rect.setColor(Color.RED); add(rect); // ruft mittelbar paint(g) auf GStrangeRect rect2 = new GStrangeRect(130,80,100,100/PHI); rect2.setFilled(true); rect2.setColor(Color.RED); add(rect2); // ruft mittelbar paint(g) }

GRect getFillColor(): Color paint(Graphics): void ... Jedes Objekt kennt die eigene Klasse GStrangeRect getFillColor(): Color rect2 Klasse Erste Regel: Die Suche nach einer Implementierung für eine Operation beginnt in der Klasse des Empfängers und verläuft entlang der Vererbungshierarchie, bis eine Implementierung gefunden wird [oder in dynamisch typisierten Sprachen die Wurzel der Hierarchie erreicht wurde].

Aufruf der Methode paint(Graphics)
GRect getFillColor(): Color paint(Graphics): void ... if (isFilled) { g.setColor( getFillColor()) ... run() Klasse paint(g) GStrangeRect getFillColor(): Color rect Der Aufruf von rect.paint(g) nutzt die Methode paint(g) in GRect Der Aufruf von getFillColor() geht wieder an den Typ GRect

Aufruf der Methode paint(Graphics)
GRect getFillColor(): Color paint(Graphics): void ... if (isFilled) { g.setColor( getFillColor()) ... run() paint(g) GStrangeRect getFillColor(): Color Klasse setColor(Color.BLUE); return super.getFillColor(); rect2 Aufruf von rect2.paint(g) sucht die Methode paint(g) in GStrangeRect Da sie dort nicht überschrieben wurde, nutzt man den Code von GRect Der Aufruf von getFillColor geht wieder an das Objekt rect2 Dieses nutzt nun die überschriebene Methode und setzt die Farbe um Am Ende wird noch die Methode aus super aufgerufen

Überschreiben geerbter Methoden
Die Klasse GStrangeRect überschreibt die geerbte Methode getFillColor Die Methode in der Klasse GRect bleibt unverändert bestehen Der Methodenname getFillColor wird nicht „für immer“ an den Code der Klasse GRect gebunden! Die Bindung erfolgt dynamisch: Java sucht bei Methodenaufrufen ausgehend vom Laufzeittyp des Objekts nach der ersten „passenden“ Implementierung Daher wird bei Aufruf von rect2.paint(g) Für paint(g) der Code aus Klasse GRect genutzt Für die dort aufgerufene Methode der Laufzeittyp bestimmt Das ist GStrangeRect (da wir auf rect2 arbeiten) Dann wird die erste passende Methode genutzt Die stammt wiederum aus GStrangeRect Erwähne, dass in diesem Fall ein if-Block von Nöten ist

Dynamische Bindung der Methoden
run() Die Bindung erfolgt erst während der dynamischen Ausführung einer Aufgabe. Sie hängt ab vom Typ des Objekts, das die Nachricht bekommt. paint(g) GRect getFillColor(): Color paint(Graphics): void ... rect Klasse GStrangeRect getFillColor(): Color rect2 Klasse

Bindung von super-Aufrufen
GRect getFillColor(): Color paint(Graphics): void ... if (isFilled) { g.setColor( getFillColor()) ... run() paint(g) GStrangeRect getFillColor(): Color Klasse setColor(Color.BLUE); return super.getFillColor(); rect2

Bindung von this- und super-Aufrufen
Zweite Regel: Die Suche für eine Implementierung für super-Aufrufen beginnt in der Super-Klasse der Klasse, in der der Aufruf sich befindet. Aufrufe über this werden spät (dynamisch) gebunden Aufrufe über super werden früh (statisch) gebunden

Zusammenfassung Klassen können die Definition anderer Klassen erben, überschreiben und erweitern Die wahre Neuigkeit der OOP Unterstützt inkrementelles Programmieren  Wiederverwendbarkeit Abstrakte Klassen ermöglichen die Definition von Funktionsvorlagen  Wiederverwendbarkeit Schnittstellen trennen Typdeklarationen von Implementierungen Operationsnamen werden dynamisch an Implementierungen gebunden Der Typ des Empfängers bestimmt die Auswahl Gilt auch für Operationen an this Operationen an super werden statisch an die nächste Implementierung gebunden

Grundlagen der Informatik 1

Ähnliche Präsentationen

Präsentation zum Thema: "Grundlagen der Informatik 1"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Grundlagen der Informatik 1

Ähnliche Präsentationen

Präsentation zum Thema: "Grundlagen der Informatik 1"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback