(Der Originalartikel wurde geschrieben von Edward V. Berard, Berard Software Engineering, Inc.,902 Wind River lane, Suite 203, Gaithersburg, Maryland 20878, USA. Übersetzt von Ulli Gellesch, STARBRIGHT Software)
Die Art, wie Menschen Technologie verstehen
Es gibt eine alte Geschichte darüber, wie eine Gruppe Blinder aufgefordert wurde herauszufinden, was ein Elefant sei. Man gab ihnen dazu eine lebendiges Exemplar und ließ sie beginnen. Jeder von Ihnen untersuchte einen anderen Körperteil des Elefanten. Einer der Blinden fiel gegen die Seite des Elefanten und erklärte, daß der Elefant Ähnlichkeiten mit einer Wand habe. Ein anderer, der das Ohr befühlte, meinte, daß ein Elefant viele Gemeinsamkeiten mit einem Blatt habe und derjenige, der den Schwanz des Elefanten untersuchte, kam zu dem Ergebnis, daß es sich um eine Art Seil handeln müsse. Ein weiterer Blinder, der das Bein des Elefanten berührte, war überzeugt davon, daß es sich um einen Baum handele und der nächste, der sich mit dem Rüssel beschäftigte, behauptete das ein Elefant viel Übereinstimmung mit einer Schlange hat.
Jeder der Blinden hat zwar ein wenig über das Wesen eines Elefanten herausgefunden, aber keiner von Ihnen hat je die Gesamtheit begriffen oder wirklich verstanden was denn nun ein Elefant ist. Man kann sich lebhaft vorstellen was es für eine Diskussion gegeben hat, als die Blinden ihr Wissen über den Elefanten untereinander austauschten -- jeder war sich darüber im klaren, daß der andere das Falsche herausgefunden hatte.
Oft geht es Menschen die Untersuchungen beliebiger Art durchführen, genau wie diesen Blinden in der Geschichte. Es kommt oft vor, daß sich diese Menschen auf eine Sache, einen Aspekt, des zu untersuchenden Objektes konzentrieren und dabei ganz offensichtlich andere wichtige Aspekte total übersehen. Eigentlich ist das nicht weiter schlimm - es sei denn, die Person behauptet das ganze sehr gut verstanden zu haben.
Um wirkliches Verständnis einer Technologie zu erreichen, bedarf es eines großen Aufwandes des Studiums dieser Technologie. Alleine die Menge an Informationen die es zu verarbeiten gilt ist überwältigend. Die Aufgabe wird noch schwieriger durch die unvermeidlichen Fehler die in den einzelnen Untersuchungen enthalten sind. Selbst wenn eine Person in der Lage ist eine große Menge an Material zu verarbeiten und zusätzlich noch die Fähigkeit besitzt Fehler sofort zu erkennen, so bleibt doch immer noch der Prozess der Analyse nach, die Schlußfolgerung aus dem was man in sich aufgenommen hat. Um Technologie wirklich zu verstehen muß man in der Lage sein zu unterscheiden zwischen den für diese Technologie wichtigen Dingen und den unwesentlichen.
Wie Menschen sich der objektorientierten Technologie nähern
Die Objektorientierte Technologie ist überaus mächtig und sehr weit reichend. End-User von Computersystemen und computerunterstützten Systemen spüren die Auswirkungen dieser Technik in Form von immer einfacher zu bedienender Software und Betriebssystemen, in immer flexibler werdenden Diensten der Banken, Telekommunikation und Kabelfernsehen. Für den Software Ingenieur ist diese Technologie verbunden mit objektorientierten Programmiersprachen, objektorientierten Entwicklungsmethoden, Verwaltung objektorientierter Projekte, objektorientierter Hardware und objektorientierter computerunterstützter Softwareentwicklung. Es ist daher nicht erstaunlich, das es deshalb einige Verwirrung gibt bezüglich objektorientierter Begriffe und Konzepte. In diesem Artikel werden wir dem Leser verständliche Definitionen für objektorientierte Begriffe und Konzepte geben die wichtig sind für das grundsätzliche Verständnis der objektorientierten Technologie.
Viele der Begriffe die in der objektorientierten Technologie gemeinhin verwendet werden, wurden am Anfang zur Beschreibung der Konzepte der objektorientierten Programmierung verwendet. Genauer gesagt, auch wenn diese Begriffe aus einer nicht computerorientierten Umgebung entliehen wurden, so wurden sie doch zuerst stark strapaziert zur Beschreibung der Konzepte, die in objektorientierten Programmiersprachen wie C++, Smalltalk und Eiffel enthalten sind. Wie auch immer, die Begriffe sind äußerst nützlich, auch wenn man nie vorhat Software zu schreiben.
Zum Beispiel könnte ein Industriedesigner ein Objektorientiertes Modell einer Plastikverformungsmaschine entwerfen. Die Formen, Plastikteile und sogar die „Rezepte" (proportionale Kombinationen) der Chemikalien die zur Erzeugung der verschiedenen Plastikmassen benötigt werden, können alle dargestellt werden mit objektorientierten Begriffen. Weiterhin können mittels objektorientierter Begriffe alle dynamischen und statischen Beziehungen zwischen verschiedenen Dingen beschrieben werden.
Letztendlich sollten sie sich darüber im klaren sein, daß es keinen ultimativen Satz von Definitionen für objektorientierte Begriffe und Konzepte gibt, noch jemals geben wird. Abhängig von ihrem Gesprächspartner wird es immer einige kleine Abweichungen in den Definitionen und Begriffen geben. Das ist aber ganz normal. In verschiedenen Teilen der USA wird derselbe Gegenstand z.B. eines Frühstücks mal Pfannkuchen, mal Runzelkuchen, mal umgedrehter Hans oder auch heißer Kuchen genannt. Ein Chemiker verwendet vielleicht den Begriff „Vorhang" und „oxidations Status" für ein und dasselbe Konzept.
Objektorientierte Begriffe und Konzepte
Objekte sind physikalische und konzeptuelle Dinge die wir in unserem Universum um uns herum finden. Hardware, Software, Dokumente, Menschen und sogar Konzepte sind alles Beispiele für Objekte. Zum Zweck der Modellierung ihres oder seines Unternehmens könnte ein Geschäftsführer/in Angestellte, Arbeiter, Gebäude, Abteilungen, Dokumente und soziale Arbeitnehmerzulagen als Objekte betrachten. Ein Automobilingenieur würde Reife, Türen, Motoren, Höchstgeschwindigkeit und aktueller Tankinhalt als Objekt sehen. Atome, Moleküle, Volumen und Temperaturen wären alles Objekte eines Chemikers unter der Annahme, daß er eine ojektorientierte Simulation einer chemischen Reaktion darstellen möchte. Letztendlich würde ein Softwareingenieur Stapel, Warteschlangen, Fenster und Kontrollkästchen als Objekte bezeichnen.
Objekte haben einen definierten Zustand. Der Zustand eines Objektes ist seine momentane Kondition oder es gibt einen Satz von Umständen die den Zustand eines Objektes beschreiben. Es ist nicht unüblich, daß man Leute über die „Zustandsinformation" in Zusammenhang mit einem bestimmten Objekt sprechen hört. Zum Beispiel wäre der Zustand eines Bankkontos sein aktueller Saldo, der Zustand eines Uhrenobjektes wäre die aktuell angezeigte Zeit, der Zustand einer elektrischen Glühbirne wäre „an" oder „aus". Für komplexe Objekte wie einen Menschen oder ein Automobil wäre eine komplette Zustandsbeschreibung sehr aufwendig. Wenn wir Objekte zur Modellierung der realen Welt oder für imaginäre Situationen benutzen, dann beschränken wir uns glücklicherweise nur auf die Zustände die für unser Modell relevant sind. Wir können uns auch den Zustand eines Objektes als etwas vorstellen das im inneren des Objektes enthalten ist (dem Objekt inhärent ist). Wenn wir zum Beispiel eine Nachricht in einen Briefkasten legen, dann ist der (interne) Zustand des Objektes Briefkasten verändert, im Gegensatz dazu ist der (interne) Zustand der Nachricht gleich geblieben.
Manchmal betrachten die Leute ein Objekt als streng statisch. Sie glauben, das sich der Zustand eines Objektes nur dann ändert, wenn von außen eine Anforderung zur Zustandsänderung gemacht wird. In der Tat sind viele Objekte passiv (statisch). Eine Namensliste würde sich selbst nicht spontan einen weiteren Namen zufügen oder einen von sich aus löschen.
Es ist aber für einige Objekte doch möglich, daß sie ihren eigenen Zustand ändern. Wir beziehen uns auf diese Objekte als „lebende Objekte" (lebende Objekte werden oftmals auch „aktive Objekte" oder auch „actors" genannt). Uhren und Timer sind übliche Beispiele für lebende Objekte. Wenn wir Geschäftsprozesse modellieren, dann müssen wir uns darüber im klaren sein, daß Verkäufer und Kunden ebenso lebende Objekte sind.
Klassen, Metaklassen, parametrisierte Klassen und Exemplare
Es gibt weite Kategorien von Objekten: Klassen und Instanzen. Benutzer der objektorientierten Technologie stellen sich oft unter Klassen vor, daß sie die Informationen enthalten die notwendig sind um Instanzen zu erzeugen oder um es anders zu sagen, die Struktur und Möglichkeiten einer Instanz werden bestimmt durch die zugehörige Klasse. Es gibt drei, oft benutzte (und verschiedene), Sichten zur Definition von „Klasse":
Wahrscheinlich sind die beiden meist vereiteten Sichten die „Sicht als Instanzenfabrik" und die „Sicht als cookie cutter".
Es sei hier bemerkt, das es möglich ist, das die Instanz einer Klasse als neue Klasse fungieren kann. Eine Metaklasse ist also eine Klasse deren Instanzen ebenfalls Klassen sind. Wenn wir den Mechanismus zur Erzeugung einer Metaklasse benutzen, dann sind die Instanzen die wir erzeugen ebenfalls Klassen. Der Mechanismus dieser neuen Klasse kann natürlich auch wiederum zum erzeugen von Instanzen verwendet werden. Die erzeugten Instanzen können, müssen aber nicht, wiederum Klassen sein
Ein Konzept das sehr ähnlich zu dem der Metaklasse ist, ist das der parametrisierten Klasse. Eine parametrisierte Klasse ist ein Modell für eine Klasse, in der spezifische Eigenschaften der Klasse zum Erzeugungszeitpunkt zwingend notwendig spezifiziert werden müssen, damit Klassen, die auf diesem Modell beruhen, erzeugt werden können. Eine parametrisierte Klasse kann man auch betrachten als „noch auszufüllen" Version einer Klasse. Den Mechanismus zur Erzeugung von Instanzen einer parametrisierten Klasse kann man also ohne sinnvollen Parameter nicht direkt verwenden. Wir müssen also erst die erforderlichen Parameter zur Verfügung stellen, bevor der Mechanismus eine nicht-parametrisierte Klasse erstellt. Wenn wir dann eine nicht-parametrisierte Klasse haben, dann können wir deren Erzeugungsmechanismus verwenden um Instanzen von dieser Klasse zu kreieren.
Im allgemeinen werde ich den Begriff „Klasse" für alle Arten von Klassen verwenden, also Metaklasse, parametrisierte Klasse und Klassen die weder Metaklassen noch parametrisierte Klassen sind. Ich werde nur dann eine Unterscheidung machen, wenn das im Kontext notwendig ist. Gelegentlich werde ich mich auch auf „nicht-Klassen-Instanzen" beziehen. Eine nicht-Klassen-Instanz ist die Instanz einer Klasse, kann selbst aber keine Klasse sein. Die Instanz einer Metaklasse kann selbst nie eine nicht-Klassen-Instanz sein.
Objektorientierte Personen benutzen machmal das Wort „Instantiation". Instantiation hat zwei Bedeutungen:
Einige Leute verwenden den Begriff „Objekt" ganz strikt nur auf Instanzen von Klassen. Wenn diese Leute konfrontiert werden mit dem Konzept von Metaklassen und parametrisierten Klassen, dann haben sie arge Schwierigkeiten, die Probleme, die sich aus der Einführung dieser Konzepte ergeben, aufzulösen. Die Frage ist zum Beispiel ob eine Klasse die aus einer Metaklasse instanziiert wurde ein Objekt ist -- auch wenn sie selbst eine Klasse ist? Ich benutze also den Begriff „Objekt" um mich auf beides zu beziehen, Klassen und ihre Instanzen. Wir werden zwischen den beiden nur dann unterscheiden, wenn es notwendig ist.
Black Boxes und Schnittstellen
Objekte sind „Black Boxen". Insbesondere die den Objekten zugrunde liegenden Implementationen sind vor denen, die die Objekte benutzen, versteckt. In objektorientierten Systemen ist der Produzent (Erzeuger, Designer, Erbauer) eines Objektes der einzige, der die Details der internen Konstruktion kennt. Den Konsumenten (Benutzern) der Objekte ist die Kenntnis der internen Funktionen untersagt und sie müssen ihre Kommunikation mit dem Objekt über eine der drei unterschiedlichen Schnittstellen abwickeln:
Eine andere Art darauf hinzuweisen, daß eine Eigenschaft in der Schnittstelle eines Objektes enthalten ist, ist zu sagen, daß das Objekt diese Eigenschaft „exportiert". Ähnlich ist es, wenn ein Objekt informationen von außen bedarf, (z.B. als Parameter in einer parametrisierten Klasse) dann können wir sagen, daß das Objekt die Informationen „importieren" muß.
Aggregation
Natürlich ist es möglich, das ein Objekt aus anderen Objekten zusammenmgesetzt ist. Aggregation ist entweder:
Zum Beispiel könnte ein Datumobjekt zusammengesetzt sein aus einem Monatobjekt und einem Tagobjekt und einem Jahrobjekt. Ein Namenlisteobjekt kann man sich vorstellen als viele Namenobjekte.
Ein monolithisches Objekt ist ein Objekt, daß keine nach außen erkennbare Struktur hat. Mit anderen Worten, ein monolithisches Objekt ist nicht zusammengesetzt aus zwei oder mehreren anderen Objekten. Spezifischer ausgedrückt ist ein monolithisches Objekt ein zusammenhängendes Ganzes. Das Äußere eines monolithischen Objektes kann nicht direkt interagieren mit irgendwelchen (egal ob real oder imaginär) Objekten im Inneren des monolithischen Objektes. Ein Optionsfeld ( radio button) in einer grafischen Benutzerschnittstelle (GUI) ist ein Beispiel für ein monolithisches Objekt.
Zusammengesetzte Objekt sind nach außen erkennbare Strukturen und die Struktur kann angesprochen werden über die öffentlich zugänglich Schnittstelle des zusammengesetzten Objektes. Die Objekte, aus denen ein zuammengesetztes Objekt besteht, werden Komponentenobjekte genannt. Zusammengesetzte Objekte erfüllen eine oder zwei der nachfolgenden Kriterien:
Es ist sinnvoll zusammengesetzte Objekte in zwei Unterkategorien zu unterscheiden:
Heterogene zusammengesetzte Objekte und Homogene zusammengesetzte Objekte
Die Regeln für den Entwurf von heterogenen zusammengesetzten Objekten unterscheiden sich von den Regeln für den Entwurf von homogen zusammengesetzte Objekten.
Spezialisierung und Vererbung
Aggregation ist nicht die einzige Art mit der zwei Objekte miteinander in Beziehung gebracht werden können. Ein Objekt kan die Spezialisierung eines anderen Objektes sein. Spezialisierung ist entweder:
Spezialisierung ist normalerweise in Zusammenhang mit Klassen zu sehen. Es ist meistens in den sogenannten „klassenlosen" objektorientierten Systemen wo von spezialisierten Objekten gesprochen wird anstatt von Klassen.
Abhängig von ihrem technischen Hintergrund, gibt es eine Menge von verschiedenen Arten wie Personen Spezialisierung ausdrücken. So beziehen sich diejenigen, die Erfahrung mit objektorientierten Programmiersprachen wie Smalltalk haben auf „Subklassen" und bezeichnen die zugehörigen Klassen in denen die Spezialisierung generalisiert wurde als „Superklasse". Diejenigen mit einem Hintergrund in C++ sprechen von abgeleiteten Klassen und Basisklassen.
Es ist allgemein üblich zu sagen, daß alles was für die Generalisierte Klasse gilt, auch für die Spezialisierte der Fall ist. Wir können zum Beispiel Sparkonten und Girokonten als Spezialisierung von Bankkonten definieren. Anders ausgedrückt können wir aber auch sagen, daß ein Girokonto eine Art Bankkonto als auch ein Sparkonto ist. Nochmals anders ausgedrück können wir auch sagen, daß alles was für ein Bankkonto gilt genauso gilt für ein Sparkonto als auch für ein Girokonto.
In einem objektorientierten Kontext sprechen wir bei der Spezialisierung auch von „Vererbung" der Characteristika der zugehörigen generalisierten Klasse. Vererbung kann definiert werden als der Prozess bei dem ein Objekt die charakteristischen Eigenschaften erhält (bekommt, erwirbt) von einem oder mehreren Objekten.
Einige objektorientierte Systeme erlauben nur einzelne Vererbung. Das ist meistens der Fall, bei der eine Spezialisierung nur von einer einzigen Klasse gebraucht wird. Viele der objektorientierten Systeme erlauben aber multiple Vererbung, daß heißt das Spezialisierung von zwei oder mehreren generalisierten Klassen möglich ist.
Unser vorheriges Beispiel der Spezialisierung des Bankkontos ist eine einfache Vererbung. Ein Teleskop und ein Fernsehgerät sind beides spezialisierte Geräte die es einem ermöglichen „Dinge zu sehen die weit entfernt sind". Ein Fernsehgerät ist aber auch ein elektronisches Gerät. Man kann also sagen, daß ein Fernsehgerät die Charakteristika von zwei generalisierten Klassen erwirbt, nämlich von der Klasse der Geräte die es einem erlaubt Dinge zu sehen die weit entfernt sind und von der Klasse der elektronischen Geräte. Deshalb ist ein Fernsehgerät ein Produkt multipler Vererbung.
Abstrakte Klassen
Normalerweise gehen wir von vollständig definierten Klassen aus. Es gibt aber Situationen, in denen unvollständig definierte Klassen sinnvoll sind. Zum Beispiel reden wir in unserer täglichen Konversation eventuell über Bankkonten, Versicherungspolicen und Häuser. In objektorientierter Denkweise isolieren wir solch nützliche, aber unvollständigen Konzepte wie diese in eigene Spezialklassen.
Abstrakte Klassen sind Klassen, die das Prinzip von logischem Zusammenhalt und innerer Bindung auch auf unvollständige Konzepte ermöglichen, andererseits machen sie diese Spezialisierung nutzbar durch Vererbung. Für abstrakte Klassen findet man manchmal auch den Begriff „partieller Typ" oder „abstarakte Superklasse". Man würde niemals eine Instanz einer abstrakten Klase erzeugen, aber man würde diese speziellen Eigenschaften für eine weiter spezialisierte Klasse nutzen.
Nehmen wir mal das Beispiel eines Automobils. Auf der einen Seite wissen die meisten Menschen was ein Automobil ist. Auf der anderen Seite ist der Begriff „Automobil" aber eine unvollständige Beschreibung eines Fahrzeuges. Es würde wesentlich mehr Sinn machen ein „Automobil" mit der Menge der Eigenschaften zu beschreiben die ein Automobil wirklich ausmachen. Mit anderen Worten der „Essenz von Automobilität".
Operationen
Die öffentliche Schnittstelle eines Objektes enthält typischerweise drei verschieden Kategorien von Dingen wie:
Eine Operation der öfftenlichen Schnittstelle eines Objektes gibt nach außen die funktionellen Möglichkeiten eines Objektes bekannt. So ist zum Beispiel „einzahlen" eine Operation der öffentlichen Schnittstelle eines Bankkontos, „wie hoch ist die aktuelle Temperatur" wäre eine Operation der öffentlichen Schnittstelle eines Temperatursensors und „inkrementieren" wäre eine Operation der öffentlichen Schnittstelle eines Zählers.
Den tatsächlichen Algorithmus, der zur Durchführung der Operation benötigt wird, bezeichnet man als Methode. Im Unterschied zu Operationen, sind Methoden nicht in der öffentlichen Schnittstelle eines Objektes enthalten. Methoden sind im inneren eines Objektes versteckt. Benutzer eines Bankkontos wissen zwar, daß sie die Operation einer „Einzahlung" durchführen können, aber sie kennen nicht die ganzen Details die erfolgen, bis die Einzahlung ihrem Konto gutgeschrieben wurde.
Die Operationen der öffentlichen Schnittstelle eines Objektes bezeichnen wir auch als „erlaubte Operationen". Erlaubte Operationen sind Operationen, die zwei Kriterien erfüllen; es sind zum einen Dinge die mit einem Objekt gemacht werden dürfen und sie sind in der öffentlichen Schnittstelle des Objektes bekannt. Zum Beispiel können wir sagen, daß ein Bankkonto die Operation des Einzahlens „erlaubt". Ein Bankkonto könnte auch die Abfrage nach dem aktuellen Kontostand „erlauben". Manchmal wird die erlaubte Operation aúch als „exportierte Operation" bezeichnet.
Manchmal brauchen Objekte Unterstzützung für ihre charakteristischen Eigenschaften. Nehmen wir mal an, wir wollen ein Objekt „generisch geordnete Liste" erstellen. Eine geordnete Liste ist eine Liste, die ihren Inhalt sortiert darstellt, z.B. von Klein nach Groß. Immer wenn wir der Liste etwas neues zufügen, dann muß dieses Neue an der richtigen Position in Bezug auf die bereits vorhandenen Dinge einsortiert werden. Mit „generisch" meinen wir ein Modell, daß immer instanziiert werden kann mit einer Kategorie (z.B. einer Klasse) von Dingen die wir in einer geordneten Klasse haben möchten.
Es wäre nicht Grundlos, wenn wir so ein Objekt als parametrisierte Klasse implementieren würden. Offensichtlich wäre dann einer der Parameter die Kategorie der Dinge (z.B. Klasse), die wir in die Liste einfügen möchten. Zum Beispiel könnte die Instanziierung (erzeugen einer Instanz) einer generisch geordneten Liste mit dem Parameter „Klassenname" zur Erzeugung einer geordneten Liste von Klassennamen führen.
Es gibt da aber noch ein Problem. Unter der Annahme, daß wir in der Lage sind eine generisch geordnete Liste für jede beliebige Kategorie von Dingen zu instanziieren, bleibt immer noch die Frage, wie wir sicher stellen können, daß unsere geordnete Liste auch weiß, wie sie sortieren soll -- egal wofür wir unser Liste instanziieren? Nehmen wir mal an wir wollten eine geordnete Liste von „Fazomas" haben. Wie könnten wir dann feststellen, daß ein Fazoma größer oder kleiner als ein anderer ist?
Eine Lösung des Problems wäre einen zweiten Parameter zu fordern, z.B. einen Parameter der etwas über die Kategorie der Dinge (Klasse) aussagt die wir in der Liste ordnen wollen. Der zweite Parameter wäre eine „<" (kleiner als) Operation die mit der Kategorie Dinge funktioniert die in der Liste plaziert werden. Im Fall unser Fozomas wäre das eine „<„ Funktion die Fazomas richtig einordnet.
Die „kleiner als" Funktion die mit Fozomas arbeitet, ist ein Beispiel für eine erforderliche Operation. Eine erforderliche Operation ist eine Operation, die das Objekt braucht um seine nach außen sichbaren, charakteristischen Eigenschaften, zur Verfügung stellen zu können, die es selbst aber nicht besitzt. Sie werden auch oft als „importierte Operation" bezeichnet.
Es gibt drei große Kategorien von erlaubten Operationen:
Weiterhin kann man Iteratoren nochmal in zwei Kategorien unterteilen: Aktive (offene) Iteratoren und passive (geschlossene). Aktive Iteratoren sind Objekte die aus sich selbst den Iterationsmechanismus zur Verfügung stellen. Passive Iteratoren sind implementiert als Schnittstellen, über die die Iteration ermöglicht wird. Die passiven Iteratoren sind dann nochmal unterteilt in selektive und konstruktive Iteratoren. Passive selektive Iteratoren gestatten dem Benutzer keine Änderung des Objektes auf dem die Ietration ausgeführt wird, während passive konstruktive Ietratoren dies zulassen.
Erlaubte Operationen können wir auch noch beschreiben als primitive und zusammengesetzte Operationen. Eine primitive Operation ist eine Operation die nicht einfach,effizient und zuverlässig ausgeführt werden kann, ohne Kenntnis der drunterliegenden (versteckten) Implementation. Als Beispiel könnte man sagen, daß die Operation des zufügens oder löschens eines Listenelementes eine primitive Operation ist in Bezug auf das Listenobjekt.
Wenn man zum Beispiel eine Swap Operation erstellen möchte um zum Beispiel in einer Liste ein Element einzufügen und ein anderes gleichzeitig zu entfernen (also ein Austausch), dann ist dies keine primitive Operation mehr, da wir die einfügen und lösch Operationen verwenden. Eine zusammengesetzte Operation besteht also aus zwei oder mehreren primitiven Operationen.
Konstanten
Zusätzlich zu den erlaubten Operationen kann eine öffentliche Schnittstelle Konstanten haben. Konstanten sind Objekte die einen konstanten Status haben. Stellen sie sich vor, daß sie eine „Klasse begrenzter Adresslisten" erstellen wollen. Eine begrenzte Liste ist eine Liste die festgelegte Anzahl von Elementen hat. Eine begrenzte Liste kann leer sein (keine Eelemente), sie kann weniger Elemente als das festgelegte Maximum haben oder gleich diesem Maximum sein. Sie kann aber niemals mehr Elemente als die festgelegte Anzahl haben.
Nehmen wir mal an, daß wir eine Konstante in die öffentliche Schnittstelle unserer begrenzten Adressliste tun, dann repräsentiert diese Konstante die Anzahl der Elemente die unsere Liste enthalten kann. Nehmen wir weiterhin an, das wir eine erlaubte Operation haben, die uns den Wert der aktuellen Anzahl der Elemente zurückgibt (in diesem Fall Adressen) die unsere Liste gerade enthält. Wir sind dann in der Lage zu berechnen wieviel Platz wir noch in unserer Liste haben, indem wir die aktuelle Anzahl der Elemente von der Konstanten abziehen.
In vielen Fällen, wie den vorher beschriebenen, dient die Konstante der Einfachheit mehr, als der Notwendigkeit. In anderen Fällen, z.B. bei Verschlüsselungsalgorithmen, brauchen wir einen Startwert und dann ist unsere Konstante zwingend Notwendig.
Sonderfallbehandlung
Eine dritte Kategorie von Dingen in der öffentlichen Schnittstelle ist die Sonderfallbehandlung. Sonderfallbehandlungen haben zwei verschiedene Definitionen:
Sonderfallbehandlung kann man in gewisser Weise im Zusammenhang mit einer älteren, nicht so sicheren Technologie sehen: „den Fehlercodes". Die Idee hinter den Fehlercodes war ziemlich einfach. Sie forderten von einer Anwendung, oder einer Teilanwendung, das sie eine Aufgabe erfüllt respektive eine Tätigkeit verrichtet. Ein Teil der Informationen die die Anwendung dann zurückzugeben hatte, war der Fehlercode. Wenn alles normal verlaufen war, dann hatte der Fehlercode im Allgemeinen den Wert Null, anderfalls hatter er einen von Null abweichenden Wert. Es war also ganz normal die verschieden von Null abweichenden Werte mit einem speziellen Fehler in Verbindung zu bringen.
Fehlercodes litten aber unter zwei grundsätzlichen Problemen:
Die Sonderfallbehandlung adressiert direkt diese beiden Probleme. Um dies zu verstehen, müssen wir verstehen wie die Sonderfallbehandlung typischer Art und Weise funktioniert:
Beispiele solcher Ausnahmefälle können sein: der Versuch einen leeren Behälter zu leeren, einen Aufzug der im obersten möglich Stockwerk steht höher zu schicken und der Versuch einem Datum einen eindeutig verkehrten Wert zuzweisen, wie z.B. 31.2.????
Im Gegensatz zu Fehlercodes, kann die Ausnahmefallbehandlung nicht ignoriert werden. Sobald die Ausnahmefallbehandlung aktiviert worden ist, hat sie die Kontrolle. In Objektorientierten Systemen wird die Ausnahmefallbehandlung zusätzlich in die öffentliche Schnittstelle integriert. Änderungen der öffentlichen Schnittstelle eines Objektes haben meistens zur Folge, daß alle abhängigen Objekte und Dinge überprüft werden. Dadurch erfolgt eine teilweise automatische Weitergabe der neuen Bedingungen.
Kopplung und innere Bindung von Objekten
Ingenieure wissen schon seit Jahrzehnten, daß je weniger ein Teil eines Systems vom anderen Teil abhängig ist, umso stabiler ist das Gesamtsystem. Systeme, deren Komponenten stark unabhängig sind, sind einfacher zu reparieren, zu warten und zu erweitern als solche die starke interdependenzen haben. Hochgradig unabhängige Komponenten sind nur möglich wenn es eine minimale Kopplung zwischen den einzelnen gibt und diese wiederum eine starke innere Bindung haben.
Die Kopplung ist ein Maß der Stärke der Verbindung zweier Komponenten in einem System. Je mehr zwei Komponenten voneinander wissen, umso enger (schlechter) ist die Kopplung. Die innere Bindung sagt etwas darüber aus, wie stark die einzelnen Teile innerhalb einer Komponente logisch zueinander in Beziehung stehen. Je größer die logischen Beziehungen innerhalb einer Komponente sind, umso größer (besser) ist deren innere Bindung.
Die Objekte aus denen ein Objektorientiertes System besteht, zeigen diese Objektkopplung und Objektbindung. Objektkopplung zeigt den Grad der Beziehung der einzelnen Objekte zueinander. Je mehr ein Objekt über irgendein anderes Objekt im System weiß, umso größer (schlechter) ist die Kopplung.
Zur Erzeugung eines Systems von Objekten, müssen wir diese sinnvoll miteinander Koppeln. Dies ist notwendige Kopplung und wird z.B. durchgeführt auf einer Applikation für Applikation Basis. Wenn aber im Entwurf eines einzelnen Objektes, dieses spezielle Kenntnisse über ein anderes Objekt erhält, dann ist dies unnötige Kopplung. Unnötige Kopplung reduziert die Wiederverwendbarkeit von Objekten und verringert die Funktionsstabilität des Systems.
Objektbindung gibt Auskunft über die logischen Beziehungen der einzelnen Komponenten zueinander aus einer Übergeordneten Sicht. Wenn uns z.B. gesagt wird, da´ein Datumobjekt aus einem Tagobjekt, einem Monatobjekt, einem Jahrobjekt der Farbe Blau besteht, dann sollte uns sofort auffalen, daß die Farbe Blau hier nicht hingehört und das dies die inner Bindung schwächt. Aus zwei Gründen sollte unser Ziel sein unsere Objekte so kohäsiv wie möglich zu machen. Erstens können Objekte mit schwacher Bindung wesentlich einfacher ungewollt geändert werden und haben deshalb wesentlich schneller unerwünschte Seiteneffekte. Zweitens sind Objekte mit geringer Bindung selten leicht wiederverwendbar.
Objektsysteme
Bei der Entwicklung von Objektorientierten Modellen und objektorientierten Anwendungen finden wir sehr schnell heraus, das Einzelklassen und Einzelinstanzen nicht ausreichend ist. Man braucht eine Möglichkeit der Handhabung großer Objekte, das heißt Objektsystemen. Ein Objektsystem ist definiert als zwei oder mehr Objekte die interagieren, zueinander in Beziehung sind, aber nicht ineinander Verschachtelt sind. (Einfache Zusammensetzungen entsprechend unserer Definition der Aggregation sind hier ausgeschlossen)
Objektsysteme fallen in zwei generelle Kategorien:
Solche Sammlungen von Objekten entsprechen einer Bibliothek. Nehmen wir mal, wir wollen z.B. eine Applikation mit einer grafischen Benutzeroberfläche entwickeln. Für grafische Benutzeroberflächen brauchen wir einige verschiedene Arten von Fenster. Es wäre dann sinnvoll, wenn wir eine Bibliothek mit verschiedenen Fenstern und Fensterkomponenten hätten mit denen wir dann unsere gewünschten Fenster erzeugen könnten. Fenster sind Objekte und die Komponenten eines Fenster (Knöpfe, Kontrollkästchen etc) sind wiederum Objekte. Eine Ansammlung von Fenstern und Fensterkomponenten kann als Werzeugkasten betrachtet werden.
Andererseits entsprechen Systeme von interagierenden Objekten Applikationen. Wenn wir z.B. eine objektorientiete Anwendung entwerfen wollten, die einen Aufzug in einem Gebäude steuert, dann würden wir den Aufzugkorb, die Knöpfe, Lampen, Schaltereinheiten und all die anderen Objekte in einen funktionierenden Zusammenhang (d.h. Applikation) bringen. Solch eine Applikation würden wir nicht als eine Bibliothek betrachten, sondern als ein in sich stark zusammengehöriges Ganzes. So ein Fahrstuhlkontrollsystem ist ein System interagierender Objekte.