Von wegen abstrakt: Design Patterns in der Softwareentwicklung

Software Design Patterns – schneller zur Lösung

Was sind Design Patterns?

Software Design Patterns, auf Deutsch Entwurfsmuster, sind Templates bzw. strukturierte Lösungen für wiederkehrende Probleme, auf die man im Softwaredesign und in der -Entwicklung immer wieder trifft – quasi eine Musterlösung, die Strukturen schafft. Denn Struktur ist eines der wichtigsten Konzepte, um die Komplexität der Informatik beherrschbar zu machen.

Warum sind Software Design Patterns wichtig?

Zum einen arbeitet man schneller und effizienter, da Design Patterns „vorgefertigte“ Lösungsansätze für komplexe Probleme bieten. Zum anderen erleichtern Design Patterns das tagtägliche Arbeiten im Team enorm, da sie uns eine gemeinsame Kommunikationsbasis bzw. ein einheitliches Vokabular bieten. Design Patterns sind eine klassische Software Engineering Methode, die dem Code Struktur geben. Wer von außen auf den Code schaut, kann dann relativ schnell erkennen, was der Code macht.

Für wen bzw. welche Berufsfelder sind Design Patterns relevant?

Dieses Konzept wird vor allem im Bereich der Softwareentwicklung und des Softwaredesigns angewandt – ursprünglich stammt die Idee aber aus den Entwurfsmustern der IT-Architektur. Daher sind Design Patterns vor allem für Software Engineers und IT-Architekten beim Design von Code und Architekturen relevant. Business Analysten müssen nicht unbedingt konkrete Patterns kennen. Dennoch bin ich auch in meiner früheren Rolle als Business Analyst immer wieder auf die gleichen Probleme innerhalb eines Projekts gestoßen und habe mir dazu Designs bzw. abstrakte Lösungen überlegt.

Get the future you want – als Softwareentwickler (w/m/d) bei Capgemini

Du willst mit Design Patterns Software entwickeln? Bewirb dich jetzt als Softwareentwickler und gestalte die Zukunft der IT-Welt von morgen.  

Jetzt bewerben

Design Patterns in der Anwendung

Welche verschiedenen Design Patterns gibt es?

Es wird grob zwischen drei Klassen unterschieden. Diese Differenzierung ergibt sich daraus, dass man die Design Patterns an verschiedene Situationen anpasst und mit ihnen unterschiedliche Problematiken lösen möchte.

1. Erzeugungsmuster (Creational Patterns): Hier liegt der Fokus stark auf der Erzeugung von Objekten. Die Konstruktion eines Objekts wird von seiner Repräsentation entkuppelt. Das heißt, ich gebe den Befehl, dass ich das Objekt brauche, aber wie es erzeugt wird, ist nach außen gekapselt – also nach außen abgeschirmt und daher für mich nicht ersichtlich.
2. Strukturmuster (Structural Patterns): Diese bieten einen Lösungsansatz für die Fragestellung, wie bestimmte Entitäten zueinander in Bezug stehen sollen. Sie unterstützen dabei, die Struktur der gesamtem IT-Struktur sauber zu designen.
3. Verhaltensmuster (Behavioural Patterns): Das sind Patterns, die oftmals komplexes Verhalten von Code kapseln, um nach außen hin eine möglichst einfache Struktur und Schnittstelle transparent darzustellen.

Kannst du uns das Prinzip eines Design Patterns an einem konkreten Beispiel erklären?

Das Factory Pattern ist eines der bekanntesten Entwurfsmuster und repräsentiert die Klasse der Erzeugungsmuster am besten: Dieses Software Pattern kapselt die Instanziierung – also die Erstellung eines Objekts – nach außen hin für den Nutzer, für den Prozess oder für den Teil des Programms, der dieses Objekt zur Laufzeit anfordert.

Ich mache es an einem Beispiel anschaulich: Wer ein Zeichenprogramm programmiert, macht sich darüber Gedanken, dass Nutzer später damit geometrische Formen erstellen möchten. Man weiß noch nicht, welche Anforderung an das Objekt zur Laufzeit gestellt wird, beispielsweise welche geometrische Form in dem Moment gezeichnet werden soll. Das lässt sich durch eine Factory designen, die erst zur Laufzeit übergeben bekommt, was sie dann zurückgeben soll: zum Beispiel einen Kreis. Wie eine kleine Fabrik, die zur Laufzeit genau das produziert, was gefordert ist. Wie sie das macht, ist für mich als Nutzer jedoch irrelevant. Ohne das Factory Pattern müsste das Graphic User Interface jede Anforderung zur Laufzeit selbst instanziieren – das wird sehr komplex und unübersichtlich. Diese Funktionalität kapselt die Factory nach außen.

Was wäre ein Beispiel für ein Design Pattern aus der Klasse der Verhaltensmuster?

Ein Beispiel für die Klasse der Verhaltensmuster ist das Strategy Pattern. Dieses ist dann anzuwenden, wenn ich den Algorithmus, also das Verhalten bzw. eine konkrete Strategie, kapseln möchte. Dieses Pattern könnte man in der Routennavigation anwenden, beispielsweise wenn ich die Reiseroute von meinem Capgemini Standort Köln zum Standort Düsseldorf berechnen möchte. Als Nutzer einer Navigations-App entscheide ich, ob ich gehen, Auto fahren oder öffentliche Verkehrsmittel nutzen möchte – die Strategie wählt dann erst zur Laufzeit aus, welcher Algorithmus gebraucht wird.

