Upload
leudbold-anich
View
105
Download
1
Embed Size (px)
Citation preview
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
• 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
• 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
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
• 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
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
STUDENTISCHE_HILFSKRAFT
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
STUDENTISCHE_HILFSKRAFT
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
• 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
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
Statischer Typ: FAHRZEUG
Wert: Dynamischer Typ: AUTO
Statischer Typ: AUTO
Wert: Dynamischer Typ: FAHRZEUG
24
FAHRZEUG
AUTO
Dynamisches Binden
bewegen
fahren
Variable meinFahrzeug:
Statischer Typ: FAHRZEUG
Dynamischer Typ: AUTO
meinFahrzeug.bewegen
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
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
• 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
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
• 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
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
Basis-Routine Routine 1 Routine 2 Routine 3
Routinenaufruf Routinenaufruf Routinenaufruf
X
RescueBlock
retry
retry-Anweisung
43
RückmeldungRückmeldungRückmeldung
Basis-Routine Routine 1 Routine 2 Routine 3
Routinenaufruf Routinenaufruf Routinenaufruf
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
• 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
Vielen Dank für Eure Aufmerksamkeit