Grundlagen der Informatik I “Programmierung”
Grundlagen der Informatik I “Programmierung” Grundlagen der Informatik I “Programmierung”
Bei der Erzeugung von Objekten mittels clone(person 1) ist zu berücksichtigen, daß Verweise, die im Objekt person 1 enthalten sind, als Verweise identisch kopiert werden und nicht etwa zu jedem Verweis ein weiteres Objekt kopiert wird. Man sagt auch, daß clone eine flache (shallow) Kopie erzeugt: das neue Objekt ist wirklich in allen Komponenten identisch mit person 1. In manchen Anwendungen ist es jedoch notwendig, eine komplette Kopie der gesamten Objektstruktur zu erzeugen, die an der genannten Stelle beginnt. Eine solche “tiefe” Kopie wird durch die Funktion deep clone generiert. Genau besehen erzeugt also der Aufruf deep clone(person 1) einen Verweis auf ein neues Objekt, dessen Komponenten mit einfachen Datenkomponenten mit denen von person 1 identisch sind und dessen Verweiskomponenten wiederum auf neue Objekte verweisen, die mit den entsprechenden in person 1 angesprochenen Objekten bis auf Verweise identisch sind usw. Kopieren von Objektzuständen: Neben clone, der Erzeugung neuer Objekte, gibt es eine weitere sinnvolle Möglichkeit, Objekte inhaltlich zu kopieren, nämlich bestehenden Objekten die Zustände anderer Objekte zuzuweisen. Dies geschieht mit der Prozedur (nicht Funktion!) copy. Während der Befehl autor := person 1 der Größe autor nur den in person 1 enthaltenen Verweis zuweist und autor := clone(person 1) ein zuvor nicht vorhandenes Objekt erzeugt, wird durch autor.copy(person 1) ein bereits existierendes durch autor bezeichnetes Objekt verändert (deshalb auch die Verwendung der Punktnotation: die Operation copy arbeitet auf dem Objekt, auf das autor verweist). Dieses Objekt erhält in jeder Komponente den Wert der entsprechenden Komponente des durch person 1 bezeichneten Objekts. Der in autor enthaltene Verweis wird dagegen nicht verändert. Wichtig ist aber, daß autor keinen leeren Verweis enthalten darf. Genauso wie clone erzeugt copy eine flache Kopie von Objekten. Wird eine tiefe Kopie benötigt, so ist die Prozedur deep copy anzuwenden, wie zum Beispiel in autor.deep copy(person 1) Vergleich von Objekten: Wegen des schon öfter angesprochenen Unterschiedes zwischen einem Objekt und dem Verweis darauf gibt es zwei Möglichkeiten, Objekte zu vergleichen. Die gewöhnliche Gleichheit = stellt die Frage, ob die beiden Objekte identisch sind. Die Funktion equal testet, ob die beiden Objekte in jeder Komponente dieselben Werte haben. Das hat wieder zu tun mit der Tatsache, daß Größen, welche Objekte bezeichnen, in Wirklichkeit Verweise auf diese Objekte sind. Gleichheit der Größen bedeutet, daß die Verweise gleich sind, also daß auf dasselbe Objekt verwiesen wird. Der Ausdruck autor = person 1 liefert true, wenn autor und person 1 dasselbe Objekt bezeichnen, und sonst false. Das Umgekehrte, der Test auf Ungleichheit der Objekte, wird durch autor /= person 1 ausgedrückt. Die Funktion equal geht einen Schritt weiter. Statt einfach die Verweise zu vergleichen, betrachtet sie die Zustände der durch autor und person 1 bezeichneten Objekte. equal(autor,person 1) liefert true, wenn entweder die mit autor und person 1 verbundenen Verweise beide leer sind, oder wenn beide bezeichneten Objekte in jeder Komponente übereinstimmen (das bedeutet aber, daß in Komponenten enthaltene Verweise wieder auf dasselbe Objekt zeigen müssen). Wenn autor = person 1 gilt, dann gilt auch equal(autor,person 1) aber nicht umgekehrt. Auch equal führt einen “flachen” Vergleich durch. equal(autor,person 1) gilt nur, wenn Verweise in Komponenten der durch autor und person 1 bezeichneten Objekte jeweils auf dasselbe Objekt zeigen. Der Vergleich, ob die bezeichneten Objekte strukturell identisch sind, wird aufgerufen mit deep equal(autor,person 1)
Gegenüber früheren Versionen von Eiffel (vor allem gegenüber dem Buch “Object-oriented Software Construction”, aber auch gegenüber dem Skript von Prof. Henhapl) haben sich in der Syntax dieser Operationen einige Änderungen ergeben. Der Grund hierfür war laut [Meyer, 1992] hauptsächlich eine Vereinheitlichung der Semantik für die Punktnotation (nur anwendbar auf nichtleere Verweise), die in den alten Formen etwas unsystematisch war. 11 Die folgende Tabelle beschreibt die Zusammenhänge. Frühere Versionen Eiffel 3 autor.Create !!autor autor.Forget autor := Void autor.Void autor = Void autor.Clone(person 1) autor := clone(person 1) autor.Equal(person 1) equal(autor,person 1) Natürlich gibt es in Eiffel viele weitere vordefinierte Operationen, mit denen man in Eiffel so rechnen kann, wie in jeder anderen Programmiersprache. Da aber Arithmetik und ähnliche Operationen nichts spezifisches für die objektorientierte Denkweise sind, verschieben wir die Besprechung der “konventionellen Programmierkonzepte” auf die nächsten Kapitel. 3.3.5 Das aktuelle Exemplar Eine der herausragenden Eigenschaften der objektorientierte Denkweise ist, daß jedes Programmkonstrukt sich auf ein Objekt bezieht. Man schreibt nie ein Programmstück, welches nur sagt “tue dies”, sondern gibt allen Befehlen die Form “tue dies an diesem Objekt”. Um zu erkennen, auf welches Objekt sich ein Stück Eiffel-Text bezieht, muß man berücksichtigen, daß jeder Eiffel-Text Teil von genau einer Klasse ist. Ein höheres Konstrukt als Klassen gibt es in Eiffel nicht. Jede Klasse beschreibt einen Datentyp, dessen Exemplare zur Ausführungszeit die Objekte sind. Der Klassentext zeigt die Merkmale, die all diese Objekte gemeinsam haben, indem ein typisches Exemplar der Klasse, das sogenannte aktuelle Exemplar, beschrieben wird. Daher bezieht sich jeglicher Eiffel-Text auf genau dieses aktuelle Exemplar, d.h. jedes Vorkommen des Attributs autor innerhalb der Klasse BUCH bezieht sich auf die Komponente des aktuellen Buch-Objektes, welche dem Attribut autor entspricht. Die Zuweisung erscheinungsdatum := 1993 in der Klasse BUCH bedeutet also, daß der Komponente erscheinungsdatum des aktuellen Exemplars von BUCH der Wert 1993 zugewiesen wird. Oft aber ist es auch notwendig, auf andere Objekte zu verweisen. Hierfür verwendet man in Eiffel die bereits angesprochene Punktnotation. Definition 3.3.4 (Qualifiziertes Vorkommen von Attributen) Es sei entity ein Attribut vom Klassentyp K und a ein Attribut der Klasse K, dann bezeichnet entity.a die Komponente a des Objektes, welches zur Laufzeit mit entity verbunden wird. entity.a heißt qualifiziertes Vorkommen von a. Die Punktnotation kann beliebig verschachtelt werden. Man beachte jedoch, daß selbst qualifizierte Vorkommen von a das Konzept des aktuellen Exemplars (nämlich entity) benötigen. Beispiele haben wir bereits im vorhergehenden Abschnitt gegeben. Ein qualifiziertes Vorkommen eines Attributs wird in Eiffel immer als eine Funktion behandelt und nicht etwa als Name einer Komponente. Aus diesem Grunde kann man nur den Komponenten des aktuellen Exemplars 11 Konzeptionell weist Eiffel 3 keine Änderungen gegenüber früheren Versionen auf. Änderungen beschränken sich auf eine Verbesserung der Syntax (konsistenter und deutlicher), die Klärung semantischer Unsauberkeiten, und die Hinzunahme einiger neuer sinnvoller Konstrukte als vordefinierte Bestandteile der Sprache
- Seite 43 und 44: Kapitel 2 Logik und formale Sprachb
- Seite 45 und 46: 2.1 Formale Sprachbeschreibungen Di
- Seite 47 und 48: möglichen Alternativen auf der rec
- Seite 49 und 50: Wenn wir eine Menge von Sprachen be
- Seite 51 und 52: Da wir im folgenden den Begriff der
- Seite 53 und 54: Für die Zuordnung zwischen der Obj
- Seite 55 und 56: Diese Form der Definition findet ih
- Seite 57 und 58: K1: Kommutativ-Gesetz E1 ∧E2 ≡
- Seite 59 und 60: Axiomenschemata: L1 A ∨ ¬A L2 (A
- Seite 61 und 62: In dem Kapitel über die Programmve
- Seite 63 und 64: 2. Es werden Quantoren eingeführt,
- Seite 65 und 66: s (T, state) = wahr s (F, state) =
- Seite 67 und 68: • x ist gebunden in p(t1, ..., tn
- Seite 69 und 70: Der Wert einer Aussage mit mehreren
- Seite 71 und 72: Wichtig ist, daß die Auswahl des W
- Seite 73 und 74: Wir geben hier eine Funktion an, di
- Seite 75: wichtigste formale Sprache zur Besc
- Seite 78 und 79: Wir wollen jedoch deutlich darauf h
- Seite 80 und 81: Buch, sondern sollten besser als ei
- Seite 82 und 83: Viel sinnvoller ist es, bei der Bes
- Seite 84 und 85: Entsprechend ihrer beabsichtigten B
- Seite 86 und 87: Klassen sind rein statische Beschre
- Seite 88 und 89: leeren Verweis (d.h. von machen Per
- Seite 90 und 91: haben wie z.B. “(jahr:INTEGER)”
- Seite 92 und 93: und diese erzeugten Objekte mit Ver
- Seite 96 und 97: über den Namen eines Attributs Wer
- Seite 98 und 99: • Die Veränderung und Auswertung
- Seite 100 und 101: 3.5 Copy- und Referenz-Semantik In
- Seite 102 und 103: 3.5.2 expanded: Klassen mit Copy-Se
- Seite 104 und 105: class LIST[X] creation new feature
- Seite 106 und 107: Dieses Problem wird durch das Konze
- Seite 108 und 109: 3.7.1 Zusicherungen Eiffel logische
- Seite 110 und 111: class ARRAY[X] creation make featur
- Seite 112 und 113: class ARRAY[X] creation make featur
- Seite 114 und 115: formulieren und zu überwachen. Eig
- Seite 116 und 117: 3.8.2 Export geerbter Features Norm
- Seite 118 und 119: Ist also p ein Personenobjekt und a
- Seite 120 und 121: Definition 3.8.5 (Konformität) Ein
- Seite 122 und 123: Um die Beschreibung des Typsystems
- Seite 124 und 125: Nachkommenklassen aber folgt entity
- Seite 126 und 127: deferred class LIST[X] feature leng
- Seite 128 und 129: class STUDENT feature universität:
- Seite 130 und 131: Das Problem ist nun, daß beide Elt
- Seite 132 und 133: Prinzipiell wäre es sogar möglich
- Seite 134 und 135: Das bedeutet also, daß die Erbenkl
- Seite 136 und 137: Die eigentliche Montage eines Syste
- Seite 138 und 139: Verständlichkeit der Module: Die L
- Seite 140 und 141: dynamische Semantik: Die dynamische
- Seite 142 und 143: Constant ::= Manifest constant | Id
Gegenüber früheren Versionen von Eiffel (vor allem gegenüber dem Buch “Object-oriented Software Construction”,<br />
aber auch gegenüber dem Skript von Prof. Henhapl) haben sich in <strong>der</strong> Syntax dieser Operationen<br />
einige Än<strong>der</strong>ungen ergeben. Der Grund hierfür war laut [Meyer, 1992] hauptsächlich eine Vereinheitlichung<br />
<strong>der</strong> Semantik für die Punktnotation (nur anwendbar auf nichtleere Verweise), die in den alten Formen etwas<br />
unsystematisch war. 11 Die folgende Tabelle beschreibt die Zusammenhänge.<br />
Frühere Versionen Eiffel 3<br />
autor.Create !!autor<br />
autor.Forget autor := Void<br />
autor.Void autor = Void<br />
autor.Clone(person 1) autor := clone(person 1)<br />
autor.Equal(person 1) equal(autor,person 1)<br />
Natürlich gibt es in Eiffel viele weitere vordefinierte Operationen, mit denen man in Eiffel so rechnen kann,<br />
wie in je<strong>der</strong> an<strong>der</strong>en Programmiersprache. Da aber Arithmetik und ähnliche Operationen nichts spezifisches<br />
für die objektorientierte Denkweise sind, verschieben wir die Besprechung <strong>der</strong> “konventionellen Programmierkonzepte”<br />
auf die nächsten Kapitel.<br />
3.3.5 Das aktuelle Exemplar<br />
Eine <strong>der</strong> herausragenden Eigenschaften <strong>der</strong> objektorientierte Denkweise ist, daß jedes Programmkonstrukt<br />
sich auf ein Objekt bezieht. Man schreibt nie ein Programmstück, welches nur sagt “tue dies”, son<strong>der</strong>n gibt<br />
allen Befehlen die Form “tue dies an diesem Objekt”.<br />
Um zu erkennen, auf welches Objekt sich ein Stück Eiffel-Text bezieht, muß man berücksichtigen, daß je<strong>der</strong><br />
Eiffel-Text Teil von genau einer Klasse ist. Ein höheres Konstrukt als Klassen gibt es in Eiffel nicht. Jede<br />
Klasse beschreibt einen Datentyp, dessen Exemplare zur Ausführungszeit die Objekte sind. Der Klassentext<br />
zeigt die Merkmale, die all diese Objekte gemeinsam haben, indem ein typisches Exemplar <strong>der</strong> Klasse, das<br />
sogenannte aktuelle Exemplar, beschrieben wird. Daher bezieht sich jeglicher Eiffel-Text auf genau dieses<br />
aktuelle Exemplar, d.h. jedes Vorkommen des Attributs autor innerhalb <strong>der</strong> Klasse BUCH bezieht sich auf die<br />
Komponente des aktuellen Buch-Objektes, welche dem Attribut autor entspricht. Die Zuweisung<br />
erscheinungsdatum := 1993<br />
in <strong>der</strong> Klasse BUCH bedeutet also, daß <strong>der</strong> Komponente erscheinungsdatum des aktuellen Exemplars von<br />
BUCH <strong>der</strong> Wert 1993 zugewiesen wird.<br />
Oft aber ist es auch notwendig, auf an<strong>der</strong>e Objekte zu verweisen. Hierfür verwendet man in Eiffel die bereits<br />
angesprochene Punktnotation.<br />
Definition 3.3.4 (Qualifiziertes Vorkommen von Attributen) Es sei entity ein Attribut vom Klassentyp<br />
K und a ein Attribut <strong>der</strong> Klasse K, dann bezeichnet entity.a die Komponente a des Objektes, welches<br />
zur Laufzeit mit entity verbunden wird.<br />
entity.a heißt qualifiziertes Vorkommen von a.<br />
Die Punktnotation kann beliebig verschachtelt werden. Man beachte jedoch, daß selbst qualifizierte Vorkommen<br />
von a das Konzept des aktuellen Exemplars (nämlich entity) benötigen. Beispiele haben wir bereits im<br />
vorhergehenden Abschnitt gegeben.<br />
Ein qualifiziertes Vorkommen eines Attributs wird in Eiffel immer als eine Funktion behandelt und nicht etwa<br />
als Name einer Komponente. Aus diesem Grunde kann man nur den Komponenten des aktuellen Exemplars<br />
11 Konzeptionell weist Eiffel 3 keine Än<strong>der</strong>ungen gegenüber früheren Versionen auf. Än<strong>der</strong>ungen beschränken sich auf eine<br />
Verbesserung <strong>der</strong> Syntax (konsistenter und deutlicher), die Klärung semantischer Unsauberkeiten, und die Hinzunahme einiger<br />
neuer sinnvoller Konstrukte als vordefinierte Bestandteile <strong>der</strong> Sprache
Change language