Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Ein wichtiges Ziel jedes Objektmodells ist es, Objektautoren das Wiederverwenden und Erweitern von Objekten zu ermöglichen, die von anderen als Teile ihrer eigenen Implementierungen bereitgestellt werden. Eine Möglichkeit hierzu in Microsoft Visual C++ und anderen Sprachen ist die Verwendung von implementierungsvererbung, mit der ein Objekt einige seiner Funktionen von einem anderen Objekt erben kann, während andere Funktionen überschrieben werden.
Das Problem bei systemweiter Objektinteraktion mit herkömmlicher Implementierungsvererbung besteht darin, dass der Vertrag (die Schnittstelle) zwischen Objekten in einer Implementierungshierarchie nicht eindeutig definiert ist. Tatsächlich ist es implizit und mehrdeutig. Wenn das übergeordnete oder untergeordnete Objekt seine Implementierung ändert, kann das Verhalten verwandter Komponenten nicht definiert oder instabil implementiert werden. In jeder einzelnen Anwendung, bei der die Implementierung von einem einzelnen Entwicklungsteam verwaltet werden kann, das alle Komponenten gleichzeitig aktualisiert, ist dies nicht immer ein großes Anliegen. In einer Umgebung, in der die Komponenten eines Teams durch die Blackbox-Wiederverwendung anderer Komponenten erstellt werden, die von anderen Teams erstellt wurden, gefährdet diese Art von Instabilität die Wiederverwendung. Darüber hinaus funktioniert die Implementierungsvererbung in der Regel nur innerhalb von Prozessgrenzen. Dies macht traditionelle Implementierungsvererbung für große, sich entwickelnde Systeme, die aus Softwarekomponenten bestehen, die von vielen Entwicklungsteams erstellt wurden, unpraktisch.
Der Schlüssel zum Erstellen wiederverwendbarer Komponenten besteht darin, das Objekt als undurchsichtige Box zu behandeln. Dies bedeutet, dass der Codeabschnitt, der versucht, ein anderes Objekt wiederzuverwenden, nichts weiß und nichts über die interne Struktur oder Implementierung der verwendeten Komponente wissen muss. Anders ausgedrückt: Der Code, der versucht, eine Komponente wiederzuverwenden, hängt vom Verhalten des Objekts und nicht von der genauen Implementierung ab.
Um Black-Box-Wiederverwendbarkeit zu erreichen, übernimmt COM andere etablierte Wiederverwendungsmechanismen wie Eindämmung/Delegierung und Aggregation.
Hinweis
Aus Gründen der Einfachheit wird das wiederverwendete Objekt als inneres Objekt bezeichnet, und das Objekt, das dieses innere Objekt verwendet, ist das äußere Objekt.
Es ist wichtig, sich in beiden Mechanismen daran zu erinnern, wie das äußere Objekt für seine Clients erscheint. Was die Clients betrifft, implementieren beide Objekte alle Schnittstellen, auf die der Client einen Zeiger abrufen kann. Der Client behandelt das äußere Objekt als undurchsichtigen Kasten und kümmert sich daher weder um die interne Struktur des äußeren Objekts, noch ist das notwendig. Der Client interessiert sich nur für das Verhalten.
Weitere Informationen finden Sie in den folgenden Themen: