4.         Gekapselte Objektgeflechte

4.1.            Bestandteile    

 Eine Software bzw. ein Programm besteht aus mehreren Komponenten. Diese Komponenten können durch mehrere Objekte (à Objektgeflechte) realisiert werden. In Abbildung 4.1.1. wurde ein Queue als Objektgeflecht dargestellt. Eine Queue ist eine Datenstruktur zur Speicherung von Objekten nach dem fifo-Prinzip (first in, first out). Die einzelnen Knoten (Objektträger , Node) halten Referenzen auf Objekte. Die einzelnen Knoten sind untereinander vom ersten Knoten (head) bis zum letzten Knoten miteinander verkettet. Die letzte Verknüpfung ist null und zeigt somit das Ende der Queue an. Mit der Operation push(Object o) wird ein neuer Knoten am Ende angeknüpft, der das übergebene Objekt hält. Bei der pop()-Methode wird das erste Element entfernt und zurückgegeben. Der QueueIterator erlaubt es, durch die Datenstruktur durchzulaufen, ohne dabei ein Element zu entfernen und anschließend wieder einfügen zu müssen. Eine Komponente besteht aus nachfolgenden Bestandteilen und ihre Planung ist relevant bezüglich Kapselung und Vererbung:

 Komponentenschnittstellen:

 Komponentenschnittstellen sind Elemente einer Komponente, die einen Zugriff von außen auf das Innere einer Komponente bzw. eines Objektgeflechts zulassen. In diesem Fall stellen die Klassen Queue und QueueIterator Komponentenschnittstellen dar, die es erlauben mit den Methoden next() und pop() auf die Elemente (Nodes) zuzugreifen. Die vollständige Kapselung einer Schnittstelle ist folglich nicht sinnvoll.

Argumentobjekte:

 Alle Objekte außerhalb der Komponente, die von innerhalb der Komponente referenziert werden, heißen Argumentobjekte (argument objects). Von diesen Objekten wird gefordert, dass sie die Funktionsfähigkeit der Komponente nicht einschränken bzw. beeinflussen können. Das bedeutet, in dem Beispiel der Queue, dass diese Objekte, außer dass sie in einem Knoten gespeichert werden, nichts mit der Queue gemein haben. Es wird Argumentunabhängigkeit verlangt (no argument dependence).

 Repräsentation:

 Wie der Name bereits Auskunft gibt, sind alle Elemente die die Komponente darstellen Teil der Repräsentation. Alle geschützten Attribute und Methoden der Klassen Queue und QueueIterator, insbesondere alle Nodes (halten die Daten/Objekte) bilden die Repräsentation. Jedoch gehören die Daten (argument objects) die in den Nodes gespeichert sind nicht zur Repräsentation, da sie den Zustand einer Komponente, wie oben gefordert, nicht verändern, bzw. beeinflussen. Repräsentationen sind die Objekte, die nicht zur Schnittstelle gehören. Eine Repräsentation darf mehr enthalten, sollte aber im Idealfall auf das Notwendigste beschränkt werden.

4.2.            Kapselung der Repräsentation

 Die Repräsentation muss alle Attribute und Methoden enthalten, von denen das korrekte Verhalten der Komponente abhängt und wie bereits gesagt, nicht von außen zugreifbar sein. Da die Repräsentation alle wichtigen Elemente der Komponente enthält, ist es wichtig, folgende Regeln zu beachten:

-                     Saubere Kapselung soll einen fehlerhaften Zugriff von außen Verhindern.

-                     Änderungen an der Repräsentation, darf sich nicht auf die Funktionsweise der Schnittstelle (letztendlich auf den Benutzer) auswirken.

-                     Mit alias protection unterbindet man direkte Referenzen auf Objekte der Repräsentation, um u.a. keine Änderungen der Repräsentation zu ermöglichen. Solche direkten Referenzen nennt man schützenswerte Referenzen.

 Verletzung obiger Regeln / Vorgaben kann dazu führen, insbesondere bei schützenswerten Referenzen, wie im Beispiel von Abschnitt 3.5, dass ein falsches Ergebnis zurückgegeben oder die Komponente inkonsistent wird. Eine Zugriffseinschränkung bzw. -schutz ist unumgänglich.

4.3.            Realisierung gekapselter Komponenten

Der Abschnitt zuvor hat bereits geklärt, dass der Zugriff auf die Attribute der Repräsentation und der Komponentenschnittstelle beschränkt werden muss. Am Beispiel der Queue wurden z. B. das Attribut head der Queue und das Attribut next des Iterators geschützt deklariert, damit ein Benutzer die Struktur nicht zerstören kann. Soweit möglich sollten Objekte, die außerhalb der Komponenten erzeugt wurden nicht in die Repräsentation eingebaut werden. In der Queue wurde deshalb die Node-Klasse als innere Klasse konzipiert. Wenn es möglich ist, sollten auch keine Referenzen auf Objekte der Repräsentation zurückgegeben werden, d.h. außerhalb der Komponenten, da man durch die Referenz direkten Zugriff auf ein Objekt der Repräsentation erhält. Falls ein Objekt der Repräsentation herausgegeben bzw. eingebaut wird, sollte man dazu eine Kopie verwenden, da auf diese Kopie keine Referenzen verweisen, die einen externen Zugriff ermöglichen. Um externen Zugriff zu vermeiden besteht weiterhin die Möglichkeit Daten zu kodieren, d.h. ihnen einen Identifikator zu geben, der beispielsweise einen int-Wert (Sorten sind referenzfrei) übergibt, so dass man Java-Referenzen umgehen kann, aber in der eigenen Datenstruktur ein bestimmtes Element wiederfindet, bzw. es durch die übergebenen Daten intern neu erstellt.

Komponenten werden erstellt damit sie später wiederverwendet werden, sprich andere Klassen werden früher oder später von einer Komponente erben. Es ist festzustellen, dass Vererbung und Subtyping in einem Spannungsverhältnis zueinander stehen. Verwendet man zu häufig private Zugriffsmodi, so schränkt man die Spezialisierungsmöglichkeiten der erbenden Klasse ein und erschwert folglich die Wiederverwendbarkeit, allerdings bleibt der Typ und die Invariante der erbenden Klasse erhalten. Der Gebrauch der öffentlichen und geschützten Zugriffmodi lassen dem Benutzer alle Freiheit die er braucht, führt aber unkontrolliert und undokumentiert zu einem Aufweichen der Kapselung (Offenlegen schützenswerter Referenzen) und somit zu einem sehr wahrscheinlichen fehlerhaften Verhalten der Komponente.