Grundlagen der Informatik I “Programmierung”
Grundlagen der Informatik I “Programmierung” Grundlagen der Informatik I “Programmierung”
3.8.2 Export geerbter Features Normalerweise werden alle features einer Elternklasse unverändert übernommen. Es gibt jedoch Gründe, Ausnahmen von dieser Regel zu vereinbaren. Manche Merkmale der Elternklasse PERSON machen im Zusammenhang mit der Verwaltung von Entleihern nur wenig Sinn: weder das Todesdatum noch die Nationalität sind von irgendeinem Interesse. Daher sollten diese features von der Klasse ENTLEIHER nicht wieder als Dienstleistungen bereitgestellt werden. Da sie nicht innerhalb der Klasse ENTLEIHER definiert, sondern geerbt wurden, kann man ihre Verbreitung auch nicht durch die Form der feature-Klausel kontrollieren, sondern benötigt eine explizite Export-Vereinbarung. In Eiffel wird dies durch Angabe einer export-Klausel innerhalb der Beschreibung der Vererbungseigenschaften ermöglicht. class ENTLEIHER inherit PERSON export name, vornamen, geburtsdatum end -- feature-Anpassung von PERSON feature straße, hausnummer, stadt: STRING; postleitzahl : INTEGER; ausweisnummer: INTEGER end -- class ENTLEIHER Abbildung 3.29: Klassendefinition mit Export geerbter features Die Angabe des Schlüsselwortes export besagt, daß die dahinter aufgezählten von PERSON geerbten features zusammen mit den neuen features als Dienstleistungen der Klasse ENTLEIHER bereitstehen. Die nicht genannten features todesjahr und nationalität sind nicht mehr benutzbar. Fehlt die export-Klausel, so sind alle von PERSON geerbten features erneut verfügbar. Das Schlüsselwort end beendet Modifikationen der geerbten features. Auch beim Export geerbter features kann es sinnvoll sein, die Weitergabe von Informationen von der Kundenklasse abhängig zu machen. So könnte es zum Beispiel sein, daß die Nationalität eines Arbeitnehmers – ebenfalls ein Spezialfall von Personen – für das Finanzamt aus steuerrechtlichen Gründen von Bedeutung ist, nicht aber für den Arbeitgeber. Aus diesem Grunde erlaubt Eiffel einen selektiven Export geerbter features. Die Syntax ist vergleichbar mit der in Abschnitt 3.4 angegebenen Form für feature-Klauseln: export { Klassenliste1} featurelist1; . { Klassenlisten} featurelistn Die Klasse ARBEITNEHMER in Abbildung 3.30 exportiert an die Klasse ARBEITGEBER – und an alle Erben dieser Klasse– die geerbten features name, vornamen, geburtsjahr sowie alle neu vereinbarten features 20 , an die Klasse FINANZAMT jedoch alle geerbten (und die neuen) features. Zur Vereinfachung der Schreibweise gibt es hierfür in Eiffel (Version 3) das Schlüsselwort all. Es besagt, daß alle features der Elternklasse an die in der Klassenliste aufgezählten Klassen geliefert werden. Fehlt die export-Klausel, so bleibt ein geerbtes geheimes feature geheim und ein exportiertes features wird weiter exportiert. Dieses Verhalten kann jedoch in der export-Klauseln nach Belieben verändert werden, da die Erben einer Klasse – im Gegensatz zu den Kunden – alle Rechte (und Pflichten) ihrer Ahnen besitzen und damit umgehen dürfen, wie sie es für richtig halten. Sie dürfen daher für ihre Kunden ein geheimes feature wieder exportieren bzw. ein exportiertes feature verstecken 21 . 20Wir haben hier der Einfachheit halber die vier Komponenten straße, hausnummer, stadt, postleitzahl einer Adresse in einem Objekt zusammengefaßt. 21Hier gibt es allerdings feine Grenzen, da sonst die Korrektheit des Gesamtsystems verletzt werden könnte.
class ARBEITNEHMER inherit PERSON export {ARBEITGEBER} name, vornamen, geburtsjahr; {FINANZAMT} all end -- feature-Anpassung von PERSON feature adresse: ADRESSEN; gehaltsklasse: STRING; gehalt: REAL is -- Gehalt berechnen do Result := Gehalt aus Tabelle nach gehaltsklasse end end -- class ARBEITNEHMER Abbildung 3.30: Klassendefinition mit selektivem Export geerbter features Diese Koppelung der Vererbung mit dem in Abschnitt 3.4 diskutierten Geheimnisprinzip hat eine Reihe interessanter Anwendungen. Sie erlaubt es, durch verschiedene Erbenklassen auch verschiedene Sichten auf eine Datenstruktur zu ermöglichen und hierüber die unterschiedlichen Zugriffsrechte zu regeln. So gibt es zum Beispiel bei einem Bankkonto die Vorgänge eröffnen, abheben, einzahlen, geheimzahl eingeben, geheimzahl prüfen, geheimzahl ändern, löschen, gebühren einziehen, konto sperren, usw. Nicht jeder dieser Vorgränge darf vom Kunden selbst ausgeführt werden (für die Eröffnung des Kontos sind z.B. einige Vorschriften zu beachten) sondern nur von den Bankangestellten am Schalter und umgekehrt. Andere Vorgänge (Kontosperrung) dürfen nur von Angestellten des Managements ausgelöst werden. Diese verschiedenen Sichten auf ein und dieselbe Datenstruktur läßt sich durch Vererbung auf eine sehr einfache und übersichtliche Art realisieren. Die in Abbildung 3.31 genannten Erben der Klasse BANKONTO stellen jeweils einen Teil der Dienstleistungen der Ahnenklasse bereit und darüber hinaus noch ihre eigenen speziellen features. ✬ ✫ SCHALTER ✬ BANKONTO ✫ ✟✩✟✟✟✟✯ ✬ ✻ ✪✫ KUNDE ✩ ❍❨ ❍✪ ❍ ✩❍ ❍✬ ✪✫ MANAGEMENT ✩ ✪ Abbildung 3.31: Vererbung und Datenkapselung: Verschiedene Sichten auf eine Datenstruktur Eine gewisse Ausnahme von der Regel, daß features einer Elternklasse für gewöhnlich übernommen werden, betrifft Initialisierungsprozeduren. Meist besitzen die Erben einer Klasse mehr Attribute als ihre Vorfahren und auch die Eigenschaften der geerbten features sind oft spezieller als die der Elternklasse 22 . Aus diesem Grunde müssen spezifische Initialisierungsprozeduren einer Nachkommenklasse oft völlig anders aussehen als die der Eltern. Man kann also nicht einfach die Initialisierungsprozedur der Elternklasse erneut zur Erzeugung von Objekten der Nachkommenklasse verwenden. Ist dies dennoch gewünscht, so muß diese Prozedur erneut über eine creation-Klausel als Initialisierungsprozedur der Nachkommenklasse deklariert werden. Ansonsten ist sie nicht mehr als eine gewöhnliche geerbte Routine, die bestehende Objekte ändert, nicht aber neue erzeugt. Vererbung ermöglicht es, Objekte einer Nachkommenklasse auch als Objekte der Vorfahrenklasse zu betrachten. Arbeitnehmer und Entleiher sind insbesondere auch Personen – man besitzt nur einige zusätzliche Informationen über Arbeitnehmer und Entleiher, die man von Personen nicht unbedingt erhalten kann. 22 So muß zum Beispiel ein Arbeitnehmer in Deutschland immer älter als 14 Jahre sein, während für Personen eine solche Einschränkung nicht sinnvoll ist.
- 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 94 und 95: Bei der Erzeugung von Objekten mitt
- 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 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
- Seite 145 und 146: Kapitel 4 Systematische Entwicklung
- Seite 147 und 148: 4.1.2 Grundideen des objektorientie
- Seite 149 und 150: jedoch dringend zu empfehlen, jegli
- Seite 151 und 152: • Ausleihe - Bücher werden nach
- Seite 153 und 154: Der Anwender ist kein echter Klient
- Seite 155 und 156: Es sei an dieser Stelle angemerkt,
- Seite 157 und 158: einen Rechner überprüft werden ka
- Seite 159 und 160: Definition 4.2.3 (Korrektheit von R
- Seite 161 und 162: Programmkonstruktion keine Rolle, d
- Seite 163 und 164: Eine Wertzuweisung entity := Ausdru
- Seite 165 und 166: 4.3.2.1 Die Rolle formaler Paramete
3.8.2 Export geerbter Features<br />
Normalerweise werden alle features einer Elternklasse unverän<strong>der</strong>t übernommen. Es gibt jedoch Gründe,<br />
Ausnahmen von dieser Regel zu vereinbaren. Manche Merkmale <strong>der</strong> Elternklasse PERSON machen im Zusammenhang<br />
mit <strong>der</strong> Verwaltung von Entleihern nur wenig Sinn: we<strong>der</strong> das Todesdatum noch die Nationalität<br />
sind von irgendeinem Interesse. Daher sollten diese features von <strong>der</strong> Klasse ENTLEIHER nicht wie<strong>der</strong> als Dienstleistungen<br />
bereitgestellt werden. Da sie nicht innerhalb <strong>der</strong> Klasse ENTLEIHER definiert, son<strong>der</strong>n geerbt<br />
wurden, kann man ihre Verbreitung auch nicht durch die Form <strong>der</strong> feature-Klausel kontrollieren, son<strong>der</strong>n<br />
benötigt eine explizite Export-Vereinbarung. In Eiffel wird dies durch Angabe einer export-Klausel innerhalb<br />
<strong>der</strong> Beschreibung <strong>der</strong> Vererbungseigenschaften ermöglicht.<br />
class ENTLEIHER<br />
inherit PERSON<br />
export<br />
name, vornamen, geburtsdatum<br />
end -- feature-Anpassung von PERSON<br />
feature<br />
straße, hausnummer, stadt: STRING;<br />
postleitzahl : INTEGER;<br />
ausweisnummer: INTEGER<br />
end -- class ENTLEIHER<br />
Abbildung 3.29: Klassendefinition mit Export geerbter features<br />
Die Angabe des Schlüsselwortes export besagt, daß die dahinter aufgezählten von PERSON geerbten features<br />
zusammen mit den neuen features als Dienstleistungen <strong>der</strong> Klasse ENTLEIHER bereitstehen. Die nicht genannten<br />
features todesjahr und nationalität sind nicht mehr benutzbar. Fehlt die export-Klausel, so sind alle<br />
von PERSON geerbten features erneut verfügbar. Das Schlüsselwort end beendet Modifikationen <strong>der</strong> geerbten<br />
features.<br />
Auch beim Export geerbter features kann es sinnvoll sein, die Weitergabe von Informationen von <strong>der</strong> Kundenklasse<br />
abhängig zu machen. So könnte es zum Beispiel sein, daß die Nationalität eines Arbeitnehmers –<br />
ebenfalls ein Spezialfall von Personen – für das Finanzamt aus steuerrechtlichen Gründen von Bedeutung ist,<br />
nicht aber für den Arbeitgeber. Aus diesem Grunde erlaubt Eiffel einen selektiven Export geerbter features.<br />
Die Syntax ist vergleichbar mit <strong>der</strong> in Abschnitt 3.4 angegebenen Form für feature-Klauseln:<br />
export<br />
{ Klassenliste1} featurelist1;<br />
.<br />
{ Klassenlisten} featurelistn<br />
Die Klasse ARBEITNEHMER in Abbildung 3.30 exportiert an die Klasse ARBEITGEBER – und an alle Erben dieser<br />
Klasse– die geerbten features name, vornamen, geburtsjahr sowie alle neu vereinbarten features 20 , an die<br />
Klasse FINANZAMT jedoch alle geerbten (und die neuen) features. Zur Vereinfachung <strong>der</strong> Schreibweise gibt es<br />
hierfür in Eiffel (Version 3) das Schlüsselwort all. Es besagt, daß alle features <strong>der</strong> Elternklasse an die in <strong>der</strong><br />
Klassenliste aufgezählten Klassen geliefert werden.<br />
Fehlt die export-Klausel, so bleibt ein geerbtes geheimes feature geheim und ein exportiertes features wird<br />
weiter exportiert. Dieses Verhalten kann jedoch in <strong>der</strong> export-Klauseln nach Belieben verän<strong>der</strong>t werden, da<br />
die Erben einer Klasse – im Gegensatz zu den Kunden – alle Rechte (und Pflichten) ihrer Ahnen besitzen und<br />
damit umgehen dürfen, wie sie es für richtig halten. Sie dürfen daher für ihre Kunden ein geheimes feature<br />
wie<strong>der</strong> exportieren bzw. ein exportiertes feature verstecken 21 .<br />
20Wir haben hier <strong>der</strong> Einfachheit halber die vier Komponenten straße, hausnummer, stadt, postleitzahl einer Adresse<br />
in einem Objekt zusammengefaßt.<br />
21Hier gibt es allerdings feine Grenzen, da sonst die Korrektheit des Gesamtsystems verletzt werden könnte.