1. Startseite
  2. Wissen kompakt
  3. Entwurfsmuster

Entwurfsmuster

Inhaltsverzeichnis: DefinitionArten und KategorienVorteile und NachteileTippsFragen aus der PraxisHinweise

Wissen kompakt: Entwurfsmuster sind wiederverwendbare Lösungen für typische Aufgaben im Softwareentwurf und fördern wartbare, flexible und erweiterbare Systeme.

Entwurfsmuster: Wiederkehrende Aufgaben elegant lösen

Komplexe Anwendungen bestehen aus vielen Modulen, die miteinander interagieren. Ohne klare Struktur wird der Code schnell unübersichtlich, schwer wartbar und fehleranfällig. Änderungen an einer Komponente können unerwartete Auswirkungen an anderer Stelle haben. Die Entwicklung wird ineffizient, die Erweiterung mühsam.

Entwurfsmuster – im deutschsprachigen Raum auch bekannt unter dem englischen Begriff Design Pattern – bieten für solche typischen Aufgaben im Softwareentwurf praxiserprobte, wiederverwendbare Lösungen. Sie beschreiben bewährte Vorgehensweisen zur Strukturierung von Code, zur Objekt-Erzeugung oder zur Organisation der Kommunikation zwischen Komponenten. Entwurfsmuster helfen dabei, Software flexibler, verständlicher und leichter wartbar zu gestalten – unabhängig von der Programmiersprache oder dem konkreten Anwendungsfall.

Entwurfsmuster: Wiederkehrende Aufgaben elegant lösen

Entwurfsmuster bieten bewährte Lösungen für typische Herausforderungen im Softwareentwurf. Sie abstrahieren wiederkehrende Aufgaben oder Problemlagen und ermöglichen es Entwicklern, sich auf das Wesentliche im Design zu konzentrieren – ohne sich in technischen Details zu verlieren. Durch ihre Wiederverwendbarkeit sparen sie Zeit und Aufwand bei Entwurf und Implementierung. Gleichzeitig schaffen sie Flexibilität durch klar definierte Schnittstellen und Regeln für Anpassungen und Erweiterungen. Ihre modulare Struktur reduziert die Kopplung zwischen Komponenten und erleichtert so die Wartung. Darüber hinaus fördern Entwurfsmuster die Kommunikation im Team, indem sie ein gemeinsames Begriffsverständnis schaffen.

Arten und Kategorien von Entwurfsmustern

Es gibt verschiedene Arten oder Kategorien von Design Patterns. Geht es nach der sogenannten Gang of Four [1] gibt es drei grundlegende Kategorien, die jeweils unterschiedliche Aspekte des Softwareentwurfs adressieren:

Erzeugungsmuster (Creational Patterns):

Diese Entwurfsmuster unterstützen die kontrollierte und flexible Erstellung von Objekten. Sie entkoppeln den Erstellungsprozess von der konkreten Implementierung und bieten damit mehr Anpassungsmöglichkeiten. Ziel ist es, Objekte so zu erzeugen, dass sie gut in den jeweiligen Anwendungskontext passen. Typische Beispiele sind:

  • Singleton: Stellt sicher, dass eine Klasse nur eine Instanz besitzt, und bietet einen globalen Zugriffspunkt.
  • Factory Method: Definiert eine Schnittstelle zur Objekterzeugung, während die konkrete Instanziierung Unterklassen überlassen wird.
  • Abstract Factory: Erzeugt Familien verwandter Objekte, ohne deren konkrete Klassen zu kennen.
  • Builder: Trennt die Konstruktion komplexer Objekte von deren Repräsentation, sodass verschiedene Varianten desselben Objekts entstehen können.
  • Prototype: Erzeugt neue Objekte durch das Kopieren eines vorhandenen Prototyps.

Strukturmuster (Structural Patterns):

