Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus.

Ähnliche Präsentationen


Präsentation zum Thema: "Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus."—  Präsentation transkript:

1 Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus

2 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 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 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 5 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

6 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

7 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 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 9 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

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

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

12 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 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 14 Beispiel rename class STUDENTISCHE_HILFSKRAFT inherit STUDENT rename personennummer as matrikelnummer inherit LEHRSTUHLMITARBEITER rename personennummer as mitarbeiternummer end....

15 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 16 Beispiel Redefinition class KREIS inherit ELLIPSE redefine berechne_umfang end feature berechne_umfang is do -- hier neue Implementierung einfügen... end

17 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 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

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

21 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 dynamischer Typ Typ Name Wert

22 22 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 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 24 Dynamisches Binden bewegen fahren Variable meinFahrzeug : Statischer Typ: FAHRZEUG Dynamischer Typ: AUTO meinFahrzeug.bewegen

25 25 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

26 26 class A feature {B, C} x: INTEGER y: REAL methode_1 is do... end Exportliste 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

27 27 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) ExportlisteSichtbarkeitsbereich Beispiele Exportliste

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

29 29 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

30 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 31 Typen von Zusicherungen Vorbedingungen Nachbedingungen Klasseninvarianten Schleifenvarianten Schleifeninvarianten

32 32 Vorbedingung Nachbedingung Programmlogik ClientSupplier Routinenaufruf Vorbedingung prüfen Exception Routine abarbeiten Nachbedingung prüfen Rückgabe Vor- und Nachbedingungen routine_1routine_2

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

34 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 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 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 37 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

38 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 39 routine_1 is rescue -- rescue-Block ensure -- Nachbedingung do -- Routinen-Quelltext require -- Vorbedingung end 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 Fehlerbehandlung

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

41 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 42 Basis- Routine Routine 1Routine 2Routine 3 Routinenaufruf X Rescue Block retry retry-Anweisung

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

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

45 45 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

46 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


Herunterladen ppt "Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus."

Ähnliche Präsentationen


Google-Anzeigen