Ein Vortrag im Rahmen des Seminars “Programmiersprachen”

Präsentation zum Thema: "Ein Vortrag im Rahmen des Seminars “Programmiersprachen”"—  Präsentation transkript:

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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

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

12 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

13 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

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

15 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

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

17 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

18 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

19 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 ...

20 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

21 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

22 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

23 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

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

25 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

26 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

27 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)

28 Ä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.

29 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

30 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

31 Typen von Zusicherungen
Vorbedingungen Nachbedingungen Klasseninvarianten Schleifenvarianten Schleifeninvarianten

32 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

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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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

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

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

44 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

45 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

46 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

47 Vielen Dank für Eure Aufmerksamkeit