Strukturmuster helfen dabei, Klassen und Objekte zu größeren, stabilen Strukturen zusammenzufügen. Sie definieren klare Beziehungen zwischen Komponenten und ermöglichen es, Funktionalitäten zu erweitern, ohne die interne Struktur zu verändern. Bekannte Vertreter sind:

  • Adapter: Passt die Schnittstelle einer Klasse an eine andere an, um inkompatible Klassen miteinander arbeiten zu lassen.
  • Bridge: Trennt Abstraktion und Implementierung, sodass beide unabhängig voneinander verändert werden können.
  • Composite: Erlaubt es, Objekte zu Baumstrukturen zusammenzufassen, um Teil-Ganzes-Hierarchien einheitlich zu behandeln.
  • Decorator: Fügt einem Objekt zur Laufzeit zusätzliche Funktionalitäten hinzu, ohne dessen Struktur zu verändern.
  • Facade: Bietet eine vereinfachte Schnittstelle zu einem komplexen Subsystem.
  • Flyweight: Reduziert den Speicherverbrauch großer Objektmengen, indem gemeinsame Daten geteilt werden.
  • Proxy: Stellt ein Platzhalter-Objekt bereit, das den Zugriff auf ein anderes Objekt kontrolliert.

Verhaltensmuster (Behavioral Patterns):

Diese Design Patterns legen den Fokus auf die Interaktion und Kommunikation zwischen Objekten. Sie beschreiben, wie Objekte zusammenarbeiten und Verantwortung teilen, um gemeinsam komplexe Aufgaben zu bewältigen. Zu den gängigen Mustern dieser Gruppe zählen:

  • Observer: Stellt sicher, dass abhängige Objekte automatisch benachrichtigt werden, wenn sich der Zustand eines Subjekts ändert.
  • Strategy: Kapselt eine Familie von Algorithmen, die austauschbar verwendet werden können.
  • Command: Verpackt Anfragen als Objekte, um sie später auszuführen, zu protokollieren oder rückgängig zu machen.
  • State: Ermöglicht einem Objekt, sein Verhalten bei Zustandsänderungen dynamisch zu ändern.
  • Template Method: Definiert den Grundaufbau eines Algorithmus und erlaubt Unterklassen, bestimmte Schritte zu überschreiben.
  • Mediator: Kapselt die Kommunikation zwischen Objekten und reduziert so direkte Abhängigkeiten.
  • Chain of Responsibility: Leitet eine Anfrage durch eine Kette von Handlern, bis einer sie bearbeitet.
  • Interpreter: Implementiert eine Sprache und verarbeitet Ausdrücke durch ein gemeinsames Interpretationsmodell.
  • Visitor: Trennt Algorithmen von den Datenstrukturen, auf denen sie arbeiten, und erlaubt neue Operationen, ohne bestehende Klassen zu ändern.

Neben diesen „klassischen“ Kategorien – Erzeugungsmuster, Strukturmuster und Verhaltensmuster – gibt es weitere Mustergruppen, die spezifische Herausforderungen adressieren:

Muster für objektrelationale Abbildung (Object-Relational Mapping Patterns):

Diese Entwurfsmuster lösen typische Probleme bei der Abbildung von objektorientierten Strukturen auf relationale Datenbanken. Sie helfen, Inkonsistenzen zwischen Objektmodell und Datenbankmodell zu überbrücken. Häufig verwendete Muster sind:

  • Data Mapper: Trennt die Geschäftslogik vollständig vom Datenbankzugriff, indem eine separate Komponente für die Datenübertragung zuständig ist.
  • Active Record: Kombiniert Daten und Datenbankoperationen in einem Objekt – jedes Objekt repräsentiert eine Datenbankzeile.
  • Identity Map: Stellt sicher, dass jedes Datenbankobjekt nur einmal im Speicher existiert, um Mehrfachinstanzen zu vermeiden.
  • Unit of Work: Bündelt Änderungen an Objekten und koordiniert ihre Speicherung in der Datenbank als eine Transaktion.

Nachrichtenübermittlungsmuster (Messaging Patterns):

Diese Design Patterns betreffen die Kommunikation zwischen verteilten Systemen oder Komponenten über Nachrichten. Sie definieren, wie Informationen zuverlässig, effizient und entkoppelt übertragen werden können. Zentrale Muster sind:

  • Message Queue: Ermöglicht asynchrone Kommunikation durch Zwischenspeichern von Nachrichten zur späteren Verarbeitung.
  • Publish/Subscribe: Sendet Nachrichten an alle interessierten Abonnenten, ohne dass Sender und Empfänger voneinander wissen müssen.
  • Message Router: Leitet Nachrichten anhand bestimmter Regeln an den richtigen Empfänger oder Pfad weiter.
  • Message Filter: Filtert eingehende Nachrichten anhand definierter Kriterien, um irrelevante Informationen auszusortieren.

