Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik 1 Thema 13: Vererbung, Funktionsvorlagen,

Telecooperation/RBG

Technische Universität Darmstadt

Copyrighted material; for TUD student use only

Grundlagen der Informatik 1

Thema 13: Vererbung, Funktionsvorlagen, Späte Bindung

Dr. G. RößlingProf. Dr. M. Mühlhäuser

RBG / Telekooperation©

Grundlagen der Informatik I: T13

• 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

Inhaltsverzeichnis

2




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),…

3




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– 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.

4




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 Person5




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

6




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

7




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

8




Motivation für neue Objekttypen• Motivation / Vorteile:

– Komplexere Aktionen pro Befehl– Nähe zur natürlichen Sprache – Einfacher zu verstehen und ggf. zu korrigieren

9

Mentales Modell Design Modell

niedriger Abstraktions-

versatz

modulare Struktur des Programms

schmale Repräsentations-

Lücke

Maschinenebene

Compiler






Inhaltsverzeichnis

10




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)

11

Eine neue Programmkomponente N wird konstruiert, indem man spezifiziert, wie sie sich von einer bestehenden Komponente B unterscheidet, ohne B dabei zu modifizieren.

Eine neue Programmkomponente N wird konstruiert, indem man spezifiziert, wie sie sich von einer bestehenden Komponente B unterscheidet, ohne B dabei zu modifizieren.




Inkrementelles Programmieren: Analogie

12

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.

B

M

N

Übereinander liegende Folien

Am Ende gibt es sowohl B als auch N. Durch Auflegen von M wird B nur „virtuell“ (nicht physisch) modifiziert.




Inkrementelles Programmieren: Analogie

13

B

MN

Vorteile• 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.

• Ä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ürinkrementelles 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)

14






Inhaltsverzeichnis

15




Definition neuer Objekttypen in Java: Person

16

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

17

Die neue Klasse „erbt“ alle Methoden und Attribute der Basisklasse und kann zusätzlich neue definieren.

class <Subklasse> extends <Basisklasse> { [Liste neuer Attribute] [Liste von Konstruktoren] [Liste neuer Methoden]}

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

18

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; }}

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.

Vorläufige

Fassung




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! 19




Konstruktoren und neue Objekttypen

20

• 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}

public class Mitarbeiter extends Person { Mitarbeiter() { super(); } // ...}

Das geht aber nur, wenn die Oberklasse einen parameterlosen Konstruktor definiert – sonst Compilefehler! (Passiert hier…)

Schlüsselwort für Zugriff auf Element des Vorfahren, hier: Konstruktor




Konstruktoren und neue Objekttypen

21

• 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.

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, 64289 Darmstadt", "06151-1234567", 10);




Abstecher: Modellierungssprache

22

Mentales Modell

Kleiner Abstraktions-

sprung Design Modell

modulare Struktur des Programms

Kleine Repräsentations-

lücke

Maschinen-Level

Compiler

• 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.




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

23




Das UML Klassendiagramm

24

UML Notationfür Methoden-Implementierung

getOfficeNr(): intsetOfficeNr(): void

return officeNr;

getSupervisedList(): …

UML Notationfür „erbt“

UML Notationfür „Klasse“ name: String

…setName(String): void...

Person

Mitarbeiter

Manager

Vererbung ist eine transitive Relation: Manager erbt alles, was Mitarbeiter erbt (z.B. setName(String))

Klassendiagramm:•

Klasseneigenschaften- Attribute- Methoden

• Beziehungen:- Vererbung- (Teil-von)-

(Abhängigkeiten)






Inhaltsverzeichnis

25




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…26




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

27




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…

28




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

29





• 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

30





• 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

31




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

32




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

33




Beispiel: zwei Objekte auf der Zeichenfläche

import java.awt.Color; // fuer Farbenimport acm.graphics.GOval; // fuer das Ovalimport acm.graphics.GRect; // fuer das Rechteckimport 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, 50 + 50 / PHI, 100, 100 / PHI); oval.setFilled(true); // ebenfalls gefuellt... oval.setColor(Color.GREEN); // aber gruen add(oval); // zum GCanvas hinzu

}

34




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ätereingefügten Oval.

35




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

36




Vorhandene Unterklassen von GObject• 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

37




Vorhandene Unterklassen von GObject

• 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

38




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. Hoeheg.drawRect(getX(), getY(), getWidth(),getHeight());

}

• Zeichnen eines Quadrats (leicht vereinfacht) mit Graphics:public void paint(Graphics g) {// Zeichne Quadrat ab (x, y) mit passender Groesseg.drawRect(getX(), getY(), size, size);

}39






Inhaltsverzeichnis

40




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

41




Modellierung I: Punkt als Basisklasse

• Ü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“ 42

GPoint

GRect

Keine gute Modellierung




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

43

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

44

GSquare

GObject

GPoint GRect

Ist das eine gute Modellierung?




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 545




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

46




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 hinzuGSquare square = new GSquare(120, 80, 60);square.setColor(Color.BLACK);add(square);// Rest wie gehabt...

47






Inhaltsverzeichnis

48




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.

49




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

50




Behandlung nicht-konkreter Methoden

• Möglichkeit 1: wir lassen diese Methoden in GObject leerpublic 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

51




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 werdenpublic abstract class GObject { ... }

• Da die Klasse damit unvollständig ist, kann kein Objekt dieses Typs angelegt werdenGObject go = new GObject(); // Fehler!

52




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önnen53




Nutzung abstrakter Klassen

54

// ... 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, 50 + 50/PHI, 100, 100/PHI); oval.setFilled(true); oval.setColor(Color.GREEN); add(oval);}// ...

• Denken wir kurz an den Code auf Folie 35f zurück:

• 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

55

abstract class GObject extends Object{ //Konstruktor (versteckt)

boolean contains(double x, double y){ return getBounds().contains(x, y);

} abstract GRectangle getBounds();}

Unimplementierte Operation. Wird hier nur deklariert; bedeutet „alle GObjects bieten den Dienst getBounds() an“. Es ist aber nicht möglich, eine gemeinsame Implementierung anzugeben.

Schablone-Operation (engl. „template method“. Ruft primitive abstrakte Operationen auf




Erben von abstrakten Klassen

56

class GRect extends GObject{ double frameWidth, frameHeight; // Konstruktor etc... GRectangle getBounds() { return new GRectangle(getX(), getY(), frameWidth + 1, frameHeight + 1); }}

class GSquare extends GObject{ double frameSize; // Konstruktor etc... GRectangle getBounds() { return new GRectangle(getX(), getY(), frameSize + 1, frameSize + 1); }}

GRect und GSquare instanziieren die Vorlage unterschiedlich

Nutze Breite und Höhe für das Ergebnis

Nutze die Größe beide Mal für das Ergebnis




Abstrakte Klassen in UML

57

GRectgetBounds(): GRectangle

GSquaregetBounds(): GRectangle

UML-Notation für abstrakte Klassen

UML-Notation für abstrakte Methoden

GObject

contains(double, double): booleangetBounds(): GRectangle




Modellierung V: Entkopplung der Klassen

• Analog zu Punkt und Rechteck können wir Rechteck und Quadrat entkoppeln

58

GSquare

GObject

GPoint GRect

• 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 dieser meisten Probleme ist einfach– Siehe die beiden nächsten Folien für den Code

59




Kompletter Code für GSquarepackage 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 speichernsetLocation(x, y); // Position setzen (von GObject)

}

public double getSquareSize() { // Groesse des Quadrats liefernreturn frameSize; // Groesse zurueckgeben

}60




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

61






Inhaltsverzeichnis

62




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

63

GSquare

GFillableObjectGPoint

GRect

GObject





Modellierung VI: Abstraktes GFillableObject

• Prinzipiell ist diese Struktur sauber und funktioniert

• Aber: alle gefüllten Strukturen müssen nun von der Klasse GFilledObject 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

GFilledObject …– … aber nicht von GFilledObject 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.

64




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

65

+operation(): void

<<interface>> AnInterface

UML Notation Java syntax

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!

66




Implementierung der Schnittstellen

67

ClientClassruft auf

ImplClass1

AnInterface wird von ImplClass1

und ImplClass2 implementiert. ImplClass2

<<interface>> AnInterface

<<interface>>AnotherInterface

operation(): void

+operation(): void+operation(): void

UM

L Nota

tion

für im

ple

ments

class ImplClass1 implements AnInterface {

public void operation () { // ... }}




Schnittstellenvererbung

• 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

68

«interface»A

«interface»B

AClass

operation1()operation2()

operation3()

operation1()operation2()operation3()

interface B extends A {

public void operation3();

}




Variablen vom Schnittstellentyp

69

• 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(); }}

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.

Fehler

OK




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 Implementierung70




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

71

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

72

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

73






Inhaltsverzeichnis

74




Ü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…

75

B

MN




Überschreiben ererbter Methoden

76

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);

}

Die Methode paint in GRect nutzt die Methoden getColor(), getFillColor()

class GStrangeRect extends GRect { // Konstruktor etc. Color getFillColor() { setColor(Color.BLUE); // ! return super.getFillColor(); }}

Wir schreiben ein „komisches Rechteck“, das diese Methoden modifiziert

Was passiert hier?




Überschreiben geerbter Methoden

77

class GStrangeRect extends GRect { // ... Color getFillColor () { setColor(Color.BLUE);

return super.getFillColor(); }}

• „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“

Technisch gesprochen: „Führe die erste Implementierung von getFillColor() aus, die entlang der Kette meiner Ahnen existiert.“






Inhaltsverzeichnis

78




class GStrangeRect extends GRect { // Konstruktor etc. …// Verschiebt sich vor dem Zeichnen void getFillColor() { setColor(Color.BLUE); return super.getFillColor(); }}

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.

79

Achtung! Was passiert beim Aufruf von paint(g)?




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)}

Auswahl einer Methode beim Operationsaufruf

80

Überschreiben von getFillColor() in GStrangeRect führt dazu, dass auch paint() sich seltsam verhält, wenn GStrangeRect es ausführt. Die Frage ist, warum?




Auswahl einer Methode beim Operationsaufruf

81

rect2Klasse

Jedes Objekt kennt die eigene 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].

GRectgetFillColor(): Colorpaint(Graphics): void...

GStrangeRect

getFillColor(): Color




Aufruf der Methode paint(Graphics)

82

rect

Kla

sse


GStrangeRect


run()

paint(g)

if (isFilled) { g.setColor( getFillColor())...

• 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)

83

rect2Klas

se


GStrangeRect


run()

paint(g)


setColor(Color.BLUE);return super.getFillColor();

• 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

84

• 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




Dynamische Bindung der Methoden

85

rect2Klasse


GStrangeRect


rectKlasse

run()p

ain

t(g

)Die Bindung erfolgt erst während der dynamischen Ausführung einer Aufgabe.

Sie hängt ab vom Typ des Objekts, das die Nachricht bekommt.




Bindung von super-Aufrufen

86

rect2Klas

se


GStrangeRect


run()

paint(g)


setColor(Color.BLUE);return super.getFillColor();




Bindung von this- und super-Aufrufen

87

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) gebundenAufrufe ü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

88

Documents

Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik 1 Thema 13: Vererbung, Funktionsvorlagen,