Ersetzbarkeit, Client-Server Beziehungen

Transkript

1 Ersetzbarkeit, Client-Server Beziehungen VL Objektorientierte Programmierung Raimund Kirner Mitwirkung an Folienerstellung: Peter Puschner, basieren auf den Folien von Franz Puntigam, TU Wien

2 Überblick Ersetzbarkeit Kovarianz, Kontravarianz, Invarianz Client-Server Beziehungen Person Univ.Lehrer Student Verw.pers. ADT + Vererbung + Dynamisches Binden 2

3 Das Ersetzbarkeitsprinzip U ist Untertyp von T, wenn eine Instanz von U überall verwendbar ist, wo eine Instanz von T erwartet wird Dieses Ersetzbarkeitsprinzip benötigt man für den Aufruf einer Routine mit einem Argument, dessen Typ Untertyp des formalen Parametertyps ist; die Zuweisung eines Objekts an eine Variable, wobei der Objekttyp Untertyp des deklarierten Variablentyps ist. 3

4 Untertypen und Schnittstellen Objekttyp U ist Untertyp von Objekttyp T wenn gilt für jede Konstante in T (vom Typ A) existiert eine Konstante in U (vom Typ B), wobei B Untertyp von A für jede Variable in T existiert eine Var. in U vom selben Typ für jede Methode in T existiert eine Methode in U, wobei Parameteranzahlen und Parameterarten (Eing./Ausg./Durchg.) gleich Eingangsparametertypen in T Untertypen der in U entsprechende Durchgangsparametertypen gleich Ausgangsparametertypen in U Untertypen der in T Ergebnistyp in U Untertyp von Ergebnistyp in T 4

5 Ergebnis- und Ausgangspar.-Typen In T: In U: TRet1 einemethode(tout1 par){...} TRet2 einemethode(tout2 par){...} T U Jeder in U nach außen gelieferte Typ (TRet1, TOut1) soll vom entsprechenden Typ in T (TRet2, TOut2) sein. Typen von Ergebnissen und Ausgangsparametern im Untertyp U müssen Untertypen der entsprechenden Typen in T sein (Kovarianz) 5

6 Eingangsparameter-Typen In T: In U: TRet1 einemethode(tin1 par){...} TRet2 einemethode(tin2 par){...} T U Jeder in T gelesene Wert vom Typ (TIn1) soll vom entsprechenden Typ in U (TIn2) sein. Typen von Eingangsparametern im Untertyp U müssen Obertypen der entsprechenden Typen in T sein (Kontravarianz) 6

7 Variablen und Durchgangspar.-Typen In T: In U: TRet1 einemethode(tinout1 par){...} TRet2 einemethode(tinout2 par){...} T U Ersetzbarkeit bei lesendem und schreibendem Zugriff benötigt. Typen von Variablen und Durchgangsparametern müssen in U und T gleich sein (Invarianz) 7

8 Ko-, Kontra- und Invarianz Kovarianz: Typ eines Elements im Untertyp ist Untertyp des Elementtyps im Obertyp Konstantentypen, Ergebnistypen, Ausgangsparametertypen Kontravarianz: Typ eines Elements im Untertyp ist Obertyp des Elementtyps im Obertyp Eingangsparametertypen Invarianz: Typ eines Elements im Untertyp ist gleich dem Elementtyp im Obertyp Variablentypen, Durchgangsparametertypen 8

9 Einschränkungen in der Praxis Theorie: vollständig und widerspruchsfrei, keine expliziten Untertypdeklarationen nötig Einschränkung in vielen praktisch verwendeten Sprachen: explizite Vererbungsbeziehung vorausgesetzt (zb: C++) Vererbung entsprechend eingeschränkt (zb: C++) Grund: einfach, keine zufälligen Untertypbeziehungen weitere Einschränkung in C++: Ergebnistypen kovariant, alle anderen Typen invariant 9

10 Beispiel zu Ersetzbarkeit class T1 { virtual T1& getref() { } }; class T2: public T1 { T2& getref() { } }; Zu prüfende Fragen: 1. Ist T1 ersetzbar durch T2? 2. Ist T1 ersetzbar durch T3? 3. Ist T2 ersetzbar durch T1? 4. Ist T2 ersetzbar durch T3? 5. Ist T3 ersetzbar durch T1? 6. Ist T3 ersetzbar durch T2? class T3: public T1 { T3& getref() { } }; In C++ wird Vererbungsbeziehung vorausgesetzt für Untertypbeziehung (daher nur Fragen 1. und 2. wahr). Wie sieht es ohne die C++ Einschränkungen aus? 10

11 Untertypen Code-Wiederverwendung Software-Generationen und -Versionen Treiber1 Treiber2a Treiber2b Treiber2c Treiber3a Treiber3b Treiber3c Ersetzbarkeit Code-Wiederverwendung zw. Versionen Typen sollen unverändert bleiben, Erweiterungen möglich 11

12 Untertypen Code-Wiederverwendung Wiederverwendung innerhalb eines Programms Person Univ.Lehrer Student Verw.pers. Stud.Ass. Werksstud. Ersetzbarkeit Code-Wiederverwendung im Programm Lokalhalten von Code-Änderungen Typen sollen stabil sein vor allem weiter oben 12