Weitere Muster:

Es gibt auch Entwurfsmuster, die sich keiner der klassischen Kategorien eindeutig zuordnen lassen, aber dennoch verbreitet und nützlich sind. Dazu gehören:

  • Service Locator: Bietet eine zentrale Stelle, um Objekte oder Dienste bereitzustellen, ohne direkte Abhängigkeit zu deren Implementierung.
  • Dependency Injection: Überträgt die Verantwortung für das Bereitstellen von Abhängigkeiten an externe Komponenten (z. B. Frameworks).
  • Null Object: Verwendet ein Objekt mit neutralem Verhalten statt null, um Nullprüfungen zu vermeiden.
  • Lazy Initialization: Verzögert die Erstellung eines Objekts bis zu dem Zeitpunkt, an dem es tatsächlich benötigt wird.

Diese Arten bzw. Kategorien bieten eine strukturierte Grundlage für den Entwurf robuster, flexibler und wartbarer Softwaresysteme – unabhängig von Programmiersprache oder Anwendungskontext.

Vorteile und Nachteile von Entwurfsmustern

Die Anwendung von Design Patterns in Softwareprojekten bringt eine Vielzahl von Vorteilen mit sich. Einer der größten Pluspunkte ist die Wiederverwendbarkeit: Entwurfsmuster stellen praxiserprobte Lösungen für häufige Probleme bereit und sparen dadurch Zeit und Entwicklungsaufwand. Gleichzeitig fördern sie die Wartbarkeit des Codes, da sie Modularität und Entkopplung unterstützen – der Code wird dadurch verständlicher, leichter zu modifizieren und langfristig besser pflegbar.

Ein weiterer Vorteil ist die erhöhte Flexibilität und Erweiterbarkeit. Durch klar definierte Schnittstellen und strukturierte Architekturen lassen sich neue Funktionalitäten einfacher integrieren und bestehende Komponenten an veränderte Anforderungen anpassen. Zudem verbessern Entwurfsmuster die Kommunikation im Team, da sie ein gemeinsames Vokabular schaffen, auf das sich alle Beteiligten beziehen können.

Nicht zuletzt tragen Entwurfsmuster zur Steigerung der Softwarequalität bei. Ihre Anwendung führt zu robusteren, zuverlässigeren Systemen, da sie auf bewährten Konzepten beruhen. In ihnen steckt das kollektive Expertenwissen der Softwareentwicklergemeinschaft – Erfahrungen und Lösungen, die sich in vielen Projekten bewährt haben und von denen neue Entwicklungen unmittelbar profitieren können.

Trotz ihrer vielen Vorteile können Design Patterns auch gewisse Nachteile mit sich bringen. Wird ein Muster unüberlegt oder übermäßig eingesetzt, kann dies zu unnötiger Komplexität im System führen und die Wartbarkeit sogar verschlechtern – insbesondere, wenn das gewählte Muster nicht gut zum eigentlichen Problem passt.

Ein weiterer Aspekt ist der Lernaufwand: Es braucht Zeit, Erfahrung und ein gutes Verständnis, um Entwurfsmuster sinnvoll und korrekt anzuwenden. Ohne das nötige Hintergrundwissen besteht die Gefahr, Muster mechanisch zu verwenden, ohne deren Zweck oder Grenzen wirklich zu verstehen.

In manchen Situationen kann es zudem effizienter sein, eine spezifische, auf das Problem zugeschnittene Lösung zu entwickeln, anstatt ein allgemeines Muster aufwendig anzupassen. Wird ein ungeeignetes Muster gewählt, kann dies im schlimmsten Fall sogar die Leistung des Systems negativ beeinflussen.

Daher ist bei der Anwendung von Entwurfsmustern ein bewusster und situationsgerechter Einsatz entscheidend, um ihre Vorteile tatsächlich zu nutzen, ohne neue Probleme zu schaffen.

Tipps zur Anwendung von Design Patterns

Es gibt einige nicht ganz so offensichtliche, aber sehr wertvolle Tipps im Umgang mit Entwurfsmustern, die über die üblichen „Lerne die GoF-Muster“ und „Nutze Design Pattern situationsgerecht“ hinausgehen. Hier ein paar Einsichten, die man meist erst mit etwas Projekterfahrung gewinnt:

