C Objektorientierte Programmierung C.1 Überblick C ... · Jürgen Kleinöder • Universität...

Reproduktion jeder Art oder Verwendung dieser Unterlage, außer zu Lehrzwecken an der Universität Erlangen-Nürnberg, bedarf der Zustimmung des Autors.

C Objektorientierte Programmierung C.1 Überblick

Jürgen Kleinöder • Universität Erlangen-Nürnberg • Informatik 4, 2007 WS 2007/08 MW (C-OOP.fm 2007-10-16 09.12) C - 1Reproduktion jeder Art oder Verwendung dieser Unterlage, außer zu Lehrzwecken an der Universität Erlangen-Nürnberg, bedarf der Zustimmung des Autors.

C Objektorientierte Programmierung

C.1 Überblick

■ Motivation für das objektorientierte Paradigma

■ Software-Design Methoden

■ Grundbegriffe der objektorientierten Programmierung

■ Fundamentale Konzepte des objektorientierten Paradigmas

■ Objektorientierte Analyse und Design

■ Design Patterns


C Objektorientierte Programmierung C.2 Literatur


C.2 LiteraturABC83. M. P. Atkinson, P. J. Bailey, K. J. Chisholm, W. P. Cockshot and R. Morrison, “An Approach to

Persistent Programming”,The Computer Journal, Vol. 26, No. 4, pp. 360-365, 1983.Boo94. Grady Booch,Object-Oriented Analysis and Design (with Applications), Benjamin/Cummings,

Redwood (CA), 1994.CW85. Luca Cardelli, Peter Wegner, "On Understanding Types, Data Abstraction, and Polymorphism",

Computing Surveys, Vol. 17, No. 4, Dec. 1985.GHJ+97. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.Design Patterns: Elements of

Reusable Object-Oriented Software, 10th print, Addison-Wesley, 1997Jac92. I. Jacobson. Object-Oriented Software Enineering — A Use Case Driven Approach. Addison-

Wesley, 1992.MaM88. Ole Lehrmann Madsen, Birger Møller-Pedersen, "What object-oriented programming may be —

an what it does not have to be",ECOOP ’88 – European Conference on OO Programming, pp. 1- 20, S. Gjessing, K. Nygaard [Eds.]; Springer Verlag, Oslo, Norway, Aug. 1988.

Mey86. Bertrand Meyer, "Genericity versus Inheritance",Conference on Object-Oriented ProgrammingSystems, Languages, and Applications - OOPSLA ’87, pp. 391 - 405, Portland (Oreg., USA),published asSIGPLAN Notices, Vol. 21, No. 11, Nov. 1986.

Mey88. Bertrand Meyer.Object Oriented Software Construction. Prentice Hall Inc., Hemel Hempstead,Hertfordshire, 1988.

Oes97. B. Oestereich. Objektorientierte Softwareentwicklung: Analyse und Design. Oldenbourg, 1997.Str93. Bjarne Stroustrup, "A History of C++", ACM SIGPLAN Notices, Vol. 28, No. 3, pp.271 - 297,

Mar. 1993.Str00. Bjarne Stroustrup.The C++ Programming Language(Special Edition). Addison Wesley. Reading

Mass. USA. 2000.Weg87. Peter Wegner, “Dimensions of Object-Based Language Design”,OOPSLA ’87 – Conference

Proceedings,pp. 1-6, San Diego (CA, USA), published asSIGPLAN Notices, Vol. 22, No. 12, Dec.1987.

Weg90. Peter Wegner, “Concepts and Paradigms of Object-Oriented Programming”, ACM OOPSMessenger, No. 1, pp. 8-84, Jul. 1990.

BRJ98. G. Booch, J. Rumbaugh, and I. Jacobson.The Unified Modeling Language Reference Manual.Addison Wesley, 1998.

RJB98. J. Rumbaugh, I. Jacobson, and G. Booch.The Unified Modeling Language User Guide.AddisonWesley, 1998.

JBR98. I. Jacobson, G. Booch, and J. Rumbaugh.The Unified Software Development Process. AddisonWesley, 1998.


C Objektorientierte Programmierung C.3 Motivation für das objektorientierte Paradigma


C.3 Motivation für das objektorientierte Paradigma

1 Ziele

■ Mithalten mit der steigenden Komplexität großer SoftwaresystemeBooch [Boo94] spricht vonindustrial-strength Software und meint damit komplexe Softwaresy-steme, wie sie heute in der Industrie (Prozeßsteuerung, Bank- und Versicherungswesen, Bu-chungssysteme, etc.) in großem Umfang eingesetzt sind. Solche Softwaresysteme sind so kom-plex, daß es in der Regel für einen Entwickler nicht möglich ist, alle Details des Designs zu über-blicken. Die Softwaresysteme haben eine sehr lange Lebensdauer, haben viele Nutzer und werdenvon vielen unterschiedlichen Personen gewartet und erweitert.Mit der ständig steigenden Leistungsfähigkeit (Geschwindigkeit, Speicherumfang, Parallelverar-beitung) von Rechnern nimmt auch die Komplexität der damit bearbeitbaren Probleme zu. Die ur-sprünglichen Softwareentwicklungsmethoden reichen zur Bewältigung dieser Komplexität nichtmehr aus. Objektorientierung ist eine besser Art Software zu entwickeln und zu strukturieren.

➞ Softwarekrise: Hardware wird immer leistungsfähiger, Software wird größer, die aufgrund derKonkurrenzsituation zur Verfügung stehenden Entwicklungszeiträume werden gleichzeitig kür-zer, die Kosten für Wartung und Weiterentwicklung steigen dramatisch. Letzlich stehen nichtmehr genug gute Softwareentwickler für die Entwicklung und Pflege der benötigten Software zurVerfügung.

➞ Lösung:

■ Produktivität des Programmierers steigern◆ Entwurfsmuster für häufig wiederkehrende Probleme

➞ Design-Patterns

◆ Wiederverwendung existierender Software(teile)Durch mehrfache Instantiierung allgemein einsetzbarer Softwaremodule (Klassenbibliothe-ken) sowie durch Anpassung existierender Module an erweiterte oder abgewandelte Anfor-derungen (Vererbung).Frameworks geben komplette Anwendungsgerüste vor, die durch Anpassung einzelnerKomponenten zu einer maßgeschneiderten Anwendung geformt werden können.

◆ bessere Erweiterbarkeit von SoftwareDurch Modularisierung und klare Definition von Schnittstellen zwischen den einzelnenSoftwarekomponenten

◆ bessere Kontrolle über Komplexität und Kosten von Software-WartungModulgrenzen und -schnittstellen legen klare Grenzen fest.

■ Übergang von einer maschinen-nahen Denkweisezu Abstraktionen der Problemstellung

➞ Besseres Verständnis für die Problemstellung• Terminologie der Problemstellung findet sich in der Software-Lösung wieder

➞ Lösung wird leichter verständlich


C Objektorientierte Programmierung C.4 Software-Design Methoden


C.4 Software-Design Methoden

1 Einordnung nach Booch (aus [Boo94])Grundprinzip Dekomposition:

Zerlegen eines komplexen Problems in überschaubare Teilprobleme

■ Top-down structured design (composite design)• Traditionelle Software-Design-Methode

■ Data-driven design• Orientiert sich an der Abbildung von Eingabedaten auf Ausgabedaten

■ Object-oriented design• "Moderne" Methode - findet seit einigen Jahren großen Zulauf• Bisherigen Erfahrungen zeigen vor allem Vorteile bei dem Design sehr großer Softwaresy-

steme

2 Klassen von Programmiersprachen… zumindest die wichtigsten

■ Prozedural / imperativ• z. B. Algol, Pascal, C – setzen direkt die Konzepte des Top-down structured design um

■ Funktional• Lisp und seine "Nachfahren"

■ Objektorientiert• Simula, Smalltalk, Eiffel, Java (und viele weitere)• C++ ist hybrid: prozedural auf der einen, voll objektorientiert auf der anderen Seite




3 Top-down Structured Design (Composite Design)➔ wesentlich durch die traditionellen Programmiersprachen (wie Fortran oder Cobol) beeinflusst

■ Einheit für Dekomposition: Unterprogramm• Resultierendes Programm hat die Form eines Baums in dem Unterprogramme ihre Aufgaben

durch Aufrufe weiterer Unterprogramme erledigen

■ Algorithmische Dekomposition zur Zerlegung größerer Probleme• Zentrale Sicht: Ausführung einer Problemlösung

– Modularisierung: Identifizieren von Teilproblemen / Ausführungsschritten– Reihenfolge, in der Aktionen (=Teilproblemlösungen) auszuführen sind, wird hervor-

gehoben

■ Eignung für die Strukturierung heutiger, sehr großer Softwaresystemewird bezweifelt

• Heutige Rechner können Softwaresysteme bewältigen, deren Umfang und Komplexität dieder 60er und 70er um Größenordnungen übersteigt

• Der Wert strukturierter Programmierung besteht nach wie vor, aberStructured programming appears to fall apart when applications exceed 100 000 lines ofcode or so [Boo94]

