Entwurfsmuster in der Softwareentwicklung: Das etwas andere IKEA-Regalsystem
Softwareentwicklung ohne Design Pattern ist vergleichbar mit einer Suppe ohne Salz – sie sind essenziell, doch können für Neulinge herausfordernd sein.
(Bild: Black Jack/Shutterstock.com)
- Nils Kasseckert
Entwurfsmuster ähneln einem modularen IKEA-Regalsystem, das in verschiedenen Größen und Farben erhältlich ist. Sie lassen sich immer gleich kombinieren und erfüllen stets denselben Zweck. Die Farbe ist mit der Programmiersprache vergleichbar, die Regalgröße mit dem Entwurfsmuster. Je nach Anwendungsfall und Projektgröße bietet sich die Verwendung eines Regals in einer anderen Farbe oder Größe an.
Konkret sind Entwurfsmuster also Elemente wiederverwendbaren Codes in der objektorientierten Programmierung (OOP). Sie haben kein festgelegtes Design und beinhalten keinen fertigen Code. Entwurfsmuster bieten Lösungsansätze für typische Probleme in der OOP-Welt und sind auch bei immer komplexer werdenden Frameworks aktuell. Eine Informatikerin oder ein Informatiker kann sie unabhängig von der jeweiligen Programmiersprache einsetzen.
Aktuell gibt es mehr als 100 verschiedene Entwurfsmuster (Stand Januar 2024). Jedes Entwurfsmuster lässt sich einem Typus zuordnen. Die grundlegenden Typen sind: Erzeugungsmuster, Strukturmuster sowie Verhaltensmuster. Inzwischen gibt aber auch weitere Typen. Sie sind aufgrund der immer größer werdenden Menge an Entwurfsmustern hinzugekommen. Einfachheitshalber beschränkt sich dieser Artikel lediglich auf die grundlegenden Typen (Abbildung 1).
Der erste Typ sind Erzeugungsmuster. Sie dienen ausschließlich der Erzeugung neuer Instanzen und ermöglichen die Erstellung eines neuen Objekts unabhängig von seiner konkreten Implementierung. Dadurch ist die Objekterstellung ausgelagert und gekapselt. Die am häufigsten genutzten Erzeugungsmuster sind Singleton und Factory-Method.
Ein Unikat erstellen
Ein Singleton kann man sich wie eine globale Variable ohne Zugriffsschutz in der OOP vorstellen. Es ist während der gesamten Laufzeit nur ein einziges Mal erzeugbar, weshalb in einem System maximal eine Instanz eines Singletons existiert. Es kapselt die Verwaltung der Instanzen und stellt einen einheitlichen Zugriffspunkt zur Verfügung.
Jedes Singleton besteht aus einer privaten statischen Variablen und einer veröffentlichten statischen Methode (Abbildung 2). Die Variable enthält die aktuelle Instanz des Objekts über seinen gesamten Lebenszyklus. Die öffentliche Methode getInstance() gibt eine statische Variable zurück. Nur das Objekt selbst darf die Instanz erzeugen. Ein privater Konstruktor stellt das sicher.
Das Konstrukt ist leicht anzuwenden und zu verstehen. Zudem vereinfacht es Architekturentscheidungen. Dem stehen aber auch einige Nachteile entgegen. Zum einen benötigt eine Nutzerin beziehungsweise ein Nutzer bei jedem Zugriff auf ein Singleton den vollständigen Klassennamen. Dadurch entsteht eine starke Kopplung an den konkreten Typ, was bei automatisierten Softwaretests ein großes Problem darstellt. Schließlich ersetzen Dummy-Objekte normalerweise nicht benötigte Objekte. Das ist mit einem Singleton jedoch bei klassischen Programmiermethoden nicht möglich. Zum anderen verschlechtert der Einsatz dieses Konstruktes die Systemarchitektur. Schließlich ist für dieses Objekt keine Zugriffskontrolle möglich und jeder Nutzer kann darauf zugreifen. In der Praxis sollten Nutzer sich den Einsatz des Strukturmusters Singleton gut überlegen.
Besonders bei Einsteigern ist dieses Konstrukt aufgrund seiner Einfachheit beliebt. Es gibt zwar diverse Beispiele, die nicht auf die Softwarearchitektur achten, aufgrund der vielen Nachteile sollte man es aber nur in Ausnahmefällen einsetzen: Zum Beispiel dann, wenn die Testbarkeit oder Steuerung der Zugriffskontrolle nicht notwendig sind.