13 Dynamisches Binden class Person { virtual void print() { // print Person } }; class Student : public Person { void print () { // print Student details } }; class UnivLehrer : public Person { void print () { // print UnivLehrer details } }; Person *x = new Student (); Person *y = new UnivLehrer (); x->print(); y->print(); 13

14 Dynamisches Binden (2) Achtung: Default-Bindung ist in C++ statisch Keyword virtual für dynamisches Binden Zur Implementierung von rein virtuellen (=abstrakten) Methoden, die in allen Subklassen definiert werden müssen: virtual void print() = 0; 14

15 Ersetzbarkeit und Objektverhalten bisher genannte Bedingungen von Typ- Untertypbeziehungen sind statisch können vom Compiler überprüft werden weitere Bedingungen für Ersetzbarkeit betreffen das Objektverhalten ist nicht vom Compiler überprüfbar 15

16 Client-Server-Beziehungen Server bietet Dienste an, Client nutzt Dienste Dienst entspricht der Ausführung einer Methode Objekt ist gleichzeitig Client und Server Vertrag zwischen Client und Server: Client erfüllt Vorbedingungen eines Dienstes Server erfüllt Nachbedingungen eines Dienstes Server sichert Invarianten des Objekts zu Vor-, Nachbedingungen, Invarianten sind Zusicherungen 16

17 Vorbedingung (Precondition) Verantwortlich: Client Wann: vor Methodenaufruf Was: hauptsächlich Eigenschaften von Argumenten Beispiel: Argument ist Array aufsteigend sortierter Zahlen manchmal auch Bezug auf (sichtbaren) Zustand des Servers Beispiel: abheben nicht aufrufen, wenn Konto überzogen 17

18 Nachbedingung (Postcondition) Verantwortlich: Server Wann: vor Rückkehr aus Methodenaufruf Was: Eigenschaften von Methodenergebnissen sowie Änderungen und Eigenschaften des Objektzustands Beispiel: Methode fügt Element (falls noch nicht vorhanden) in Menge ein. Das Ergebnis ist true, falls das Element bereits vorher in Menge war. Nachbedingung klingt oft wie Methodenbeschreibung 18

19 Invariante Verantwortlich: Server Wann: vor und nach Ausführung von Methoden Was: unveränderliche Eigenschaften von Objekten Beispiel: Guthaben am Sparbuch ist immer positive Zahl Gültigkeit der Invariante kann von Bedingungen abhängen Beispiel: zuverlässig == false wenn Konto überzogen Invarianten implizieren Nachbedingungen Ausnahme: Schreiben externer Variablen 19

20 Typen und Zusicherungen Zusicherungen gehören zu Typen Objekttyp besteht aus Name von Klasse Schnittstelle (= Signatur) Zusicherungen auf Methoden Formulierung der Zusicherungen als Kommentare Überprüfung der Zusicherungen bei Verwendung v. Typen Änderungen von Zusicherungen, Typänderungen Auswirkungen auf andere Programmteile 20

21 Genauigkeit von Zusicherungen Clients dürfen sich nur auf das verlassen, was in Schnitt-stellen und Zusicherungen vom Server zugesagt wird. Server dürfen sich nur auf das verlassen, was in Schnittstellen und Zusicherungen vom Client zugesagt wird. Genauigkeit durch ProgrammiererInnen bestimmbar: genau große Abhängigkeit zw. Client und Server Zus. sind bei Codeänderung eher zu ändern 21

22 Genauigkeit von Zusicherungen Tipp: nur wirklich notwendige Zusicherungen beschreiben Tipp: keine versteckten Zusicherungen Tipp für den Einsatz von Zusicherungen: Klassenzusammenhalt maximieren + Objektkopplung minimieren Beispiel: Methode abheben von Konto Vorbedingung darf Konto nicht überziehen weglassen dafür: explizietes Überprüfen der Bedingung in der Methode abheben des Server-Objekts 22

23 Ersetzbarkeit und Verhalten U ist nur dann Untertyp von T wenn gilt: Vorbedingungen in T implizieren Vorbedingungen in U Vorbedingungen in Untertypen sind schwächer bei Vererbung: Verknüpfung mit ODER Nachbedingungen in U implizieren Nachbedingungen in T Nachbedingungen in Untertypen sind stärker bei Vererbung: Verknüpfung mit UND Invarianten in U implizieren Invarianten in T Invarianten in Untertypen sind stärker bei Vererbung: Verknüpfung mit UND gilt nicht für externes Schreiben von Variablen 23

24 Faustregeln zu Zusicherungen Zusicherungen sollen stabil sein (vor allem an Wurzel der Typhierarchie) keine unnötigen Details festlegen explizit im Programm stehen unmissverständlich formuliert sein während Programmentwicklung ständig überprüft werden ggf. zusätzlich Realisierung durch Macros 24

25 Abstrakte Klassen Dienen der Festlegung eines Typs Keine Instanzen der Klasse nur Instanzen in Unterklassen abstrakte Klassen generell eher stabil Verwendung als Parametertypen sollen stabil sein d.h., sie sollen nicht mehr ausdrücken, als nötig (keine unnötigen Abhängigkeiten) abstrakte Klassen leicht hinzuzufügen (z.b. verwendbar als Parametertypen für jeden Bedarf) 25

26 Zusammenfassung Unterstützung von Polymorphimus und dynamischer Bindung Ersetzbarkeitsprinzip (Typ-/Subtypbeziehungen) Zusicherungen Zusicherungen und Ersetzbarkeit Ausblick: Klassenbeziehungen und Vererbung 26