Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus.

EiffelEin 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







• 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

• Entstehungsgeschichte von Eiffel

• Allgemeines zu Eiffel• Besondere Aspekte von Eiffel






• 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

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 HELLOcreation hello_worldfeature

hello_world isdo

print (”Hello World”)end

end

9

Gliederung


– Einfach- und Mehrfachvererbung– Dynamisches Binden und Polymorphismus




• Fazit

10

Klasse AUTO ist konform zu Klasse FAHRZEUGKlasse FAHRZEUG ist nicht konform zu Klasse AUTOKlasse AUTO ist komform zu sich selbstKlasse 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 AUTOinherit FAHRZEUG.....

FAHRZEUG

AUTO

11

class STUDENTISCHE_HILFSKRAFTinherit STUDENT, LEHRSTUHLMITARBEITER...

Mehrfachvererbung

• Eine Klasse kann in Eiffel beliebig viele Vaterklassen haben• Vererbungsgraph hat keine klassische Baumstruktur mehr

STUDENTLEHRSTUHL

MITARBEITER

STUDENTISCHE_HILFSKRAFT

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_HILFSKRAFTinherit STUDENT

rename personennummer as matrikelnummerinherit LEHRSTUHLMITARBEITER

rename personennummer as mitarbeiternummerend....

STUDENTLEHRSTUHL

MITARBEITER


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 KREISinherit ELLIPSE

redefineberechne_umfang

endfeature

berechne_umfang is do-- hier neue Implementierung einfügen...

end

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

STUDENTLEHRSTUHL

MITARBEITER


berechne_alter berechne_alter

berechne_alter

19

undefine

• Zurückversetzen eines effektiven Features in den deffered Zustand

• Dabei keine Änderung der Signatur des Features

Beispiel:

class Binherit A

undefine methode_1end...

20

Gliederung



– Dynamisches Binden und Polymorphismus– Selektiver Export von Features



• 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

dynamischer TypTyp

Name

Wert

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

Beispiele Polymorphismus

Variable Objekt

Statischer Typ: FAHRZEUG

Wert: Dynamischer Typ: FAHRZEUG


Wert: Dynamischer Typ: AUTO

Statischer Typ: AUTO

Wert: Dynamischer Typ: FAHRZEUG

24

FAHRZEUG

AUTO

Dynamisches Binden

bewegen

fahren

Variable meinFahrzeug:


Dynamischer Typ: AUTO

meinFahrzeug.bewegen

25

Gliederung




– Selektiver Export von Features– Programming by Contract


• Fazit

26

class Afeature {B, C}

x: INTEGERy: REALmethode_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

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)

Exportliste Sichtbarkeitsbereich

Beispiele Exportliste

28

Beispiel:

class B inherit Aexport

{C} x{D, E} y, methode_1

endend

Ä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

Gliederung





– 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

Vorbedingung

Nachbedingung

ProgrammlogikProgrammlogik

Client Supplier

Routinenaufru

fVorbedingungprüfen

Exceptio

n Routineabarbeiten

Nachbedingungprüfen

Rückgabe

Vor- und Nachbedingungen

routine_1 routine_2

33

sqrt (p: REAL): REAL is

end

do-- Quadratwurzel berechnen....

Programmlogik

ensureabs ((result * result) - p) < 0.001 Nachbedingung

Vorbedingungrequire

p >= 0

Beispiel Vor- und Nachbedingungen

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

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

Basis-Routine Routine 1 Routine 2 Routine 3

Routinenaufruf Routinenaufruf Routinenaufruf

XException

XException

XException

X

RescueBlock

RescueBlock

RescueBlock

RescueBlock

Organisierte Panik

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

RescueBlock

retry

retry-Anweisung

43

RückmeldungRückmeldungRückmeldung



RescueBlock

retry

retry-Anweisung

44

try_once_or_twice islocal

already_tried: BOOLEANdo

if not already_tried thenmethod_1

elsemethod_2

endrescue

if not already_tried thenalready_tried := trueretry

endend

Beispiel retry-Anweisung

45

Gliederung







• 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

Vielen Dank für Eure Aufmerksamkeit

Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus.

Documents

Transcript of Eiffel Ein Vortrag im Rahmen des Seminars Programmiersprachen Christian Niehaus.