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