1. Entwurfsmuster sind Werkzeuge, keine Ziele

Viele Entwickler versuchen (gerade am Anfang) zwanghaft, ein Muster einzubauen, selbst wenn das Problem es gar nicht erfordert. Besser: Den Code erst entwickeln, dann refaktorisieren. Oft ergibt sich erst beim zweiten oder dritten Durchlauf, welches Muster wirklich passt.

2. Muster erkennen ist wichtiger als sie zu schreiben

In echten Projekten geht es häufig darum, bestehende Muster im Design Pattern anderer zu erkennen – etwa beim Debuggen, Refactoring oder Review. Wer das kann, versteht schneller, wie ein System funktioniert. Das spart Zeit und verhindert Fehler.

3. Kombinationen sind oft die Realität

In der Praxis tauchen Muster selten isoliert auf. Stattdessen greifen sie oft ineinander – z. B. ein Observer, der über einen Mediator koordiniert wird, oder ein Builder, der in einer Factory verwendet wird. Wer Muster kombinieren kann, gestaltet flexiblere Architekturen.

4. Varianten und Abwandlungen kennen lohnt sich

Viele Muster gibt es nicht nur in der „GoF-Version“, sondern in zig Varianten. Z. B. existieren verschiedene Singleton-Implementierungen mit Lazy Loading, Thread-Safety etc. Verstehen, warum es diese Varianten gibt, hilft beim richtigen Einsatz.

5. Entwurfsmuster sind keine Ersatzreligion

Ein gut gewählter, simpler if-else-Block ist manchmal besser als ein kompliziertes Strategy-Muster. Muster dürfen nicht die Lesbarkeit oder Einfachheit opfern – sie sind nur dann sinnvoll, wenn sie das Leben wirklich leichter machen.

6. Projektspezifische „Muster“ dokumentieren

In großen Codebasen entstehen häufig wiederkehrende Strukturen, die nicht in Büchern stehen – etwa ein typisches Event-Handling oder Caching-Verhalten. Diese teaminternen Muster sollten als „Custom Patterns“ dokumentiert und benannt werden. Das verbessert Kommunikation und Onboarding enorm.

7. Muster sind exzellente Diskussionswerkzeuge

Gerade in Code Reviews oder Architektur-Meetings hilft ein Satz wie „Das hier riecht nach einem Decorator, oder?“ enorm. Selbst wenn man sich am Ende dagegen entscheidet, schafft der Begriff eine gemeinsame Grundlage, um über Alternativen zu reden.

8. Muster helfen beim Refactoring – nicht nur beim Entwurf

Viele Muster eignen sich hervorragend, um unübersichtlichen oder gewachsenen Code zu ordnen. Statt alles neu zu schreiben, kannst du durch den gezielten Einsatz von z. B. State, Strategy oder Command Strukturen klarer machen – evolutionäres Design beim Refactoring statt Big Bang.

Fragen aus der Praxis

Hier finden Sie einige Fragen und Antworten aus der Praxis:

In welchen Bereichen kommen Entwurfsmuster in der Softwareentwicklung zum Einsatz?

Entwurfsmuster werden in nahezu allen Phasen und Bereichen der Softwareentwicklung genutzt – von der Planung und Gestaltung der Softwarearchitektur über die Umsetzung einzelner Module bis hin zur Pflege und Weiterentwicklung bestehender Systeme. Sie sind gleichermaßen relevant für Desktop-Software, Webanwendungen, mobile Apps, eingebettete Systeme, Echtzeitanwendungen und viele weitere Softwaretypen.

Darüber hinaus reichen die Prinzipien der Entwurfsmuster inzwischen über die Softwareentwicklung hinaus: Sie finden auch Anwendung im Webdesign, in der Mensch-Computer-Interaktion und sogar in der Didaktik und Pädagogik, wo strukturierte Lösungsansätze ebenfalls von großem Nutzen sind.

Wie entsteht ein neues Entwurfsmuster?

Ein neues Entwurfsmuster entsteht durch einen strukturierten Prozess, der fundierte Kenntnisse in Softwarearchitektur und -design voraussetzt. Ausgangspunkt ist die Beobachtung eines Problems, das in unterschiedlichen Projekten oder Kontexten immer wieder auftritt. Dieses wiederkehrende Problem wird sorgfältig analysiert, um die zugrunde liegenden Ursachen, Rahmenbedingungen und Einschränkungen zu verstehen.

