02-inheritance

Transcription

02-inheritance
Vererbung und Polymorphie
Prof. Dr. rer. nat. habil. Uwe Aßmann
Lehrstuhl Softwaretechnologie
Fakultät für Informatik
TU Dresden
Version 06-0.2, Oct 03, 2006
Softwaretechnologie, © Prof. Uwe Aßmann
1
Obligatorische Literatur
►
►
►
Zuser Kap 7, Anhang A
Störrle, Kap. 5.2.6, 5.6
Balzert Kap 2
Prof. Uwe Aßmann, Softwaretechnologie
2
Andere Literatur
►
►
►
►
Ken Lunn. Software Development with UML. Palgrave-Macmillan.
Good case study book.
UML 2.0 report. Object Management Group (OMG).
http://www.omg.org/uml
I. Jacobsen, G. Booch, J. Rumbaugh. The Unified Software
Development Process. Addison-Wesley. The united process from the
“3 amigos”. Guiding through the OOD, from OOA to OOP.
L. A. Maciaszek. Requirements Analysis and System Design.
Addison-Wesley.
Prof. Uwe Aßmann, Softwaretechnologie
3
Ziele
►
►
►
Einfache Vererbung zwischen Klassen, konzeptuell und im Speicher
Merkmalssuche in einer Klasse und in der Vererbungshierarchie
aufwärts
Polymorphie im Speicher
Prof. Uwe Aßmann, Softwaretechnologie
4
Vererbung
Ähnlichkeit zwischen Klassen und Objekten
Softwaretechnologie, © Prof. Uwe Aßmann
5
Einfache Vererbung
►
■
■
►
Person
Vererbung: Eine Klasse kann
Merkmale von einer Oberklasse
übernehmen
.. und teilt sie damit mit allen
Geschwistern
Die Unterklasse ist damit ähnlich zu
dem Elter und den Geschwistern
Einfache Vererbung
■
■
eat()
work()
sleep()
getName()
Jede Klasse hat nur eine
Oberklasse
Die Vererbungsrelation ist ein Baum
Professor
Student
giveLecture()
visitLecture()
drinkBeer()
Oberklasse Person enthällt alle gemeinsamen Merkmale der Unterklassen
►
Vererbung drückt Ähnlichkeit bzw. Gemeinsamkeiten aus
Einfache Schreibweise: Professor < Person. Student < Person.
Prof. Uwe Aßmann, Softwaretechnologie
6
Begriffshierarchien (Taxonomien)
►
►
Klassifikationen enden oft in Begriffshierarchien
Beispiel: Klassen können Begriffsklassen (nur Attribute) oder
operationale Klassen sein (auch Operationen)
Class
name:Identifier;
Concept Class
attributes:Attribute[];
Operational Class
Prof. Uwe Aßmann, Softwaretechnologie
operations:Operation[]
7
Bsp: Begriffshierarchie der
Methodenarten
►
Wiederholung: Welche Arten von Methoden gibt es in einer Klasse?
Methode
Zustandsinvariante
Methoden
Anfrage (query)
Checker
Prof. Uwe Aßmann, Softwaretechnologie
Zustandsverändernde
Methoden
Zustandsmodifikatoren
Netzmodifikatoren
RepräsentationsWechsler
Allgemeine
8
Methoden
Bsp. Begriffshierarchie der
Steuererklärungen
►
►
Das deutsche Steuerrecht kennt viele Arten von Steuererklärungen
Eine Klassifikation führt zu einer Begriffshierarchie
Steuererklärung
sum: int
address:Address
Einkommenssteuererklärung
Vermögenssteuererklärung
deadline:Date
Reine
LohnsteuerEinkommensJahresausgleich steuererklärung
Prof. Uwe Aßmann, Softwaretechnologie
Erbschaftssteuererklärung
UmsatzsteuerErklärung
taxRatio:int
Vorsteuererklärung
UmsatzsteuerNachzahlung
9
Bsp. Hierarchien von Operationalen
Klassen
►
►
Programmiert man eine Steuerberater-Software, muss man die
Begriffshierachie der Steuererklärungen als Klassen einsetzen.
Daneben sind aber die Klassen um Operationen zu erweitern, denn
innerhalb der Software müssen sie ja etwas tun.
Steuererklärung
sum: int
address:Address
ship()
Einkommenssteuererklärung
deadline:Date
computePayBack()
Vermögenssteuererklärung
Reine
LohnsteuerEinkommensJahresausgleich
steuererklärung
Prof. Uwe Aßmann, Softwaretechnologie
Erbschaftssteuererklärung
UmsatzsteuerErklärung
taxRatio:int
Vorsteuererklärung
UmsatzsteuerNachzahlung
10
Vererbung im Speicher
►
... am Beispiel Steuerzahler
Person
name:String
martialStatus:String
work()
TaxPayer
Steuerzahler
Moonlighter
Schwarzarbeiter
taxnumber:int
pay()
fillIn()
earn()
Prof. Uwe Aßmann, Softwaretechnologie
11
Vererbung im Speicher
►
Verzeigerung der Vererbungsrelation von Unter- zu Oberklassen
■
►
Unterscheide davon die Objekt-Prototyp-Relation!
Methoden werden zwischen den Klassen geteilt
Halde
(Objektspeicher)
Prototypen im
statischen Speicher
010
name:String == null
132 name:String
014
maritalStatus:String == null
136 maritalStatus:String
018
methodTable:Method[]
022
superClass:Class
144 name:String
026
taxnumber:int
148 maritalStatus:String
030
methodTable:Method[]
026
superClass:Class
030
methodTable:Method[]
Vererbungsrelation
Prof. Uwe Aßmann, Softwaretechnologie
work()
140 prototype:Class
pay()
152 taxnumber:int == 12940
fillIn()
156 prototype:Class
144 name:String
148 maritalStatus:String
earn()
152 prototype:Class
12
Ein grosser Vererbungsbaum und
Merkmalssuche
►
►
►
►
Person
Alumnus
Oberklassen sind
eat()
visitUniversity()
allgemeiner als Unterklassen
work()
drinkBeer()
(Prinzip der Generalisierung)
sleep()
getName()
Unterklassen sind spezieller
Feature resolution
als Oberklassen
(Spezialisierung)
Student
Employee
Unterklassen erben alle
visitLecture()
salary
Merkmale der Oberklassen
drinkBeer()
Methoden- bzw.
Merkmalssuche: Wird ein
Professor
Beginner
LonglifeStudent
Merkmal nicht in einer
Klasse definiert, wird in der giveLecture() visitNullCourse()
salary
Oberklasse gesucht (method
or feature resolution)
Prof. Uwe Aßmann, Softwaretechnologie
Professor
Emeritus
13
Merkmalssuche im Speicher
1) Suche Attribut name in Steuerzahler: direkt vorhanden
2) Suche Methode pay() in Steuerzahler: Schlage Prototyp nach, finde in Methodentabelle des
Prototyps
3) Suche Methode work() in Steuerzahler: Schlage Prototyp nach, Schlage Oberklasse nach
(Person), finde in Methodentabelle von Person
4) Suche Methode payback() in Steuerzahler: Schlage Prototyp nach, Schlage Oberklasse
nach (Person), NICHT in Methodentabelle von Person. Da keine weitere Oberklasse
existiert, wird ein Fehler ausgelöst “method not found” “message not understood”
Halde (Objektspeicher)
Prototypen im statischen Speicher
010
name:String == null
132
name:String
014
maritalStatus:String == null
136
maritalStatus:String
018
methodTable:Method[]
140
prototype:Class
022
superClass:Class
144
name:String
taxnumber:int
148
maritalStatus:String
pay()
152
taxnumber:int == 12940
fillIn()
156
prototype:Class
144
name:String
148
maritalStatus:String
152
prototype:Class
026
030
methodTable:Method[]
026
superClass:Class
030
methodTable:Method[]
Prof. Uwe Aßmann, Softwaretechnologie
work()
earn()
14
Beispiel als Venn-Diagramm
►
Vererbung kann auch durch Enthaltensein von Rechtecken
ausgedrückt werden
■
►
►
Einfach-Vererbung ergibt ein Diagramm ohne Überschneidungen
Für Objekt-Extents einer Klassenhierarchie gilt, dass jede Klasse die
eigenen Objekte verwaltet
Der Objekt-Extent einer Oberklasse ergibt sich aus der Vereinigung
der Extents aller Unterklassen (Person aus Professor und Student).
Genau das drückt das Venn-Diagramm aus
Person
Professor
Student
Schill:Professor
Schneider:Student
Aßmann:Professor
Müller:Student
Härtig:Professor
Weckermann:Student
Prof. Uwe Aßmann, Softwaretechnologie
15
Objekt-Extent im Speicher, mit
Vererbung
►
Zu einer Klasse vereinige man alle Extents aller Unterklassen
010
name:String == null
132
name:String
014
maritalStatus:String == null
136
maritalStatus:String
018
methodTable:Method[]
140
prototype:Class
022
extent:List(Object)
144
name:String
148
maritalStatus:String
026
superClass:Class
152
030
taxnumber:int
taxnumber:int == 12940
156
prototype:Class
034
methodTable:Method[]
038
extent:List(Object)
160
name:String
164
maritalStatus:String
042
superClass:Class
168
prototype:Class
046
050
methodTable:Method[]
172
name:String
extent:List(Object)
176
maritalStatus:String
180
prototype:Class
184
name:String
188
maritalStatus:String
192
taxnumber:int == 12941
196
prototype:Class
Prof. Uwe Aßmann, Softwaretechnologie
16
Erweitern und Überschreiben
►
►
Eine Unterklasse kann neue
Merkmale zu einer
Oberklasse hinzufügen
(Erweiterung, extension)
Definiert eine Unterklasse
ein Merkmal erneut, spricht
man von einer Redefinition
(Überschreiben, overriding)
■
Person
Alumnus
eat()
work()
drinkBeer()
getName()
visitUniversity()
drinkBeer()
Employee
Student
salary
visitLecture()
drinkBeer()
Dieses Merkmal
überschattet (verbirgt) das
Merkmal der Oberklasse, da
der MerkmalsProfessor
suchalgorithmus in der
giveLecture()
Hierarchie von unten nach drinkBeer()
oben sucht.
Prof. Uwe Aßmann, Softwaretechnologie
drinkBeer() {
... select Erdinger;
enjoy();
}
Professor
Emeritus
drinkBeer()
drinkBeer() {
... select Radeberger;
enjoy();
}
drinkBeer() {
... select Leffe;
enjoy();
}
drinkBeer() {
}
17
Bsp. Begriffshierarchie verschiedener
Zeiten im Lebenszyklus einer Software
►
Übersetzungszeit kennt hauptsächlich Klassen; Laufzeit kennt
hauptsächlich Objekte
Zeitabschnitt
„dynamisch“
„statisch“
Übersetzungszeit
(compile time)
Generierungszeit
(generation
time)
Bindezeit
(link time)
Reine
Übersetzungszeit
Prof. Uwe Aßmann, Softwaretechnologie
Ladezeit
(load, deployment time)
Startzeit
(Allokationszeit, allocation,
creation time)
Laufzeit
(run time)
Rekonfigurationszeit
Arbeits-/
Lebenszeit
(life time)
18
Bemerkung
►
Wir benutzen i.A. mehrere Darstellungen für Klassen- und
Objektdiagramme
■
■
►
►
UML-Strukturdiagramme
Venn-Diagramme
Venn-Diagramme haben den Vorteil, dass sie sowohl die
Zugehörigkeit eines Objekts zu einer Klasse als auch Vererbung
zwischen Klassen mit einem Einkapselung einheitlich beschreiben
(mengentheoretischer und Ähnlichkeitsaspekt)
Venn-Diagramme können sowohl die statischen Beziehungen von
Klassen, als auch die dynamischen Beziehungen von Objekten und
Klassen beschreiben
Prof. Uwe Aßmann, Softwaretechnologie
19
Schnittstellen und Klassen
►
Der Klassenbegriff ist vielschattig. Man unterscheidet Klassen mit,
ohne, und mit Implementierung einer Untermenge der Operationen
Klassenbegriff
Schnittstelle
(interface)
- ohne Implementierung,
nur Signaturen
Prof. Uwe Aßmann, Softwaretechnologie
Abstrakte Klasse
- partielle
Implementierung
(Konkrete) Klasse
- mit Implementierung
20
Schnittstellen und Klassen in UML
►
►
In UML werden sog.
Stereotypen vergeben, um
Schnittstellen zu kennzeichnen
(<<interface>>)
AbstrakteKlassen werden mit
einem speziellen Markierer
(tagged value) gekennzeichnet
({abstract}) oder kursiv gemalt
<<interface>>
NamedThing
getName()
{abstract}
Person
drinkBeer()
Employee
Student
getSalary()
visitLecture()
Professor
Prof. Uwe Aßmann, Softwaretechnologie
getSalary() {
... goToBank()
withDraw();
}
getName() {
return name;
}
drinkBeer() {
... select Leffe;
enjoy();
}
VisitLecture() {
stepIn();
payAttention();
}
drinkBeer() {
... select Radeberger;
enjoy();
}
21
Schnittstellen und Klassen in Java
interface NamedThing {
String getName(); // no implementation
}
abstract class Person implements NamedThing {
String name;
String getName() { return name; } // implementation exists
abstract void drinkBeer();
// no implementation
}
abstract class Employee extends Person {
abstract void getSalary();
// no implementation
}
class Professor extends Employee { // concrete class
void getSalary() { goToBank(); withDraw(); }
void drinkBeer() { .. select Leffe(); enjoy(); }
}
class Student extends Person {
// concrete class
void visitLecture() { stepIn(); payAttention(); }
void drinkBeer() { .. select Radeberger(); enjoy(); }
}
22
Prof. Uwe Aßmann, Softwaretechnologie
Abstrakte Klassen und Abstrakte
Operationen
abstract class Termin {
...
String titel;
Hour beginn;
int dauer;
...
abstract boolean verschieben (Hour neu);
};
class Teambesprechung
extends Termin {
...
boolean verschieben (Hour neu)
{
boolean ok = abstimmen(neu, dauer);
if (ok) {
beginn = neu;
raumFestlegen();
Jede abstrakt deklarierte Methode
};
muß in der Unterklasse realisiert
return ok;
werden - sonst können keine Objekte
};
};
der Unterklasse erzeugt werden!
Prof. Uwe Aßmann, Softwaretechnologie
23
Einfache Vererbung durch
Schnittstellen
Termin
<<interface>>
Hausveranstaltung
einladen()
absagen()
Teambesprechung
einladen()
absagen()
Vortrag
einladen()
absagen()
Hinweis: “Lutscher”-Notation (lollipop) für Schnittstellen ist weit
verbreitet:
Teambesprechung
Prof. Uwe Aßmann, Softwaretechnologie
Hausveranstaltung
24
Schnittstellen und abstrakte Klassen
Abstrakte Klasse
Schnittstelle
Enthält Attribute
und Operationen
Kann Default-Verhalten
festlegen
Default-Verhalten kann in
Unterklassen überdefiniert
werden
Java: Unterklasse kann nur
von einer Klasse erben
Enthält nur Operationen
(und ggf. Konstante)
Kann kein Default-Verhalten
festlegen
Redefinition unsinnig
Prof. Uwe Aßmann, Softwaretechnologie
Java: Eine Klasse kann
mehrere Schnittstellen
implementieren
Schnittstelle ist eine spezielle
Sicht auf eine Klasse
25
Polymorphie
Softwaretechnologie, © Prof. Uwe Aßmann
26
Vererbung und Polymorphie
►
►
►
Welcher Begriff beschreibt das Objekt?
Welche Begriffshierarchie wird verwendet
(Oberklassen/Unterklassen)?
Wie hängt das Verhalten des Objektes von der Hierarchie ab
(spezieller vs allgemeiner)?
Klasse:
„Ampel“
Vererbung:
Sensorgesteuerte
Ampel
Vererbung:
Zeitgesteuerte
Ampel
Prof. Uwe Aßmann, Softwaretechnologie
Polymorphie:
Ampeln mit
Sensorsteuerung
reagieren anders
als zeitgesteuerte
Ampeln auf
Zeittakt
27
Beispiel: Ampel-Klasse und AmpelObjekte
►
Jede Ampel reagiert auf den Zeittakt.
■
Die Klasse Ampel schreibt vor, daß auf die Nachricht „Zeittakt“ reagiert
werden muß.
■
Verschiedene Reaktionen der Unterklassen
DD-0X5A: SensorAmpel
DD-0Y3C: ZeitAmpel
DD-0X5B: SensorAmpel
Ampel
SensorAmpel
ZeitAmpel
Instanz einer Klasse
Generalisierung (Vererbung)
Prof. Uwe Aßmann, Softwaretechnologie
28
Beispiel: Termin-Klasse und TerminObjekte
►
Jeder Termin kann verschoben werden.
■
►
Die Klasse Termin schreibt vor, daß auf die Nachricht
„verschiebeTermin“ reagiert werden muß.
Unterklassen spezialisieren Oberklassen
Figaro am 10.1.01: Theaterbesuch
AR-12: Teambesprechung
AR-13: Teambesprechung
Termin
Geschäftstermin
Teambesprechung
Prof. Uwe Aßmann, Softwaretechnologie
Privater Termin
Kundenbesuch
Theaterbesuch
29
Polymorphie (polymorphism)
►
Zur Laufzeit kann jedes Objekt einer Unterklasse ein Objekt einer
Oberklasse vertreten. Das Objekt der Oberklasse ist damit
vielgestaltig (polymorphic).
Person
List
Alumnus
visitUniversity()
drinkBeer()
Person
Beginner
Student
visitLecture()
drinkBeer()
LonglifeStudent
(4)
TUDList:
Person
List
(1)
John:
Alumnus
John:Beginner
(2)
Prof. Uwe Aßmann, Softwaretechnologie
John:Student
(3)
John:
30
LonglifeStudent
Wechsel der Gestalt
►
Die genaue Unterklasse eines Objektes wird festgestellt
■
■
Beim Erzeugen (der Allokation) des Objekts (oft in der Aufbauphase)
Bei einer neuen Zuweisung (oft in einer Umbauphase)
Person person;
if (hasLeftUniversity)
person = new Alumnus();
else
person = new Student();
// which type has person here?
....
if (hasWorkedHardLongEnough)
person = new Professor();
// which type has person here?
Prof. Uwe Aßmann, Softwaretechnologie
31
Dynamischer Aufruf (Dynamic
dispatch)
►
►
►
►
Person
Dynamischer Aufruf
Alumnus
(polymorpher Aufruf) realisiert
graduationYear:int
name:String
drinkBeer()
Polymorphie zur Laufzeit
drinkBeer()
Aufrufe an Objekte aus
Method resolution
Vererbungshierarchien, die
Methodensuche einsetzen
Student
Employee
(method resolution), heissen
visitLecture()
polymorphe Aufrufe
salary
drinkBeer()
Dynamischer Aufruf ist also
Aufruf an Objekt +
Methodensuche
Professor
Beginner
LonglifeStudent
Suche wird oft mit Tabellen
getSalary()
giveLecture()
visitNullCourse()
realisiert (dispatch)
drinkBeer()
John:Beginner
drinkBeer()
Prof. Uwe Aßmann, Softwaretechnologie
32
Dynamischer Aufruf (Dynamic
Dispatch)
►
Vom Aufrufer aus wird ein Suchalgorithmus gestartet, der die
Vererbungshierarchie aufwärts läuft, um die rechte Methode zu
finden
■
Diese Suche kann teuer sein und muß vom Übersetzer optimiert werden
(dispatch optimization)
Callee
Caller
Object
Callee
Callee
dispatch
Prof. Uwe Aßmann, Softwaretechnologie
33
Was passiert beim polymorphen Aufruf
im Speicher?
►
Frage: Welche Inkarnation der Methode drinkBeer() wird zu den
verschiedenen Zeitpunkten im Leben Johns aufgerufen?
Academic
name:String == null
methodTable:Method[]
extent:List(Object)
superClass:Class
methodTable:Method[]
extent:List(Object)
Beginner
superClass:Class
methodTable:Method[]
extent:List(Object)
Student
superClass:Class
methodTable:Method[]
extent:List(Object)
1
John:
Person
2
John:
Beginner <
Person
visitNullCourse()
drinkBeer()
Longlife
Student
superClass:Class
Alumnus
graduationYear:int
methodTable:Method[]
extent:List(Object)
Prof. Uwe Aßmann, Softwaretechnologie
visitLecture()
drinkBeer()
3
John:
Student <
Person
4
John:Long
lifeStudent <
Person
5
John:
Alumnus <
Person
getSalary()
drinkBeer()
drinkBeer()
name:String
prototype:Class == Person
name:String = „John Silver“
prototype:Class == Beginner
name:String
maritalStatus:String
prototype:Class == Student
name:String
prototype:Class == Longlife
Student
name:String
graduationYear:int == 1997
34
prototype:Class == Alumnus
Polymorphe und monomorphe
Methoden
►
►
►
Methoden, die nicht mit einer Oberklasse geteilt werden, können
nicht polymorph sein
Die Adresse einer solchen monomorphen Methode im Speicher kann
statisch, d.h., vom Übersetzer ermittelt werden. Eine Merkmalssuche
ist dann zur Laufzeit nicht nötig
Frage: Welche der folgenden Methoden sind poly-, welche
monomorph?
Man
name:String
martialStatus:String
work()
Prof. Uwe Aßmann, Softwaretechnologie
TaxPayer
Steuerzahler
Moonlighter
Schwarzarbeiter
taxnumber:int
pay()
fillIn()
work()
earn()
35
Einsatz von Polymorphie
►
►
Oft modellieren Unterklassen Rollen einer Oberklasse
Eine Rolle ist ein dynamischer Zustand eines Objekts: ein Objekt
spielt eine Rolle für einige Zeit
■
■
■
■
►
Akademiker spielen verschiedene Rollen bez. ihres Studentenlebens
Männer können ledig, verheiratet, geschieden, wiederverheiratet sein
Menschen können Kinder, Teenager, Erwachsene, Rentner sein
Autos können fabrikneu, Jahreswagen, gebraucht, Wrack, oder Schrott
sein
Man implementiert den Wechsel einer Rolle durch den Wechsel der
entsprechenden Unterklasse durch
■
■
■
Alloziere und fülle neues Objekt aus den Werten des alten Objektes
heraus
Setze Variable um auf neues Objekt
(Dealloziere altes Objekt)
Prof. Uwe Aßmann, Softwaretechnologie
36
Prinzipielle Vorteile von
Objektorientierung
Zuständigkeitsbereiche
Klare Schnittstellen
Lokale Kombination von
Daten und Operationen,
gekapselter Zustand
Stabilität
Definiertes Objektverhalten,
Nachrichten zwischen Objekten
Vererbung und Polymorphie
(Spezialisierung),
Klassenschachtelung
Änderungsfreundlichkeit
Hierarchie
Baukastenprinzip
Prof. Uwe Aßmann, Softwaretechnologie
Benutzung vorgefertigter
Klassenbibliotheken,
Anpassung durch Spezialisierung
(mittels Vererbung)
Wiederverwendung
37
Was haben wir gelernt?
►
►
►
►
►
►
Vererbung zwischen Klassen erlaubt die Wiederbenutzung von
Merkmalen aus Oberklassen, sowohl Schnittstellen als auch
Implementierungen
Einfache Vererbung führt zu Vererbungshierarchien
Merkmalssuche löst die Bedeutung von Merkmalsnamen auf, in dem
von den gegebenen Unterklassen aus aufwärts gesucht wird
Schnittstellen sind voll abstrakte Klassen
Polymorphie benutzt Merkmalssuche, um die Mehrdeutigkeit von
Namen in einer Vererbungshierarchie aufzulösen
Monomorphe Aufrufe sind schneller, weil die Merkmalssuche
eingespart werden kann
Prof. Uwe Aßmann, Softwaretechnologie
38
The End
Prof. Uwe Aßmann, Softwaretechnologie
39

Documents pareils