• Wesentliche Ursache ist, dass nicht die zu bearbeitenden Daten, sondern die auszuführendenAktionen im Mittelpunkt der Strukturierung stehen. Je größer ein Softwaresystem ist, destogrößer wird die Datenmenge und die Menge der Prozeduren, die darauf arbeiten. Eine festeZuordnung zwischen überschaubaren Teilmengen der Daten und Prozeduren bereits beimSoftwaredesign wird durch algorithmische Dekomposition alleine aber nicht erreicht.

■ Top-down strutured design erfasst nicht:– Datenabstraktion & Information Hiding

• Beim Top-down strutured design operieren Teilproblemlösungen auf einem globalen Daten-bestand — lokale Daten werden vor allem zur Zwischenspeicherung verwendet

– Nebenläufigkeit

■ Probleme bei sehr komplexen Aufgabenstellung und objektbasierten oderobjektorientierten Programmiersprachen

• Structured designresultiert in einer Problemstrukturierung, die nicht auf die Mechanismenin objektbasierten oder objektorientierten Sprachen abgestimmt ist

■ Häufig eingesetzte Design-Methode• Grundlagen vonstructured designberuhen auf den Arbeiten von Wirth, Dahl, Dijkstra und

Hoare

■ Prozedurale Sprachen ideal für die Implementierung geeignet




3 Top-Down Structured Design (Composite Design) (2)

■ Beispiel

Die Problemstellung ist, eine Datei mit neuen Daten zu aktualisieren.Die Aufgabe wird in mehrere Teilaufgaben zerlegt, die ihrerseits - wenn sie komplexer sind - wei-ter zerlegt werden:

• der Bereich für die Daten in der Datei muss festgelegt werden– Unteraufgabe hiervon ist, den Datenbereich zu überprüfen

• die Daten müssen vor der Ausgabe formatiert werden• die neuen Daten müssen schließlich ausgegeben werden

– Unteraufgabe ist hierbei, eine Checksumme zu berechnen

update file

calculatechecksum

formatting

check region ... ... ...

write new datadetermine region




4 Objektorientiertes Design

Bertrand Meyer:Rechner führen Operationen auf bestimmten Objekten aus;um flexiblere und wiederverwendbare Systeme zu erhalten,ist es daher sinnvoller, die Software-Strukturan diesen Objekten statt an den Operationen zu orientieren.

siehe auch [Mey88]




4 Objektorientiertes Design (2)

■ Softwaresystem wird als Sammlung kooperierender Objekte modelliert• Es stehen nicht auszuführende Aktionen im Mittelpunkt, sondern Einheiten, die einen

Zustand besitzen, ihre Dienste anderen Einheiten anbieten und zur Erledigung ihrer Aufga-ben andere Einheiten in Anspruch nehmen.

• Die Definition der Einheiten orientiert sich an den Einheiten des zu lösenden Problems

■ einzelne Objekte sind Instanz einer Klasse in einer Hierarchie vonKlassen

• Eine Klasse beschreibt die Eigenschaften von Objekten = Instanzen dieser Klasse• Hierarchie entsteht durch die Beschreibung von Ober- und Unterklassen

– Oberklasse: beschreibt allgemeine Eigenschaften von Objekten– Unterklasse: beschreibt Spezialisierung gegenüber der Oberklasse

Instanzen der Unterklasse haben die durch die Oberklasse beschriebenen Eigenschaf-ten, ergänzt oder abgeändert durch die in der Unterklasse beschriebene Spezialisierung

■ Beispiel einer Klassenhierarchie:

• Die OberklasseSpeicher beschreibt die allgemeinen Eigenschaften eines Speichers• Die Unterklassenpermanenter Speicher, flüchtiger Speicher undread-only Speicher

spezialisieren diese Eigenschaften — ein permanenter Speicher hat z. B. die Eigenschaft,dass sein Inhalt über einen Systemstart hinweg erhalten bleibt, während ein flüchtiger Spei-cher dies nicht garantiert. Ein read-only-Speicher würde bei einer Schreiboperation einenFehler melden.

• Diskette, Hard Disk und CD sind ihrerseits Unterklassen der (relativ hierzu) Oberklassepermanenter Speicher- CD ist aber auch gleichzeitig Unterklasse vonread-only Speicher(d.h. sie hat sowohl Eigenschaften von permanentem, als auch von read-only Speicher).

Von den Klassen und der Klassenhierarchie streng getrennt zu betrachten sind die einzelnen Objekte.• Von einer Klasse (z.B. Diskette) kann es mehrere Instanzen (= Objekte) geben.• Auch bei Objekten kann es Hierarchien geben (wenn ein Objekt aus anderen quasi "zusam-

mengebaut" ist) - das ist dann aber etwas ganz anderes als die Klassenhierarchie.

Speicher

read-onlySpeicher

flüchtigerSpeicher

RAM

permanenterSpeicher

Diskette CDHD

Spe

zial

isie

rung

Gen

eral

isie

rung

eine Diskette

KlassenObjekte / Instanzen




4 Objektorientiertes Design (3)

■ Konzepte in der Struktur moderner Programmiersprachen reflektiert

■ Grundlage: objektorientierte Dekomposition• Dekomposition, orientiert an den Einheiten desProblem domain— nicht an den Einheiten

oder Ausführungsschritten der Problemlösung (wie bei algorith. Dekomposition)➔ essentieller Unterschied zu algorithmischer Dekomposition und damit demTop-down struc-

tured design– andere Art, über Dekomposition nachzudenken– Software-Architektur wird völlig anders

➔ Software-Designer muß denProblem domain verstehen und überblicken — bei traditionel-ler Software-Entwicklung kommt diese (eigentlich selbstverständliche) Voraussetzung häu-fig zu kurz.

■ Vorteile:+ Wiederverwendung gemeinsamer Mechanismen

• Oberklassen beschreiben gemeinsame Eigenschaften, die in Unterklassen übernommen wer-den können.

➔ Software wird kleiner

+ Software leichter zu ändern und weiterzuentwickeln• Änderungen sind immer örtlich begrenzt (auf Klasse und evtl. deren Unterklassen)• keine globalen Datenstrukturen• Wiederverwendung durch gemeinsame Oberklassen garantiert gemeinsame Eigenschaften

– Änderung in der Oberklasse wirkt sich konsistent auf alle Unterklassen aus– keine Fehler bei Reimplementierungen

• Weiterentwicklung durch Bildung von Unterklassen

+ Ergebnisse weniger komplex• Inkrementelle Entwicklung aus kleinen, überschaubaren Systemen• OOD legt die Aufteilung großer Zustandsräume nahe (separation of concerns)

+ Besseres Verständnis des Auftraggebers für die Problemlösung• Die Begriffswelt des Auftraggebers findet sich in der Softwarelösung wieder

➤ Smalltalk

➤ C++

➤ Eiffel

➤ Java

➤ Ada


C Objektorientierte Programmierung C.5 Objektorientierte Programmierung


C.5 Objektorientierte Programmierung

1 Definition (Grady Booch [Boo94])OOP ist eine Methode der Implementierung, in der Programme in Form von

Mengen kooperierender Objekte

organisiert sind, wobei jedes Objekt

Instanz einer Klasse

ist und die Klassen Bestandteil einer über

Vererbungsbeziehungen

definierten Hierarchie von Klassen sind.

• Diese Definition enthält die wesentlichen Grundbegriffeobjektorientierter Programmierung:




2 Grundbegriffe

➔ Objekt• Objektorientierte Programmierung verwendet Objekte und nicht Algorithmen als die grund-

legenden Bausteine der Problemlösung

➔ Klasse• Jedes Objekt ist Instanz einer Klasse

➔ Vererbung• Klassen stehen über Vererbungsbeziehungen in Beziehung miteinander

Klasse

Objekt

Vererbung

Konstruktor

DestruktorPolymorphismus

Methode

TemplateMessage

Overloading

Typ




3 Objekte & Methoden

■ Sicht des Software-Entwicklers:◆ ein Objekt ist ein "Ding" aus der Problemstellung

➤ es hat einen Zustand➤ es hat Verhalten➤ es hat eine eindeutige Indentität

■ Programmiertechnische Sicht➤ eine gekapselte Einheit von Daten und Funktionen auf diesen Daten

• Zusammenfassung von Datenstrukturen und Operationen auf diesen Datenstrukturenzu einer Programmiereinheit

• Klassisches Beispiel: Ein Stack, dessen Zustand als verkettete Liste implementiert istund der die Operationenpush undpop anbietet

• Vorteile des Objekt-Konzepts:– Logisch zusammengehörige Programmteile stehen auch im Programmtext bei-

einander– Das Ergebnis von Operationen hängt nicht nur von den Aufrufparametern (wie

bei Funktionen) ab, sondern auch vom Zustand des Objekts (→ Operationen mit"Gedächtnis")

– Teile des Objekts können vor Zugriff von "außen" geschützt werden — der in-terne Aufbau des Objekts kann "geheim" bleiben (Information Hiding )

➤ ein Objekt hat eine klar definierte Schnittstelle (Operationen =Methoden)• Die Methoden eines Objekts definieren gleichzeitig dasVerhalten des Objekts

➔ Objektbasierte Programmiersprachen• Eine Programmiersprachen ist objekt-basiert, wenn sie Objekte als Sprachkonstrukt unter-

stützt [Weg87]• Probleme:

– Benötigt man von einem Objekt mehrere Exemplare (z. B. mehrere Stacks, um unter-schiedliche Informationen abzulegen), muß das Objekt entsprechend oft implemen-tiert werden

→ Abhilfe: Schablone zur Erzeugung von Objekten

OP 1OP 2

OP 3 Implementierung vonOP 1, OP 2 und OP 3

ZustandObjekt-

Schnittstelle




4 Klassen

• Auch wenn häufig nur ganz pragmatisch die programmiertechnische Sicht im Vordergrundsteht (eine Klasse ist etwas, an dem mannewaufrufen kann), ist vor allem die andere Sicht-weise von großer Bedeutung, weil sie ein wesentliches Strukturmerkmal der Software in denMittelpunkt rückt.

• Die Möglichkeit Klassen zu beschreiben und Instanzen zu erzeugen bildet auch den erstengroßen Unterschied von prozeduralen zu objektorientierten Programmiersprachen.

• Alle Instanzen können den in der Klasse implementierten Code für die Methoden gemein-sam nutzen, haben aber jeweils eine eigene Version des Objektzustands (der Variablen),gemäß der Strukturbeschreibung in der Klasse.

■ Instanzvariablen = Variablen eines Objekts (= Zustand)

➔ Klassenbasierte Programmiersprachen= Objekte & Klassen

Definitionen:• Eine Programmiersprachen ist klassen-basiert, wenn jedes Objekt eine Klasse besitzt

[Weg87]• Programmiersprachen, die die Formulierung von Klassen und die Instantiierung von

Objekten aus Klassen erlauben

■ Sicht des Software-Entwicklers◆ eine Klasse ist eine Menge von

Objekten mit gleicher Strukturund gleichem Verhalten

■ Programmiertechnische Sicht◆ Klasse = Schablone für Objekte

➤ jedes Objekt ist Instanzeiner Klasse

➤ Objekterzeugung =Instantiierung

Zustands-Beschr.Methoden

Zustand Obj. 1Methoden

Objekt 1

Klasse

Instantiierung


Objekt 2


Objekt 3




5 Vererbung

■ Beziehung zwischen Klassen, in dereine Klasse Struktur und/oder Verhalten übernimmt,das in einer anderen Klasse oder in mehreren anderen Klassendefiniert wurde

• Vererbung (engl.Inheritance) ist eine Technik, die es erlaubt, neue Klassen auf bereits exi-stierenden Klassen aufzubauen, statt sie vollständig neu zu programmieren. Die neu entste-hende Klassen wird alsUnterklasse (Subclass, derived class) bezeichnet, die Klasse, aufder aufgebaut wird, heißtOberklasse (Basisklasse, Superclass).

• Im Rahmen der Vererbung erbt die Unterklasse die Methoden und Variablen der Oberklasse.Außerdem kann die Unterklasse Variablen und Methoden hinzufügen oder umdefinieren.Prinzipiell könnte eine Unterklasse Methoden auch weglassen - die meisten Programmier-sprachen sehen dies aber nicht vor.

Beispiel:• In dem Beispiel gibt es eine allgemeine Klasse window, die all die Dinge enthält, die allen

Fenstern gemeinsam sind (z. B. Position, Größe, Rahmen sowie Methoden zum Verschie-ben, Größe verändern, Auf- und Zumachen).

• Die Unterklasse dialog enthält zusätzliche Möglichkeiten um Dialog mit einem Benutzer zuführen (sie weiß z. B. wenn der Fokus auf ihr liegt, kennt das Eingabe-Device, etc.)

• Ein yes/no-Dialog gibt nur die Möglichkeit, Buttons anzuklicken, während ein File-Dialogdie Struktur eines Dateibaums anzeigen kann und die Möglichkeit zur Texteingabe anbietet.

• Letzlich sind aber alle Dialoge auch Fenster, haben eine Größe, Position, etc.Vorteile:

• Die Implementierung der Oberklasse wird nicht verändert• Gleiche Funktionalität muss nicht mehrfach implementiert werden• Veränderungen der Oberklasse wirken auf alle Unterklassen• Beziehungen zwischen Klassen werden dokumentiert

window

dialog

window

dialog

y/n dialog file dialog

Vererbungshierarchie

Instanz einererbenden Klasse




5 Vererbung (2)

★ Begriffe

■ Unterklasse• Die neu entstehende Klassen wird alsUnterklasse (subclass, derived class) bezeichnet.

■ Oberklasse• Die Klasse, von der die Unterklasse abgeleitet wurde, heißtOberklasse oder auchBasis-

klasse(superclass, base class).

■ Einfache Vererbung• Bei einfacher Vererbung (single inheritance) hat eine Unterklasse nur genau eine Ober-

klasse.• Java sieht z. B. nur einfache Vererbung bei Klassen vor.

■ Mehrfache Vererbung

• Bei mehrfacher Vererbung (multiple inheritance) kann eine Klasse von mehreren anderenKlassen direkt erben➔ die Vererbungsbeziehungen bilden einen gerichteten Graph

• Probleme:– Namensgleichheit bei Komponenten der verschiedenen Basisklassen– Vererbung von Klassen auf unterschiedlichen Pfaden

• Anwendung:– weniger zur Wiederverwendung von Implementierung– primär zur Herstellung von Typkonformität (siehe Kapitel über Typisierung)

• C++ erlaubt z. B. mehrfache Vererbung.

window

dialog

file browser

file dialog

dialog

einfache Vererbung mehrfache Vererbung




5 Vererbung (3)

★ Sicht des Software-Entwicklers

■ Spezialisierung / Generalisierung von Klassen

■ Gemeinsame Aspekte von Klassen werden in Oberklasenzusammengefasst

■ Abstraktionshierarchie:◆ von allgemeineren Klassen zu spezialisierteren und umgekehrt

je nachdem was man zuerst hat• Generalisierung: wenn man bei der Problemanalyse die konkreteren Dinge zuerst gefunden

hat und dann gemeinsame Eigenschaften entdeckt und diese zusammenfassen möchte• Spezialisierung: wenn es unterschiedliche Ausprägungen "ähnlicher" Dinge gibt

■ Dokumentation der Beziehung zwischen Klassen




5 Vererbung (4)

★ Programmiertechnische Sicht

■ Erweiterung einer existierenden Klassenimplementierung um➤ zusätzliche Methoden

➤ weitere Daten

■ Wiederverwendung von Code:es ist keine Reimplementierung der geerbten Daten und Methodenerforderlich

■ Reimplementierung einer Methode ist möglich, wenn die Methode derOberklasse für die Unterklasse nicht passt

■ Methoden der Oberklasse können an einem Objekt der Unterklasseaufgerufen werden

■ Modifikationen der Oberklasse wirken auf alle Unterklassen(zentrale Softwarepflege)




5 Vererbung (5)

★ Reimplementierung

■ Reimplementierung einer Methode in der Unterklasse:➤ verdeckt die Methode der Oberklasse

➤ Default-Verhalten: Aufruf der Methode der Unterklasse

➤ Aufruf der der reimplementierten Methode der Oberklasse?• Die reimplementierte Methode der Unterklasse will evtl. in ihrer Implementierung auf die

"Originalmethode" der Oberklasse zurückgreifen. Zur Referenzierung von Methoden derOberklasse wird häufig ein spezielles Schlüsselwort — z. B.super — verwendet. In C++wird dies durch den Namen der Oberklasse und den Scope-Operator :: erreicht.

draw

draw

verdeckt

window

dialog




6 Vererbung in C++

■ Unterklasse erbt Variablen und Methoden von der Basisklasse

■ Unterklasse kann Basisklasse modifizieren➤ zusätzliche Methoden und Variablen

➤ veränderte Methoden

■ Methoden der Unterklasse haben Zugriff auf public- und protected -Bereich der Basisklasse

➤ public-Basisklasse

➔ die Schnittstelle der Basisklasse wird vererbt

• Daten und Methoden der Kategorienpublic undprotected haben diese Zugriffseigenschaf-ten auch in der Unterklasse, d. h.

– aufpublic-Daten und -Methoden von Instanzen der Unterklasse, die aus der Basisklas-se übernommen wurden, kann aus Funktionen und Methoden anderer Klassen zuge-griffen werden

➔ die Unterklasse stellt einenSubtyp des Typs der Basisklasse dar (vgl. Abschnittüber Typisierung)!

– wird diese Unterklasse im Rahmen weiterer Vererbung wieder als Basisklasse genutzt,können Methoden der weiteren Unterklasse ("Unter-Unterklasse") aufpublic- undprotected-Daten und -Methoden der ursprünglichen Basisklasse zugreifen, soweit die-se in der ersten Unterklasse nicht überlagert wurden.

➤ private-Basisklasse

➔ die Schnittstelle der Basisklasse wird nicht vererbt

• Daten und Methoden der Kategorienpublic undprotected werden mit der Zugriffseigen-schaftprivate in die Unterklasse übernommen, d. h.

– public-Daten und -Methoden der Basisklasse sind bei Instanzen der Unterklassepri-vate und damit nicht außerhalb sichtbar.

– Dadurch sind alle Methoden der Basisklasse an Instanzen der Unterklasse nicht auf-rufbar, es sei denn, sie wurden explizit für die Unterklasse neu definiert (eine solcheMethode der Unterklasse hat dabei auch die Möglichkeit, auf die entsprechende Me-thode gleichen Names der Basis-Klasse zuzugreifen, da für sie dieprivate-Einschrän-kung ja nicht gilt).

➔ der Typ der Unterklasse ist mit dem Typ der Basisklasse nicht in jedem Fall ver-träglich, ist alsokein Subtyp (vgl. Abschnitt über Typisierung)!

– public- undprotected-Daten und -Methoden der Basisklasse sind für Unterklassen derUnterklasse nicht sichtbar.

■ private-Daten und -Methoden der Basisklasse nicht sichtbar




7 Dynamisches Binden

■ Entscheidung welche Methode ausgeführt wird erfolgt zur Laufzeit(dynamisch)

Aufrufe virtueller Methoden in C++ werden immer dynamisch gebunden (late binding)• bei Zeiger auf Objekt wird Methode durch Instanz bestimmt

– Wird über einen Objektzeiger eine Methode aufgerufen, so wird die Methode des Ob-jekts, auf das der Zeiger gerade zeigt, ausgeführt.

– Ist es ein Objekt einer Unterklasse und wurde eine Methode der Basisklasse in der Un-terklasse umdefiniert, so wird der in Unterklasse implementierte Code ausgeführt.

• Wird an einen Zeiger auf ein Objekt einer Basisklasse eine Instanz einer Unterklasse zuge-wiesen, so sind nach wie vor nur die in der Basisklasse deklarierten Methoden aufrufbar

– in der Unterklasse neu hinzugekommene Methoden sind im Typ des Zeigers (= Typder Basisklasse) nicht angegeben und daher nicht bekannt.

■ Gilt auch, wenn ein Objekt eine Methode an sich selbst aufruft!◆ Beispiel:

– move() ruft am Ende display() auf, um das Fenster neu zu zeichnen– BorderedWindow erbt move() von Window– ein Aufruf von move() an einer Instanz von BorderedWindow ruft amEnde display() von BorderedWindow auf

Window *w = new BorderedWindow();w->display();

this this

super sub der Zeiger this referenziert immerdas "ganze Objekt" und nicht nur denTeil der Oberklasse




7 Dynamisches Binden (2)

■ Ohne dynamisches Bindenkeine “echte Vererbung”

➔ Selbstreferenz (Zeiger this) wird nichtrichtig angepasst

Ohne dynamisches Binden entsteht kein konsistentesObjekt der Unterklasse. Methoden der Oberklasse wür-den nach wie vor nur Implementierungen der Oberklasse aufrufen, selbst wenn die Unterklasseeine Reimplementierung hat, während reimplementierte Methoden der Unterklasse, die reimple-mentierten Methoden aufrufen würden.Beispiel:

Bei einem Aufuf der Methode m3 eines Oberklassenobjekts wird zweimal ober::m2 aufgerufen -einmal indirekt über m1, einmal direkt aus m3.Bei einem Aufruf von m3 an einem Unterklassenobjekt würde ohne dynamisches Binden aus derreimplementierten Methode zuerst das reimplementierte unter::m2 direkt aufgerufen werden, dannwürde das geerbte ober::m1 aufgerufen und von dort das "alte" ober::m2 - weil die reimplemen-tierte Fassung von m2 aus der geerbten Methode m1 nicht gefunden würde.

this

super sub

this

class ober {void m1() { … m2(); …}void m2() {… }void m3() {… m1(); m2(); }

}

class unter : public ober{

void m2() {… }void m3() {… m2(); m1(); }

}




8 Statisches Binden

■ Entscheidung welche Implementierung einer Methode genommen wirdfällt zur Übersetzungszeit

bei Zeiger auf Objekt wird auszuführende Methode durch Typ des Zeigers bestimmt:Wird über einen Zeiger auf ein Objekt einer Basisklasse eine Methode aufgerufen, so wird immerder in der Basisklasse definierte Code ausgeführt, unabhängig von dem Objekt, auf das der Zeigerzur Ausführungszeit gerade zeigt.

■ In C++ werden nur “virtual” -Methoden dynamisch gebunden◆ alle anderen Methoden werden generell statisch gebunden

■ In Java werden alle Methoden dynamisch gebunden• Methoden in Java entsprechen im wesentlichen den virtuellen Methoden in C++

◆ statisches Binden kann durch das Schlüsselwort final in der Methode-deklaration erzwungen werden

• Der Hauptgrund für statisches Binden in C++ ist Effizienz. Mit final-Methoden wurde inJava ein Mechanismus geschaffen, mit dem man in Einzelfällen ebenfalls Effizienz gegen-über "normalen", dynamisch gebundenen Aufrufen gewinnen kann.

◆ solche Methoden können in Unterklassen nicht reimplementiert werden

➔ Compiler kann statisch binden

• Im Gegensatz zu nicht-virtuellen Methoden von C++ kann hier in der Klassenhierarchie inden oberen Ebenen noch dynamisch gebunden werden. Erst ab der Subklasse, die dieMethode final deklariert hat abwärts ist die Methode statisch gebunden.

• Während bei C++ auch eine nicht-virtuelle Methode in einer Subklasse noch reimplemen-tiert werden kann (welche Methode tatsächlich aufgerufen wird hängt dann ja vom Typ desZeigers ab, über den aufgerufen wird), verhindert der Java-Compiler, daß eine final-Methode nochmals reimplementiert wird. Die Aufrufsemantik kann sich damit nie vondynamisch gebundenen Methoden unterscheiden!

public final void incr() { value += step; }


C Objektorientierte Programmierung C.6 Fundamentale Konzepte des objektorientierten Paradigmas


C.6 Fundamentale Konzeptedes objektorientierten Paradigmas

Eine Reihe programmiersprachlicher Konzepte, die unabhängig von den Ideen zur objektorientier-ten Programmierung entstanden sind, sind für das objektorientierte Paradigma von grundlegenderBedeutung:

■ Abstraktion◆ Kapselung

◆ Datenabstraktion in OOP

■ Modularisierung

■ Hierarchie

Weitere allgemeine programmiersprachliche Konzepte ergänzen viele objektorientierte Program-mierumgebungen. Teilweise erhielten solche Konzepte auch erst durch die Verbindung mit demobjektorientierten Paradigma praktische Bedeutung.

■ Typisierung◆ Typhierarchie

◆ Polymorphismus

◆ Generizität

■ Nebenläufigkeit

■ Persistenz




1 Abstraktion

Grundlegendes Konzept zur Lösung komplexer Probleme

■ Für Zusammenhänge relevante Aspekte hervorheben

■ Details vernachlässigen• Abstraktion hilft dem Software-Entwickler, sich auf das zu lösende Problem zu konzentrie-

ren und sich den Blick auf die eigentlichen Probleme nicht durch Implementierungsdetailszu verstellen!

➔ Objektorientierung

■ wichtig:➤ Signatur eines Objekts

➤ Semantik eines Objekts

➥ contract model: Sicht von aussen = Vertrag mit anderen Objekten

• Signatur: Beschreibung der Objektschnittstellen — Methoden, Parameter, Ergebnisse• Semantik: Auswirkung von Methodenaufrufen

Eine Klasse realisiert die Implementierung einer Abstraktion. Für den Anwender dieserKlasse — bzw. ihrer Instanzen — ist dabei lediglich der für ihn sichtbare Teil interessant.

– Sichtbar sind zum einen die Schnittstellen (=Methoden, Parameter und Resulate), zumanderen die Auswirkungen von Operationen auf das zukünftige Verhalten des Objekts.

– Änderungen des Objektzustands, die über die Schnittstellen nicht beobachtet werdenkönnen (z. B. ein Stack-Objekt fordert dynamisch Speicher nach, um weitere Datenspeichern zu können und gibt ihn auch selbsttätig wieder frei, wenn er nicht mehr be-nötigt wird), sind für den Benutzer des Objekts irrelevant.

■ unwichtig:➤ Implementierung eines Objekts

– Instanzvariablen– Implementierung von Methoden

• Die Implementierung eines Objekts sollte ausgewechselt werden können, solange sich dieSchnittstelle und die Semantik der Operationen nicht ändert. Dafür ist es aber wichtig, daßder Benutzer keine Kenntnisse über Implementierungsdetails erhält, die für seine Anforde-rungen nicht erforderlich sind. Er könnte sonst Annahmen über das Verhalten des Objektsmachen und sich auf diese Annahmen bei seiner Programmierung verlassen, obwohl solchein Verhalten durch den Implementierer des Objekts nie zugesichert wurde.

■ zuerst die Abstraktion beschreiben, dann Implementierung vornehmen• = zuerst Problemlösung spezifizieren, dann implementieren!

Sicht von aussen




2 Kapselung

= Information HidingVerbergen der Implementierung einer Abstraktion vor den Benutzern derAbstraktion

■ Gegenstück zu Abstraktion➤ Abstraktion stellt die äußeren Eigenschaften eines Objekts heraus

➤ Kapselung verbirgt die Interna

■ Grundvoraussetzung für AbstraktionB. Liskov Damit Abstraktionen funktionieren, müssen Implementierungen

gekapselt sein

■ Kapselung in der Objektorientierung◆ Darstellung des Objektzustands

◆ Implementierung der Methoden

➔ Abstrakter Datentyp, Datenabstraktion




2 Datenabstraktion in OOP

➔ auf Objektzustand kann nur durch die Methoden des Objekts zugegriffenwerden

• Viele Programmiersprachen erzwingen Datenabstraktion allerdings nicht (z. B. C++)• Häufig ist ein Kompromiss zwischen klarer Strukturierung und Disziplin sowie Flexibilität

und Effizienz erforderlich.• Vor allem in der Systemprogrammierung ist Datenabstraktion in der Praxis nicht bis in die

untersten Betriebssystemschichten durchzuhalten.– Hinter einem Objekt kann sich "ein Stück Hardware" (z. B. ein Controller oder ein

Prozessor) verbergen — Änderungen am Zustand solcher Objekte sind in manchenFällen trotzdem von "außen" zu beobachten (z. B. weil nach einem Aufruf an ein Ob-jekt, das den Treiber für eine serielle Schnittstelle realisiert, ein Signalpegel auf derSchnittstelle verändert wird und dadurch eine Telefonmodem-Verbindung abgebautwird).

■ Datenabstraktion in C++ und Java◆ Sichtbarkeitsbereiche (Scope-Regeln)

• Kapselung durchprivate- undprotected-Bereiche in Klassen• Objektschnittstellen impublic-Bereicheiner Klasse• private -Daten und -Methoden

– nur innerhalb von Methoden der gleichen Klasse sichtbar• protected -Daten und -Methoden (in Java:private protected)

– nur für Methoden der gleichen Klasse und in Methoden von Unterklassen sichtbar• public -Daten und -Methoden

– für alle Funktionen des Programms undfür alle Methoden anderer Klassen sichtbar

public -Methoden bilden die Schnittstelle der Klasse nach außenpublic -Daten erlauben eine Verletzung der Objektkapselung

➔ vermeiden!

Zustand

Meth. 1Meth. 2

Meth. 3

Zustand

Impl. Meth. 1Impl. Meth. 2

Impl. Meth. 3

Meth. 1Meth. 2

Meth. 3

Impl. Meth. 1Impl. Meth. 2

Impl. Meth. 3

Objekt als Implementierung eines ADT Objekt ohne Datenabstraktion




3 Modularisierung

Aufteilung eines Programms in einzelne Komponenten kann seineKomplexität reduzieren

◆ Teilproblem überschaubarer

◆ Teilprobleme Entwicklergruppen zuzuordnen

◆ Module = separate Softwareentwicklungseinheiten

■ vor allem: Aufteilung erzeugt Grenzen = Schnittstellen➔ Schnittstellen müssen klar definiert werden➔ Schnittstellen müssen dokumentiert werden

■ viele Programmiersprachen unterscheiden zwischen Schnittstelle undImplementierung eines Moduls➔ enge Beziehung zwischen Modularität und Kapselung

Die Unterstützung von Modularisierung in Programmiersprachen ist allerdings sehr unterschied-lich:

• In C oder C++ sind Module lediglich getrennt übersetzbare Dateien — Schnittstellen zwi-schen Modulen können über Include-Dateien konsistent gehalten werden. Die Sprachensehen allerdings keinerlei Mechanismen vor, die eine konsistente Benutzung der Schnittstel-len wirklich garantieren.

• Andere Sprachen (wie z. B. Modula) kontrollieren dagegen die Konsistenz der Modul-schnittstellen direkt.

• In Java gibt es ein eigenes Modularisierungskonzept:Packages– Zusätzliche Schutzattribute: Klassen oder Methoden sind damit nur innerhalb des ei-

genen Paketes sichtbar– Pakete spannen einen eigenen Namensraum auf

➔ keine Namenskonflikte zwischen unabhängig entwickelten Softwarekomponen-ten möglich

– Das Laufzeitsystem garantiert die Einhaltung der Schutzattribute und die konsistenteNutzung der Modulschnittstellen

■ Structured Design: Gruppierung von Unterprogrammen• Unterprogramme werden meist aufgrund ihrer Interaktionsbeziehungen auf Module verteilt.

■ OOD: Gruppierung von Objekten und Klassen• Bei der Programmierung komplexer Softwaresysteme entsteht eine große Anzahl von Klas-

sen➔ viele kleine Einheiten mit eigenen Schnittstellen➔ Beziehungen zwischen den Einheiten schwer überblickbar

• Aufgabe der Modularisierung im Rahmen von objektorientiertem Softwareentwurf istdamit, eine Gruppierung von Klassen auf Basis der Problemstruktur vorzunehmen. Diesekann sich von der Struktur, die durch die Interaktionsbeziehungen von Unterprogrammenentstehen würde stark unterscheiden!




4 Hierarchie◆ Abstraktion & Kapselung helfen Details von Komponenten zu verbergen

◆ Modularisierung hilft zusammengehörende Abstraktionen zu bündeln

■ Überblick über große Problemstellungen immer noch schwierig➔ zu viele Abstraktionen➔ Hilfsmittel zur Organisation von Abstraktionen notwendig

■ Abstraktionen bilden oft Hierarchien➤ gemeinsame Eigenschaften → allgemeinere Abstraktionen

➤ Unterschiede → Spezialisierungen

➔ Hierarchie: Ordnung auf Abstraktionen

■ Hierarchie & Objektorientierung➤ Klassenstruktur: Vererbung → "Art-von "-Hierarchie (kind of / is a)

• Vererbung• Delegation

➤ Objektstruktur: Aggregation → “Teil-von "-Hierarchie (part-of)• Aggregation — ein Objekt ist aus mehreren Unterobjekten zusammengesetzt

– Beispiel: Objekt Auto besteht aus Unterobjekten Motor, Getriebe, Lenkung, etc.




5 Typisierung

■ Typkonzept baut auf ADT-Theorie aufDefinitionen aus [Boo94]:

• Ein Typ ist eine genaue Charakterisierung der gemeinsamen Eigenschaften (bezüglichStruktur und Verhalten) einer Menge von Einheiten

• Typisierung ist das Erzwingen der Klasse eines Objekts, so dass Objekte unterschiedlicherTypen nicht oder zumindest nur in sehr eingeschränkter Weise untereinander ausgetauschtwerden können

Bei Objekten wird der Typ durch die Signatur und die Semantik der Methodenaufrufe bestimmt.Die meisten Programmiersprachen ermöglichen dem Programierer allerdings nur die Formulie-rung der syntaktischen Eigenschaften eines Typs.

– Bei vielen objektorientierten Sprachen (z. B. C++, aber nicht Java) erfolgt dies durchdie Beschreibung einer Klassenschnittstelle.

➔Die Beschreibung einer Klasse definiert gleichzeitig einen Typ.

■ Typisierung ermöglicht die Überprüfung von Ausdrücken auf Typ-Kompatibilität zur Übersetzungszeit

➔ Vermeidung von Fehlern• Zuweisungen unterschiedlicher Typen oder die Übergabe falscher Typen als Parameter von

Funktions- bzw. Methodenaufrufen kann zur Übersetzungszeit festgestellt werden. Aufdiese Weise lassen sich viele Fehler von vorneherein vermeiden.

■ Strenge TypisierungKonformität aller Typen in einem Ausdruck wird garantiert

➔ Statische TypisierungKonformität wird komplett zur Übersetzungszeit überprüft

➤ Einschränkung der Flexibilität

- kompatible Typen

Häufig kann der Compiler nicht feststellen, dass zwei unterschiedliche Typenkompatibel sind und damit in einem Ausdruck (z. B. einer Zuweisung) problem-los zusammen verwendbar sind.

- dynamisches Binden

Wenn erst zur Laufzeit festgelegt werden soll, welches Objekt (oder auch wel-che Funktion in nicht-OOP) über eine Variable erreichbar ist, kann die Typ-Ver-träglichkeit nicht generell zur Übersetzungszeit überprüft werden.

➔ mehr Flexibilität durch Polymorphismus und Generizität– Polymorphismus erlaubt neben der Verwendung des passenden Typs auch andere,

konforme Typen.– Generizität ermöglicht eine Parametrierung mit Typen. Dadurch können z. B. Klassen,

die für verschiedene Typen einsetzbar wären, aufgrund strenger Typisierung abernicht flexibel verwendet werden können, durch Typ-Parameter für die Verwendung inZusammenhang mit einem Typ eingestellt werden.




6 Typhierarchie

■ Häufig 1:1-Relation zwischen Klassen und Typen — aber nicht notwendig➤ mehrere Klassen können einen Typ implementieren

• Beispielsweise können unterschiedliche Klassen einen Datentyp "Stack" unterschiedlichimplementieren (Daten werden in einem Feld oder in einer verketteten Liste verwaltet), aberdie gleichen Methodenaufrufe (bezüglich Signatur und auch Semantik) anbieten.

➤ eine Klasse kann unterschiedliche Typen implementieren• Eine Klasse kann beispielsweise besondere Methodenaufrufe zur Einstellung von Parame-

tern oder Debug-Möglichkeiten besitzen, deren Verwendung in Teilen einer Anwendungs-implementierung aber nicht erlaubt sein darf (weil die Klasse möglicherweise später durcheine Implementierung ohne diese Methoden ersetzt werden soll). Wenn man in den Teilender Anwendung einen Typ für die Klasse bekanntgibt, der die besonderen Methodenaufrufenicht enthält, garantiert das Typsystem, dass sie auch nicht verwendet werden. In den Teilender Anwendung, die die besonderen Methodenaufrufe benötigen, wird ein anderer Typ fürdie Klasse deklariert, der die Methoden enthält.

■ Hierarchie bei Klassen: Oberklasse ← Unterklasse◆ Ziel: Wiederverwendung von Implementierung

◆ Unterklasse nicht notwenigerweise typ-konform zu Oberklasse• In den meisten Programmiersprachen (auch in C++ und Eiffel, nicht aber in Java) ist es mög-

lich, Unterklassen zu programmieren, die nicht typ-konform zur Oberklasse sind.• Unter dem Gesichtspunkt, durch eine Vererbung bei Klassen Programmcode wiederzuver-

wenden ist dies eigentlich unproblematisch. Da viele Programmiersprachen aber durchKlassendeklarationen gleichzeitig Typdeklarationen vornehmen, ist es wichtig, unterschei-den zu können, wo durch Klassen-Vererbung ein konformer Untertyp entsteht und wo nicht.

■ Hierarchie bei Typen: Obertyp ← Untertyp◆ Ziele: – Verhaltens-Vererbung

– Beschreibung konformer Typen (➔ Polymorphismus)• Durch eine Typhierarchie soll ausschließlich festgelegt werden, welche Typen zu welchen

anderen Typen konform sind.

■ Typvererbung (Subtyping) als Mechanismus zur Ableitung von Typen• Analog zur Vererbung bei Klassen: der Untertyp erbt von einem Obertyp• Unterschied zur Vererbung bei Klassen: der Untertyp ist auf jeden Fall konform zum Ober-

typ — d. h. er kann zusätzliche Methoden enthalten, enthält aber bezüglich Signatur undSemantik alle Methoden des Obertyps.

• Mehrfachvererbung bei Typen (ein Subtyp ist konform zu mehreren Obertypen) ist imGegensatz zu Mehrfachvererbung bei Klassen absolut unproblematisch, da keine Implemen-tierung verebt wird!

➔ Zusammenhänge zwischen Typen werden übersichtlich– Identifikation konformer Typen

• Durch die Typhierarchie ist festgelegt, welche (Unter-)Typen statt eines Typs in einem Aus-druck verwendet werden dürfen.




7 Polymorphismus

■ die Fähigkeit, verschiedene Formen anzunehmen [Mey88]➤ mehr als ein Typ für Werte oder Variablen

➤ verschiedene Typen als Parameter zu Funktionen

➤ verschiedene Typen als Operanden eines Operators

■ Beispiel:+-Operator arbeitet mit int- und real-Werten

■ Klassifikation [CW85]

universal polymorphism:• funktioniert prinzipiell mit beliebig vielen Typen (alle Typen haben aber eine gemeinsame

Grundstruktur — sind beispielsweise Subtypen eines gemeinsamen Obertyps, z. B. Zahlenin verschiedenen Darstellungen und Ausprägungen).

parametric polymorphism:– Eine polymorphe Funktion besitzt einen expliziten Parameter, in dem der Typ des Pa-

rameters für jeden Aufruf mit übergeben wird (spezielle Ausprägung dieses Konzeptsin Adasgeneric functions zu finden).

inclusion polymorphism:– Bei Subtyping: ein Untertyp kann jederzeit statt des Typs verwendet werden.

In objektorientierten Sprachen von großer Bedeutung: häufig mit Vererbung ge-koppelt — wenn eine Unterklasse einen Untertyp implementiert, können Instanzen derUnterklasse statt Instanzen der Basisklasse verwendet werden.

ad hoc polymorphism:• funktioniert nur auf einer endlichen Menge — möglicherweise völlig voneinander unabhän-

giger Typen.overloading:

– Mehrere verschiedene Funktionen werden unter dem gleichen Namen definiert und eswird anhand des Aufruf-Kontexts (Anzahl und Typ der Aufrufparameter) entschieden,welche Implementierung aufgerufen wird. (Beispiele siehe C++)

coercion:– Vor dem Aufruf der Funktion werden Parameter, deren Typ nicht mit der Funktions-

definition übereinstimmt, automatisch in den passenden Typ konvertiert.(Beispiel fürCoercion: in C wird bei der Addition eines int- und eines real-Wertes au-tomatisch eine Konvertierung beider Operanden nach double durchgeführt).

polymorphism

adhoc

universalparametric

inclusion

overloading

coercion

(Generizität)

(Untertypen)

(Typanpassung)




8 Polymorphismus in C++Einige Konzepte in C++ können zur Realisierung von Polymorphismus eingesetzt werden. Dabeisind drei Kategorien zu unterscheiden:

■ overloading polymorphism➤ Function-name overloading

➤ Operator overloading• Funktionen oder Operatoren eines Namens können für unterschiedliche Parameter- bzw.

Operandentypen definiert werden.

■ inclusion polymorphism➤ public Vererbung

• Da in C++ Subklassen gleichzeitig Subtypen des Datentyps der Basisklasse bilden, sind sietypkonform zur Basisklasse. Instanzen der Subklasse können daher statt Instanzen der Basis-klasse verwendet werden. In der Subklasse können dabei Methoden der Basisklasse andersimplementiert sein.

■ coercion polymorphism➤ Cast-Operatoren

• Für die Verwendung eines "unpassenden" Typs als Parameter oder in einem Ausdruck kön-nen für Einzelfälle Regeln beschrieben werden, wie der unpassende Typ in einen passendenTyp konvertiert wird. Diese Konvertierung erfolgt dann automatisch.




8 Polymorphismus in C++ (2)

★ Inclusion-Polymorphism — DER Polymorphismus in OOP

Vererbung + Virtuelle Methoden + Objekt-Referenzen

■ Eine Objektreferenz (Zeiger) hat einen Typ (= Klasse)◆ Instanzen dieser Klasse und ihrer Unterklassen können dem Zeiger

zugewiesen werden

◆ bei einem Methodenaufruf wird die tatsächlicheImplementierung der Methode nicht von der Klasse des Zeigers,sondern von der Klasse des aktuellen Objekts bestimmt

➔ Man kann jederzeit einer Referenz irgendein Typ-konformes Objektzuweisen und alles funktioniert

◆ man kann es als Parameter einer Methode übergeben

◆ der Programmierer der Methode musste den neuen Untertyp nicht kennen— so lange er konform zu dem Obertyp ist, den seine Methode erwartet




8 Polymorphismus in C++ (3)

★ Virtuelle Methoden & Inclusion Polymorphism — Beispiel:

• Der Aufrufptr->draw() bewirkt den Aufruf derdraw-Methode der Subklassecircle, obwohlptr ein Zeiger auf ein Objekt der Klassegeo_obj ist!

• Wäredraw in geo_obj nicht als virtual deklariert worden, hätte der Aufrufptr->draw() die Methode der Klassegeo_obj angesprochen, obwohl eine Instanz derUnterklassecircle anptr gebunden war.

• Die draw-Methoden der Unterklasse und auch diedraw-Methode der Oberklassegeo_obj müssen in obigem Beispiel natürlich noch außerhalb der Klassen definiert wer-den.

• Auf die Definition derdraw-Methode der Oberklasse könnte auch verzichtet werden,geo_obj wäre dann eine abstrakte Klasse (siehe Abschnitt über abstrakte Klassen).

– es könnten dann allerdings keine Instanzen vongeo_obj erzeugt werden, da dieKlasse nicht vollständig definiert ist

– geo_obj wäre dann nur als Basisklasse im Rahmen von Vererbung zu gebrauchen— in obigem Beispiel durchaus sinnvoll, weil einedraw-Methode, die nicht näher be-schriebene geometrische Objekte zeichnen kann, wohl ohnehin keinen Sinn macht.

Virtuelle Methoden einer Subklasse, die eine virtuelle Methode der Basiklasse neu implementie-ren, sind automatisch wieder virtuell (z. B. bei weiterer Vererbung).

➔ void draw(); in der Klassecircle ist damit korrekt, es muß nichtvir-tual davor angegeben werden!

class geo_obj { // general superclasspublic:virtual void draw();

};

class circle : public geo_obj { // subclasspublic:void draw();

}

class square : public geo_obj { // subclasspublic:void draw();

}

main () {geo_obj *ptr;ptr = new circle;ptr->draw();

...




9 Typen und C++: Abstrakte Klassen

■ Basisklasse deklariert Methoden und Parameter, definiert sie aber nicht– pure virtual function

➔ Basisklasse beschreibt einen Typ

■ Subklassen definieren unterschiedliche Implementierungen derMethoden

➔ jede Subklasse stellt eine Implementierung des Typs dar

■ Basisklasse ist nicht instantiierbar

■ Beispiel:

• Die Klassegeo_obj beschreibt lediglich die Signatur von geometrischen Objekten, enthältaber keinerlei Implementierungen.

• Unterklassen vongeo_obj stellen dann konkrete Implementierungen verschiedener geo-metrischer Objekte dar, die alle konform zu dem Datentypgeo_obj sind (und damit z. B.an einen Zeiger aufgeo_obj zuweisbar sind).

• Grundsätzlich können auch einzelne (virtuelle) Methoden, die für alle Subklassen gleichsein sollen, in der abstrakten Basisklasse definiert werden und andere, die erst in den Sub-klassen implementiert werden sollen, alspure virtual functions angegeben werden. DieBasisklasse ist dann nach wie vor eine abstrakte Klasse, da sie nicht vollständig implemen-tiert ist, sie entspricht aber nicht mehr einer reinen Typdefinition, sondern ist eine Mischungaus Typdefinition und -implementierung.

• Genauso können Subklassen von abstrakten Klassen auf die Definition einerpure virtualfunctionverzichten (sie müssen deren Deklaration aber explizit wiederholen!). Solche Sub-klassen sind dann nach wie vor abstrakte Klassen und können nur im Rahmen von weitererVererbung eingesetzt werden.

class geo_obj { // abstract classpublic:virtual void draw() = 0; // pure virtual function

};class circle : public geo_obj { // subclasspublic:void draw() { ... }

}




10 Typen und Java: Interfaces

■ 2 Möglichkeiten einen Typ zu deklarieren:◆ im Rahmen einer Klassendefinition

• Java kennt auch abstrakte Klassen wie in C++• Nachteile der impliziten Typ-Deklarationen durch Klassen:

– Es ist nur einfache Vererbung möglich. Ein durch eine Klasse definierter Typ kann da-mit nur an von dieser Klasse abgeleitete Unterklassen vererbt werden.

– Es gibt keine Möglichkeiten, andere, unabhängig definierte, aber typ-kompatibleKlassen zu solch einem Typ konform zu erklären.

➔ Klassenvererbung führt automatisch zu Typvererbung

• Es ist in Java nicht möglich, Subklassen zu bilden, die nicht typ-konform zur Oberklassesind.

◆ durch eine Interface-Deklaration➔ separate Typbeschreibung

• Die Typ-Beschreibung erfolgt getrennt alsinterface• Danach kann im Rahmen einer Klassendefinition angegeben werden, daß die Klasse den

Typ implementiert.• Der Compiler überprüft, ob in der Klassenimplementierung auch tatsächlich die Schnitt-

stelle des Typs korrekt angegeben ist.

■ Beispiel:public interface Printable {

public void Print();}

public class MyPoint extends Object implements Printable {....public void Print() {

System.out.println("x="+x+" y="+y);}

}




10 Typen und Java: Interfaces (2)

■ Vererbung & Mehrfachvererbung auf Interfaces• Während bei Klassenvererbung nur Einfachvererbung möglich ist, ist auf Typen auch Mehr-

fachvererbung zugelassen- d. h. ein Typ kann konform zu verschiedenen Obertypen sein

• Da nur Schnittstellenkonformität deklariert wird, aber keine Implementierung übernommenwird, treten die Konfliktprobleme der Mehrfachverbung bei Klassen natürlich nicht auf.

■ eine Klasse kann mehrere Typen implementieren• Bei einer Klassendefinition können mehrere, ggf. auch unterschiedliche Schnittstellen ange-

geben werden, die von der Klasse implementiert werden.

■ Typkonformität ist transitiv• Wenn eine Klasse einen Typ implementiert, dann implementieren automatisch auch alle

Subklassen davon diesen Typ.

■ Exceptions sind auch Bestandteil der Typ-Schnittstelle• Im Gegensatz zu C++ können in Java auch die Exceptions, die eine Methode erzeugt in der

Typ-Schnittstelle angegeben werden.• Ein Subtyp darf, um konform zu sein, nur die Exceptions des Basistyps (ggf. natürlich weni-

ger Exceptions) bzw. konforme Exceptions erzeugen– Exceptions werden in Java durch Klassen repräsentiert. Eine konforme Exception ist

damit eine Unterklasse bzw. eine zum Exception-Typ ebenfalls konforme Klasse.

■ Beispiele:

• Der TypStreamable ist von den beiden TypenFileIO undPrintable abgeleitet.• Die Methode Test kann eine ExceptionTestException erzeugen — diese Tatsache ist

Bestandteil des TypsStreamable.• Die Klasse Test implementiert die beiden TypenStreamable undTestinterface

interface Streamable extends FileIO, Printable {// additional Methodspublic void test() throws TestException;

}

class Test implements Streamable, Testinterface {...

}




11 Generizität ( Genericity)

■ Möglichkeit, den Typ von programmiersprachlichen Einheiten durchParameter festzulegenBeispiele:

• generische Funktionsargumente (ein Funktionsparameter bestimmt den Typ anderer Para-meter)

• generische (parametrierbare) Klassen

■ OOP: generische Klassen

generische Klasse ➔ Instantiierung (+Parametrierung) ➔ tatsächliche Klassetatsächliche Klasse ➔ Instantiierung von Objekten

■ Beispiel:◆ allgemeine Klasse Stack

– int-Stack

– real-Stack

– string-Stack

■ Generizität kann weitgehend mit Vererbung nachgebildet werden[Mey86]Aber: eigentlich werden dadurch die Begriffswelten von Typ und Klasse (wie so oft) vermischt: Ge-

nerizität ist ein Konzept, um mehr Flexibilität im Bereich Typisierung zu erreichen, während Ver-erbung Klassenhierarchien erzeugt!

■ realisiert in Ada, Eiffel, C++ (ab. V 3.0, Templates) und Java (ab Java 5)




12 Generizität und C++: Templates

■ Ziel: Klassendefinition ohne Festlegung auf bestimmte Typen• Vor allem wenn Klassen in Standardbibliotheken bereitgestellt werden sollen, gibt es viele

Fälle, in denen von vorneherein nicht festgelegt werden kann, für welche Typen solch eineKlasse gebaut werden soll. Typische Beispiele sind Container-Klassen wie Listen, Vektorenoder assoziative Felder.

• Grundsätzliche gibt es zwei Möglichkeiten, die Konstruktion solcher Klassen in einer Sprache zuunterstützen:

◆ dynamische Typprüfung zur Laufzeit• Die betreffenden Typen werden zur Übersetzungszeit nicht festgelegt und durch dynamische

Typprüfung zur Laufzeit wird eine konsistente Verwendung von Parametern und Instanzva-riablen überprüft. Insbesondere in nicht-getypten Sprachen (wie Smalltalk) wird dieser Weggewählt. Die Programmierung wird dadurch einfacher, vor allem sind alle Klassen sehr fle-xibel einsetzbar. Zur Laufzeit entsteht aber beträchtlicher Mehraufwand durch die dynami-schen Typprüfungen.

◆ statische Typprüfung zur Übersetzungszeit + parametrierbare Klassen• Die korrekte Verwendung von Typen bei Parameterübergabe und bei Zuweisungen wird zur

Übersetzungszeit komplett überprüft. Um Klassen definieren zu können, ohne sich auf allein der Klassenimplementierung verwendeten Typen von vorneherein festlegen zu müssen,werden parametrierbare Klassen eingeführt: Die Klassendefinition enthält Parameter, die inder Implementierung statt eines Typs eingesetzt werden können.

■ Template = parametrierbare Klasse

■ Beispiel:

• In der Klassendefinition können neben einem oder mehreren Typparametern auch andereParameter auftreten. In dem Beispiel könnte man neben dem Typ T beispielsweise auchdie Stackgröße als Template-Parameter angeben. Man könnte dann ein Objekt "Integer-Stack mit 10 Elementen" instantiieren. Dieses Objekt hätte aber einen anderen Typ als ein"Integer-Stack mit 20 Elementen". Wird die Größe dagegen im Konstruktor angegeben, soinstantiiert man Objekte vom Typ "Integer-Stack" und übergibt dem Konstruktor diegewünschte Größe. Der Typ solcher Objekte (auch unterschiedlicher Größe) ist dann iden-tisch.

template <class T> class stack {private:int index;T *array;

public:void stack(int n)

{ index = 0; array = new T[n]; }void push(T elem)

{ array[index++] = elem; }T pop(void)

{ return(array[--index]); }};




13 Generizität und Java (ab Java 5)

■ auf den ersten Blick ähnlich zu C++-Templates,aber viele Unterschiede im Detail

➤ nur eine generische Klasse für alle Objekte• es wird keine parametrisierte Klasse erzeugt, von der Instanzen gebildet werden, sondern der

Bytecode der Klasse liegt zur Laufzeit nur einmal vor• Type-Erasure: Typ-Variablen werden durch Object (bzw. bei Bounds durch den angegebe-

nen Obertyp) ersetzt. Compiler fügt Casts in den Code ein, um zur Laufzeit Typ-Sicherheitzu gewährleisten.

➤ Bounds erlauben die Einschränkung von Typ-Variablen auf bestimmteSubtypen• T extends C & T1 & T2 ...

Typ T muss Untertyp der Klasse C bzw. der Interfaces T1 oder T2 ... sein

■ Typ-Parametrierung auch auf Interfaces möglich

■ Beispiel:

class AnimalStack <T extends Animal> {private int index;private T[] array;

public void AnimalStack(int n){ index = 0; array = (T[])new Object[n];}

public void push(T elem){ array[index++] = elem; }

public T pop(){ return(array[--index]); }

};




14 Nebenläufigkeit (Concurrency)

Nebenläufigkeit: mehrere Aktivitätsträger werden parallel von mehrerenProzessoren bearbeitet oder von einem Prozessor simuliert

■ Nebenläufigkeit orthogonal zu Objektorientierungaber: Komplexität einer Problemlösung wird durch Nebenläufigkeit erhöht

zusätzliche Probleme:• Koordinierung

– gegenseitiger Ausschluß• Synchronisation

– warten auf Ergebnisse anderer Aktivitätsträger• Verteilung

– Verteilen der auszuführenden Objekte auf die verfügbaren Prozessoren

■ Granularität: Nebenläufigkeit / Objekte (Kapseln)➤ Nebenläufigkeit feiner granular

➔ NL auch objektintern

– mehrere Aktivitätsträger gleichzeitig in einem Objekt→ objektinterne Koordinierung erforderlich

➤ Nebenläufigkeit grober granular

➔ NL nur objektextern

– immer nur maximal ein Aktivitätsträger zu jedem Zeitpunkt in einem Objekt→ keine Koordinierungsprobleme innerhalb eines Objekts, Koordinierung kann aufdie Objektinteraktionen beschränkt werden

■ Integration der Kontrolle von Nebenläufigkeit in objektorientierteSprachen

➤ orthogonale Sprachen• Orthogonale Sprachen enthalten keine Sprachkonstrukte zur Kontrolle von Nebenläufigkeit.

Zur Koordinierung muß der Programmierer sprach-externe Mechanismen wie z. B. Sema-phore einsetzen.

➤ nicht-orthogonale Sprachen• In nicht-orthogonalen Sprachen können Objekte gegen nebenläufige Ausführung geschützt

werden. Dies wird entweder automatisch für alle Objekte vorgenommen➔ uniforme Sprachenoder es kann durch Sprachkonstrukte vom Programmierer festgelegt werden, ob ein Objektgeschützt werden soll➔ nicht-uniforme Sprachen.




15 Nebenläufigkeit und Java

■ Thread-Konzept und Koordinierungsmechanismen sind in Java integriert➥ nicht-orthogonale, nicht-uniforme Sprache bzgl. Nebenläufigkeit

■ Erzeugung von Threads über Thread-Klassen• Die auszuführenden Methode wird in einer speziellen Klassen, die ein InterfaceRunnable

implementiert als Methoderun implementiert.– Thread erzeugen = “run-Methoden”-Objekt instantiieren,

Thread-Objekt instantiieren und dem Konstruktor das"run-Methoden"-Objekt übergeben

– Thread starten = Methodestart an Thread-Objekt aufrufen,➞ Methoderun wird nebenläufig ausgeführt

• Es wird eine Subklasse von Thread definiert, die dierun-Methode redefiniert. Eine Instanzder Subklasse wird erzeugt und an ihr die Methodestart aufgerufen.

– Thread erzeugen = Objekt der Subklasse instantiieren– Thread starten = Methodestart an dem Objekt aufrufen

➞ Methoderun wird nebenläufig ausgeführt

■ Beispielclass MyClass implements Runnable {

public void run() {System.out.println("Hello\n");

}}

....MyClass o1 = new MyClass(); // create objectThread t1 = new Thread(o1); // create thread to run in o1

t1.start(); // start thread

Thread t2 = new Thread(o1); // create second thread to run in o1

t2.start(); // start second thread




15 Nebenläufigkeit und Java (2)

★ Koordinierungsmechanismen

■ Monitore: exclusive Ausführung von Methoden eines Objekts• Methoden oder Code-Blöcke könnensynchronized deklariert werden• Alle synchronized-Methoden und Code-Blöcke eines Objekts (einer Instanz, nicht aller

Instanzen einer Klassen gemeinsam!) bilden gemeinsam einen Monitor: d.h. es kann immernur einThread zu einem Zeitpunkt in einer der Methoden bzw. Code-Blöcke aktiv sein.

• Ein Objekt kann weitere Methoden besitzten, die nicht als synchronized deklariert wurden.Solche Methoden (z.B. Methoden, die nur auf dem Objektzustand lesen, aber keine kriti-schen, koordinierungsbedürftigen Operationen ausführen) können auch mehrfach parallelausgeführt werden.

◆ Beispiel:

◆ Conditions: gezieltes Freigeben des Monitors und Warten auf ein Ereignis• Innerhalb eines Monitors kann "wait" aufgerufen werden

⇒ Monitor wird freigegeben und Thread legt sich schlafen.• Jemand anderes kann innerhalb des Monitors "notify" oder "notifyAll" aufrufen

⇒ Einer der bzw. alle blockierten Threads werden aufgeweckt

class Bankkonto {int value;public synchronized void AddAmmount(int v) {

value=value+v;}public synchronized void RemoveAmmount(int v) {

value=value-v;}

}...Bankkonto b=....b.AddAmmount(100);




15 Nebenläufigkeit und Java (3)

★ Koordinierungsmechanismen in Java 5

■ mehrere APIs zur Unterstützung von Nebenläufigkeit

■ Atomare Operationen➤ z.B. getAndSet oder compareAndSet auf Boolean, Integer oder Long

➤ Paket java.util.concurrent.atomic

■ Locks und Condition Variablen➤ orthogonale Implementierung zusätzlich zu synchronized/wait/notify

• Vorteil: flexiblere Handhabung von Monitoren im Gegensatz zu den in die Sprache inte-grierten Mechanismen

• Nachteil: expliziter Umgang mit Koordinierungsmechansmen ggf. fehlerträchtiger

➤ Paket java.util.concurrent.locks

■ Umfangreiches Paket java.util.concurrent➤ thread-sichere Container, Queues, Collections

➤ Executor-Framework, Thread-Pools, Futures, Scheduling

➤ Semaphore, Latches, Barrieren




16 Persistenz

★ Motivation für Persistenz [ABC83]

■ “aktive” Daten → Programmiersystem• “Aktive” Daten, diekurzfristig im Speicher angelegt sind, werden mit den Hilfsmitteln des

Programmiersystems (Sprache) bearbeitet.

■ “passive” Daten → DBMS oder Dateisystem• “Passive” Daten, die die Programmausführung überleben sollen, werden einer Datenbank

(DBMS) oder einem Dateisystem übergeben und mit dessen Funktionen verwaltet.

➔ 2 Sichten auf Daten

➔ Nachteile für den Anwender

➤ Konvertierung notwendig• Programmieraufwand für die Konvertierung und den Transport zwischen passivem und akti-

vem Zustand (scanf/printf-Anweisungen)(Atkinson schätzt i. a. ca. 30% des Codes!)

➤ Datenschutz des Programmiermodells geht verloren• Schutzmechanismen des Programmiermodells (z. B. Typisierung) greifen nur, solange

Daten aktiv sind - bei der ersten Wandlung kann alles verloren gehen.

★ allgemeine Definition:Persistenz ist die Eigenschaft von Daten, das Ende einer Umgebung, inder sie entstanden oder benutzt wurden, zu überdauern




16 Persistenz (2)

★ Persistenz in objektorientierten Systemen

■ Objekte überleben das Ende der Umgebung (Aktivitätsträger,Anwendungsausführung), in der sie instantiiert oder benutzt wurden

■ In OO-Betriebssystemen mächtiger Basis-Mechanismus➤ Datenspeicherung

➤ Datentransport

■ Beispiele➤ Dateisysteme

• Eine traditionelle Datei ist ein persistentes Objekt mit Methoden wieread, write undseek.

➤ Datenbanksysteme

➤ persistente Kommunikationsobjekte• Beispielsweise ein Puffer-Objekt

■ Eigenschaften des objektorientierten Programmiermodells gehenautomatisch auf Mechanismen über, die damit erstellt wurden

C Objektorientierte Programmierung C.1 Überblick C ... · Jürgen Kleinöder • Universität...

Documents

Transcript of C Objektorientierte Programmierung C.1 Überblick C ... · Jürgen Kleinöder • Universität...