Darauf aufbauend wird eine allgemeine Lösung entwickelt, die sich flexibel auf verschiedene Situationen übertragen lässt. Diese Lösung wird iterativ verfeinert und in unterschiedlichen Anwendungskontexten erprobt. Sobald sich ihre Brauchbarkeit bestätigt hat, wird das Muster umfassend dokumentiert – typischerweise mit einem Namen, einer Beschreibung des Zwecks, der typischen Einsatzszenarien, strukturellen Komponenten, möglichen Auswirkungen sowie konkreten Implementierungshinweisen. Oft ergänzen Codebeispiele und Diagramme die Darstellung.

Im letzten Schritt wird das neue Muster innerhalb der Entwickler-Community geteilt, um Feedback zu erhalten, Erfahrungen auszutauschen und das Muster gegebenenfalls weiterzuentwickeln oder zu verbessern.

Was sind Musterkataloge?

Musterkataloge – auch Pattern Catalogs genannt – sind systematisch organisierte Sammlungen von Entwurfsmustern. Sie dienen dazu, bekannte und bewährte Lösungen für wiederkehrende Probleme im Softwareentwurf übersichtlich darzustellen, zu klassifizieren und zugänglich zu machen.

Ein Musterkatalog enthält in der Regel eine Vielzahl von Mustern, die nach bestimmten Kriterien gruppiert sind – etwa nach Kategorie (z. B. Erzeugungs-, Struktur- oder Verhaltensmuster), Anwendungsbereich oder Schwierigkeitsgrad. Jedes Muster im Katalog ist ausführlich beschrieben, meist nach einem einheitlichen Schema: Name, Problemstellung, Kontext, Lösung, Konsequenzen, Beispielcode und ggf. Diagramme.

Ziel eines Musterkatalogs ist es, Entwicklern ein Nachschlagewerk an die Hand zu geben, mit dem sie passende Muster für konkrete Designprobleme schnell finden, verstehen und anwenden können.

Beispiele bekannter Musterkataloge:

  • Gang of Four (GoF) Katalog: der Klassiker mit 23 Entwurfsmustern
  • POSA (Pattern-Oriented Software Architecture): umfangreiche Kataloge für Architektur- und Infrastrukturmuster
  • Enterprise Integration Patterns: Muster für die Integration verteilter Systeme
  • Domain-Driven Design (DDD) Patterns: Muster für domänenzentrierte Softwareentwicklung

Musterkataloge sind nicht nur nützlich für die Praxis, sondern auch ein wertvolles Lern- und Kommunikationsmittel – sie helfen dabei, bewährte Konzepte weiterzugeben und gemeinsam weiterzuentwickeln.

Was sind Anti-Patterns?

Anti-Patterns sind wiederkehrende Lösungsansätze, die sich in der Praxis immer wieder als problematisch erweisen – obwohl sie auf den ersten Blick plausibel oder sogar vertraut wirken. Sie entstehen oft aus Zeitdruck, Gewohnheit oder mangelnder Reflexion und wirken zunächst wie eine einfache oder bewährte Lösung. Doch bei näherer Betrachtung – oder spätestens im Laufe der Zeit – zeigt sich: Sie lösen das eigentliche Problem nicht nachhaltig, sondern schaffen neue Herausforderungen oder verschärfen bestehende.

Typisch für ein Anti-Pattern ist, dass es sich regelmäßig beobachten lässt, obwohl seine negativen Folgen bekannt sind. In der Softwareentwicklung etwa spricht man vom God Object, wenn eine einzige Komponente zu viele Verantwortlichkeiten übernimmt und dadurch unwartbar wird. Im Projektmanagement kennt man das Scope Creep – die unkontrollierte Ausweitung von Anforderungen, weil klare Prioritäten oder Grenzen fehlen. Und in der Führung ist Mikromanagement ein klassisches Beispiel: Es vermittelt Kontrolle, führt aber häufig zu Demotivation und Ineffizienz.