Die Routenberechnung ist also abstrakt das gleiche, die Verfeinerung ist das Fortbewegungsmittel. Die Nutzeroberfläche der App kommuniziert mit dem Strategie-Interface, welches in dem Moment auswertet, wie es sich verhalten und welchen Algorithmus es ausführen muss. Und kapselt wiederum die Komplexität nach außen. Für den User der App ist das natürlich irrelevant, aber es vereinfacht die Kommunikation zwischen der App-Oberfläche und der Logik dahinter. Das Prinzip des nach außen kapseln ist grundsätzlich entscheidend für alle Design Patterns – auch für Structural Patterns.

Was gilt es bei der Anwendung von Design Patterns zu beachten?

Aus meiner Sicht, dass man deren Verwendung im Code durch die gängige Namenskonventionen kenntlich und lesbar macht. Damit auch andere, die damit arbeiten, das angewandte Design Pattern im Code oder Design schnell wiedererkennen. Außerdem sollte man keine Angst davor haben, Software Patterns auch anzuwenden und sich sogar eigene Patterns zu überlegen. Sie machen das Leben leichter.

Warum sollten sich Software Engineers eigene Design Patterns definieren?

Es ist nicht so, dass die heute niedergeschriebenen Patterns das allumfassende und definierte Wissen sind. Innerhalb eines Projektes stößt man immer wieder auf Probleme, für die man sich ein Muster zur Problemlösung designt. Es kommt auch durchaus vor, dass sich Kolleginnen oder Kollegen eigene Patterns überlegen und diese im Projekt-Umfeld für alle Teammitglieder etablieren.

Design Patterns lernen – Tipps für Bewerber*innen

Welche Kenntnisse sollten Absolvent*innen im Bereich Design Patterns mitbringen?

Design Patterns kommen in nahezu allen unseren Projekten zum Einsatz – sie gehören zum Berufsalltag eines Software Engineers bei Capgemini dazu. Deshalb ist es wichtig, sich auch schon zu Beginn der Karriere damit auseinanderzusetzen. Ich weiß aus eigener Erfahrung, dass das Thema im Studium oft sehr abstrakt vermittelt wird – obwohl es das gar nicht ist. Absolventen sollten sich ein allgemeines Verständnis für Softwareentwicklung und den -Entwicklungsprozess aufbauen. Denn genau hier kommen Design Patterns zum Tragen, die das Design strukturieren, es lesbar und wartbar machen, damit auch in 10 Jahren noch nachvollziehbar ist, welche Methode und Strukturen angewandt wurden. Jobstarter sollten daher wissen, was Design Patterns sind und wozu man sie nutzt. Angehende Software Engineers sollten eine Idee von möglichen Anwendungsszenarien und ein Verständnis für den Sinn dahinter mitbringen.

Wie können Studierende oder Absolvent*innen die Anwendung von Design Patterns lernen bzw. sich entsprechendes Wissen aneignen?

Ich empfehle das Buch „Design Patterns“ von Gamma, Helm, Johnson und Vlissides. Diese vier Herren haben initiativ ein umfassendes Werk zum Thema geschrieben. Teilweise etwas trocken und abstrakt geschrieben, aber ich kann es jedem ans Herz legen, der sich auch beruflich damit beschäftigen möchte. Außerdem gibt es Websites wie Refactoring Guru oder Sourcemaking auf welchen Design Patterns beispielhaft und oft spielerisch erklärt werden – inklusive spannender Cases, die das Thema greifbar machen.

Werden Design Patterns in Vorstellungsgesprächen bei Capgemini thematisiert?

Die Fragen im Vorstellungsgespräch ergeben sich oftmals im Gesprächsverlauf. Software Engineers sollten nicht nur gut programmieren können, sondern auch das große Ganze im Blick behalten. Bewerberinnen und Bewerber sollten mir zeigen können, dass sie mit der klaren Definition von Anforderungen vertraut und sich dessen Wichtigkeit bewusst sind. Denn ziellos drauf los zu programmieren ist nicht nur in der Projektarbeit mit dem Kunden ein No-Go.

Im Rahmen der Anforderungsdefinition gehört auch dazu, sich Gedanken zu machen, ob der Einsatz von Design Patterns sinnvoll ist. Wenn mir Studierende erzählen, welche Anforderungen sie für ihre Abschlussarbeit definiert haben, frage ich schonmal, nach welchen Design-Prinzipien sie vorgegangen sind und ob ihnen der Begriff „Design Patterns“ etwas sagt. Wenn sie mir dann den Sinn von Design Patterns erläutern können, hinterlässt das einen sehr positiven Eindruck.

Zum Schluss: Welche Tipps möchtest du Bewerber*innen in Bezug auf Design Patterns mit auf den Weg geben?

Tipp 1: Habt keine Scheu davor! Das Thema verliert die Abstraktion, wenn Ihr Euch praktisch damit auseinandersetzt – beispielweise indem Ihr Euch Praxisbeispiele anschaut.

Tipp 2: Definiert Euch Eure eigenen Design Patterns! Überlegt doch mal, was für ein Pattern Eure tägliche Arbeit erleichtern könnte und probiert Euch aus.

Tipp 3: Eignet Euch ein allgemeines Verständnis vom Softwareentwicklungsprozess an. Ein guter Software Engineer sollte nicht nur coden können, sondern auch einen Blick für das große Ganze haben.

Vielen Dank für das Interview und die vielen Tipps, Lutz.