Die „Composite Components“ (CoCo) sind ein Architekturmuster, welches die Designprinzipien in der Softwareentwicklung „auf die Spitze treibt“ und sich für eine Neuentwicklung eines bestehenden Softwareprojekts, sowie für die schrittweise Softwarequalitätssteigerung eignet. Im Folgenden beschreibe ich zunächst die Herkunft des Musters „CoCo“ und gebe erste Einblicke in die beteiligten Komponenten. Außerdem „definiere“ ich einige Begriffe, die in späteren Artikeln wichtig werden. Später sollen die Prinzipien des Musters anhand von einigen Beispielen in der Programmiersprache C++ gezeigt werden, aber zunächst erst einmal zu der Herkunft des Architekturmusters Composite Components.

Herkunft der Composite Components

Das erste mal auf das Architekturmuster Composite Components bin ich bei einer Schulung zum Thema Softwarearchitektur/Design gestoßen. David Tielke, ein von Microsoft zertifizierter Trainer, gab für mich interessante Einblicke in seine Sichtweise auf die „gute“ Entwicklung von Softwareprojekten unter Berücksichtigung gängiger Designprinzipien wie z.B. KISS (Keep it simple, stupid), DRY (Don’t repeat yourself), Dependency Injection und Strong Cohesion – Loose Coupling. Diese Designprinzipien hat er laut eigener Aussage versucht auf den Entwurf einer Softwarearchitektur zu übertragen und das Muster der „Composite Components“ ist dabei herausgekommen. Diese Schulung liegt mittlerweile schon einige Jahre in der Vergangenheit, ich zehre allerdings bis heute davon und habe dieses Muster schon in einigen produktiven Softwareprojekten zum Einsatz gebracht. Es hat sich bewährt.

Die CoCos möchte ich in den nächsten Abschnitten und in regelmäßigen Abständen in einer Artikelserie erläutern und auch einige Beispiele in c++17 geben. Diese Beispiele sollen einen Eindruck vermitteln, wie dieses Muster in der Softwareentwicklung angewendet werden kann und haben nicht die Anspruch an Vollständigkeit.

Begriffserklärung

Der Name Composite Components (deutsch: zusammengesetzte Komponenten) beschreibt das Vorgehen dieses Architektur-Musters sehr treffend, denn es basiert darauf, dass einzelne Komponenten autark existieren können und an einem, von Herrn David Tielke scherzhaft als „Fuck-Up“-Point betitelten, zentralen Punkt zusammengesetzt werden. Der Client, also eine Software-Bibliothek oder ein ausführbares Programm etc. kennt nur den Kontrakt (Contract) der verwendeten Komponente und steht mit dem „Fuck-Up“-Point in Beziehung. Die eigentliche Implementierung der Komponente ist für den Client völlig unbekannt.

Als Kontrakt wird der Teil einer Komponente genannt, der die öffentliche Schnittstelle der Komponente definiert. Dazu gehören unter anderem Datenklassen (Dataclasses) und Klassenschnittstellen (Interfaces). Diese Teilkomponente schließt quasi einen Vertrag mit dem Client ab und beschreibt, wie die Komponente zu verwenden ist, ohne Details über ihre Implementierung zu verraten.

Diese Sätze oder Begriffe hat so ähnlich wahrscheinlich jeder Software-Entwickler schon einmal gehört, die Anwendung dieser Designprinzipien kann in der Praxis allerdings meist sehr komplex sein. Das Architekturmuster Composite Components, kann bei richtigem Einsatz, dazu beitragen, die Komplexität von Softwarekomponenten auf ein minimales Maß zu reduzieren, ohne auf Flexibilität verzichten zu müssen bzw. es schafft zusätzliche Flexibilität.

Ausblick

Das UML-Diagram in diesem Artikel zeigt in vereinfachter Form die beteiligten Komponenten dieses Architekturmusters, welches in den folgenden Artikeln/Beiträgen weiter erläutert werden soll.

Im nächsten Teil werde ich etwas genauer auf die zugrunde liegenden Designprinzipien eingehen und verdeutlichen, warum der Einsatz von Composite Components in einem Softwareprojekt Sinn ergeben kann.

To be continued…

Quellen

Clean C++ / Sustainable Software Development – Patterns and Best Practices / Stephan Roth / ISBN 978-1-4842-27-92-3

David Tielke – Freiberuflich/Selbstständig / Trainer & Berater / https://www.david-tielke.de (zuletzt abgerufen am 21.04.2021)