Anti-Patterns sind also nicht bloß „Fehler“, sondern strukturelle Denk- oder Verhaltensmuster, die langfristig mehr schaden als nützen. Sie zu erkennen – und gezielt zu vermeiden – ist ein wichtiger Schritt hin zu professionellem, reflektiertem Arbeiten. Wer Anti-Patterns versteht, lernt nicht nur aus eigenen Erfahrungen, sondern auch aus typischen Stolperfallen anderer.

Welche Muster gibt es in der Softwareentwicklung, die keine Entwicklungsmuster sind?

Wenn in der Softwareentwicklung von „Mustern“ die Rede ist, denken viele zunächst an Entwurfsmuster (Design Patterns) – also wiederverwendbare Lösungsansätze für typische Entwurfsaufgaben. Doch es gibt zahlreiche andere Musterarten, die in unterschiedlichen Phasen, Ebenen und Kontexten des Softwareentwicklungsprozesses eine Rolle spielen. Sie alle teilen den Grundgedanken: eine bewährte Lösung für eine wiederkehrende Aufgabe in einem bestimmten Kontext zu beschreiben.

Hier finden Sie einige Beispiele:

Analysemuster

Diese Muster helfen in der Anforderungsanalyse, indem sie typische Probleme und Strukturen modellieren, die in vielen Domänen vorkommen – zum Beispiel bei der Modellierung von Verträgen, Buchungen oder Benutzerrechten.

Architekturmuster

Sie beschreiben bewährte Strukturen ganzer Softwaresysteme, etwa die Schichtenarchitektur (Layered Architecture), Client-Server, Microservices oder Event-driven Architecture. Architekturmuster betreffen die Makrostruktur eines Systems.

Idiome (Programming Idioms)

Idiome sind sprachspezifische Programmiertechniken oder typische Code-Konstruktionen, die in einer bestimmten Programmiersprache besonders elegant, effizient oder idiomatisch sind. Sie bewegen sich unterhalb der Ebene des Entwurfs.

Kommunikationsmuster

Diese Muster beschreiben typische Formen der menschlichen Kommunikation innerhalb eines Entwicklerteams oder einer Organisation – zum Beispiel Stand-up-Meetings oder Pair Programming. Sie zielen auf zwischenmenschliche Zusammenarbeit.

Organisationsmuster

Sie beschreiben wiederkehrende Strukturen und Dynamiken in Teams und Unternehmen, etwa wie Teams gebildet, Wissen verteilt oder Entscheidungsprozesse organisiert werden. Ein bekanntes Beispiel ist Chief Programmer Team.

SOA-Muster (Service-Oriented Architecture Patterns)

Diese Muster liefern bewährte Konzepte für den Aufbau serviceorientierter Architekturen, etwa zur Gestaltung von Services, zur Verwaltung von Schnittstellen oder zum Umgang mit Service-Kompositionen und -Orchestrierung.

Fazit: Muster sind weit mehr als nur ein Werkzeug für den Softwareentwurf. Sie durchdringen alle Ebenen der Softwareentwicklung – von der Kommunikation im Team über den Systementwurf bis hin zur konkreten Programmierung. Wer Muster in ihrer Vielfalt kennt und bewusst einsetzt, profitiert von kollektiver Erfahrung, meidet typische Fehler und gestaltet nachhaltigere Systeme und Prozesse.

Impuls zum Diskutieren:

Welche vermeintlich bewährten Praktiken in einer Organisation könnten in Wahrheit längst zum Anti-Pattern geworden sein – und warum hinterfragt sie niemand?

Hinweise:

Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.

[1] Gang of Four (GoF): Bezeichnung für das Autorenquartett Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides, das mit dem 1994 veröffentlichten Buch Design Patterns: Elements of Reusable Object-Oriented Software maßgeblich zur Etablierung von Entwurfsmustern in der objektorientierten Softwareentwicklung beigetragen hat. Das Werk beschreibt 23 grundlegende Design Patterns, gegliedert in Erzeugungs-, Struktur- und Verhaltensmuster, und gilt bis heute als Standardreferenz in der Softwarearchitektur.

Hier finden Sie ein Video zu den Design Patterns / Entwurfsmuster der Gang of Four.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Was ist Spaghetti-Code?

Was ist Spaghetti-Code?

Wissen kompakt: Was ist ein Code Review?

Was ist ein Code Review?

Wissen kompakt: Was ist ein Feature Freeze?

Was ist ein Feature Freeze?