Ein Vortrag im Rahmen des Seminars “Programmiersprachen” Eiffel Ein Vortrag im Rahmen des Seminars “Programmiersprachen” Christian Niehaus

Gliederung Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Gliederung Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Entstehungsgeschichte Entwickelt 1985 durch Bertrand Meyer und Jean Marc Nerson Namensgeber ist Gustave Eiffel, der Konstrukteur des Eiffelturms Streng objektorientierte Programmiersprache nach Vorbild von Simula Seit 1987 kommerzielle Vermarktung Heute zahlreiche frei verfügbare Eiffel-Compiler im Internet

Gliederung Allgemeines zu Eiffel Entstehungsgeschichte von Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Allgemeines Compiler-Sprache Gehört zur Klasse der objektorientierten Sprachen Programm als System miteinander interagierender Klassen Unterstützung von (Mehrfach-) Vererbung Dynamisches Binden Polymorphismus Datenabstraktion / Abstrakte Klassen Compiler-Sprache --> Umwandlung Eiffel-Code in C-Code merkt man bei einigen Compilern nicht mehr

Allgemeines Fünf Basistypen: INTEGER, REAL, DOUBLE, CHARACTER, BOOLEAN Alle anderen Datentypen müssen als Klassen realisiert werden Automatische Speicherverwaltung Automatische Zuweisung von Speicherbereichen an neu erstellte Objekte Automatische Bereinigung des Speichers mittels Garbage Collector

Klassen Klasse besteht aus sog. Features (Methoden/Funktionen, Variablen und Konstanten) Alle Variablen sind Teil eines Objekts, keine globalen Variablen Auch Hauptprogramm in Form einer Klasse class HELLO creation hello_world feature hello_world is do print (”Hello World”) end

Gliederung Einfach- und Mehrfachvererbung Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Vererbung Kindklasse erbt die Features von Vaterklasse Immer Vererbung aller Features, kein selektives Erben nur einzelner Features Kindklasse ist konform zur Vaterklasse class AUTO inherit FAHRZEUG ..... Klasse AUTO ist konform zu Klasse FAHRZEUG Klasse FAHRZEUG ist nicht konform zu Klasse AUTO Klasse AUTO ist komform zu sich selbst Klasse FAHRZEUG ist konform zu sich selbst

Mehrfachvererbung Eine Klasse kann in Eiffel beliebig viele Vaterklassen haben Vererbungsgraph hat keine klassische Baumstruktur mehr class STUDENTISCHE_HILFSKRAFT inherit STUDENT, LEHRSTUHLMITARBEITER ...

Möglichkeiten der Feature-Übernahme Unveränderte Übernahme von geerbten Features Umbenennen von geerbten Features (rename) Redefinition von geerbten Features (redefine) Effecting von geerbten Features Zusammenfügen von geerbten Features (join) undefine von geerbten Features

Umbenennen von Features Feature erhält einen neuen Namen, unter dem es auch weitervererbt werden kann Alter Name des Features kann anderweitig vergeben werden Keine Änderung der Funktionalität Mögliche Gründe: Name eines geerbten Features passt vom Sinn her nicht mehr in die Kindklasse Namenskonflikt durch Mehrfachvererbung

Beispiel rename class STUDENTISCHE_HILFSKRAFT inherit STUDENT rename personennummer as matrikelnummer inherit LEHRSTUHLMITARBEITER rename personennummer as mitarbeiternummer end ....

Redefinition von Features Änderung von Implementierung Signatur Zusicherungen eines Features Neue Signatur muss konform zur alten sein, d.h. Anzahl Parameter darf sich nicht ändern Neue Typen von Parametern und Rückgabewert müssen konform zu bisherigen Typen sein

Beispiel Redefinition class KREIS inherit ELLIPSE redefine berechne_umfang end feature berechne_umfang is do -- hier neue Implementierung einfügen ...

Effecting Implementieren eines sog. deferred Features Feature wird dadurch zu effektivem Feature Arbeitet nach denselben Regeln wie Redefinition Wird zusammen mit Redefinition unter dem Oberbegriff Redeklaration zusammengefasst

Join Automatisches Zusammenfassen von mehreren geerbten deferred Features zu einem einzigen Feature Features müssen dabei identische Namen und Signaturen haben Zusammenfassen von Features mit unterschiedlichen Signaturen nicht möglich berechne_alter berechne_alter

undefine Zurückversetzen eines effektiven Features in den deffered Zustand Dabei keine Änderung der Signatur des Features Beispiel: class B inherit A undefine methode_1 end ...

Gliederung Dynamisches Binden und Polymorphismus Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Statischer und dynamischer Typ Variable besteht Typ, Name und Wert Ist Typ eine Klasse, so besteht Wert aus einem Verweis auf ein Objekt Typ untergliedert sich dann in statischen und dynamischen Typ statischer Typ ist derjenige Typ, der bei Variablendeklarion festgelegt wurde dynamischer Typ ist der Typ desjenigen Objekts, auf das die Variable derzeit referenziert Statischer Typ ist während gesamter Laufzeit fest Dynamischer Typ kann sich während Laufzeit ändern Variable statischer Typ Typ Name Wert dynamischer Typ

Polymorphismus Polymorphismus Statischer und dynamischer Typ müssen nicht übereinstimmen Variable kann während Laufzeit Objekte unterschiedlicher Typen annehmen Dynamischer Typ muss aber stets konform zu statischem Typ sein Polymorphismus

Beispiele Polymorphismus Variable Objekt Statischer Typ: FAHRZEUG Wert: Dynamischer Typ: FAHRZEUG Statischer Typ: FAHRZEUG Wert: Dynamischer Typ: AUTO Statischer Typ: AUTO Wert: Dynamischer Typ: FAHRZEUG

Dynamisches Binden meinFahrzeug.bewegen bewegen fahren Variable meinFahrzeug: Statischer Typ: FAHRZEUG Dynamischer Typ: AUTO

Gliederung Selektiver Export von Features Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Selektiver Export von Features Häufig sollen Features nicht für beliebige andere Objekte sichtbar sein Features können selektiv nur für Objekte bestimmter Klasse sichtbar gemacht werden Dazu Anpassung des Exportstatus Exportstatus eines Features kann bei dessen Deklaration mittels sog. Exportliste festgelegt werden Exportliste class A feature {B, C} x: INTEGER y: REAL methode_1 is do ... end

Beispiele Exportliste Sichtbarkeitsbereich feature {A, B, C} alle Objekte, die konform zu Klassen A, B oder C sind feature {ANY} feature alle Objekte feature {NONE} feature {} keine Objekte (privates Feature)

Änderung des Exportstatus Exportstatus wird an Unterklassen weitervererbt Exportstatus geerbter Features kann in der Unterklasse nachträglich geändert werden Beispiel: class B inherit A export {C} x {D, E} y, methode_1 end Feature x ist jetzt für alle Klassen sichtbar, die konform zu C sind. Features y und methode_1 sind jetzt für alle Klassen sichtbar, die konform zu D oder E sind.

Gliederung Programming by Contract Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Programming by Contract Dient der Korrektheit und Robustheit des erstellten Programms Kommunikation zwischen Objekten beruht auf sog. Zusicherungen Zusicherungen Präzise festgelegte Verpflichtungen zwischen aufrufender Routine (client) und aufgerufener Routine (supplier) Vertrag zwischen Client und Supplier Bestehen aus boolschen Ausdrücken Bei Nichterfüllung einer Zusicherung wird Exception geworfen

Typen von Zusicherungen Vorbedingungen Nachbedingungen Klasseninvarianten Schleifenvarianten Schleifeninvarianten

Vor- und Nachbedingungen routine_1 routine_2 Vorbedingung prüfen Programmlogik Routinenaufruf Vorbedingung Exception Routine abarbeiten Programmlogik Rückgabe Nachbedingung prüfen Nachbedingung Client Supplier

Beispiel Vor- und Nachbedingungen sqrt (p: REAL): REAL is Vorbedingung require p >= 0 do -- Quadratwurzel berechnen .... Programmlogik ensure abs ((result * result) - p) < 0.001 Nachbedingung end

Klasseninvariante Für gesamtes Objekt gültig (nicht für einzelne Routinen) Muss zu jedem Zeitpunkt erfüllt sein, zu dem von außerhalb auf das Objekt zugegriffen werden kann Gut geeignet für allgemeine Konsistenzbedingungen

Schleifeninvariante Stellt korrekten Ablauf von Schleifen sicher Muss nach Schleifeninitialisierung sowie vor jedem Durchlauf erfüllt sein Nichterfüllen führt zu Abbruch der Schleife und Werfen einer Exception

Schleifenvariante Stellt sicher, dass keine Endlosschleifen auftreten INTEGER-Ausdruck, der zu Beginn der Abarbeitung größer Null sein muss Muss bei jedem Schleifendurchlauf dekrementiert werden Hat Schleifenvariante Null erreicht, so bricht die Schleife ab

Gliederung Fehlerbehandlung und Exceptions Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Fehlerbehandlung und Exceptions Bei Auftreten eines Fehlers wird sog. Exception geworfen Ohne spezielle Fehlerbehandlung führt Exception zu Abbruch der betreffenden Routine Ähnlich wie bei Java

Fehlerbehandlung Fehlerbehandlung mittels sog. rescue-Block Frei implementierbares Codestück einer Routine Wird nur ausgeführt, wenn in betreffender Routine ein Fehler aufgetreten ist Geeignet z. B. zum erneuten Initialisieren von Variablen oder Sicherstellen von Invarianten routine_1 is rescue -- rescue-Block ensure -- Nachbedingung do -- Routinen-Quelltext require -- Vorbedingung end

X X X X Organisierte Panik Basis- Routine Routine 1 Routine 2 Routinenaufruf Exception X X Exception X Exception X Rescue Block Rescue Block Rescue Block Rescue Block

retry-Anweisung Darf nur innerhalb eines rescue-Blocks stehen Bewirkt einen Neustart der gescheiterten Routine Allerdings keine automatische Neu-Initialisierung der Variablen Vor retry sollte in rescue-Block dafür gesorgt werden, dass Vorbedingungen und Invarianten erfüllt sind

X retry-Anweisung retry Basis- Routine Routine 1 Routine 2 Routine 3 Routinenaufruf X retry Rescue Block

retry-Anweisung retry Basis- Routine Routine 1 Routine 2 Routine 3 Routinenaufruf Rückmeldung Rescue Block retry

Beispiel retry-Anweisung try_once_or_twice is local already_tried: BOOLEAN do if not already_tried then method_1 else method_2 end rescue already_tried := true retry

Gliederung Fazit Entstehungsgeschichte von Eiffel Allgemeines zu Eiffel Besondere Aspekte von Eiffel Einfach- und Mehrfachvererbung Dynamisches Binden und Polymorphismus Selektiver Export von Features Programming by Contract Fehlerbehandlung und Exceptions Fazit

Fazit Mächtige Sprache Dennoch schlanke, leicht erlernbare Syntax Schwerpunkt liegt auf Korrektheit und Robustheit des erstellten Codes Gute Wiederverwendbarkeit und Erweiterbarkeit von bestehendem Code sehr strenge Objektorientierung sehr komplexe Vererbungsbeziehungen durch Mehrfachvererbung

Vielen Dank für Eure Aufmerksamkeit