Design Patterns – Singleton, Observer, Factory, Adapter, Iterator, Strategy, Decorator
Dieser Beitrag ist eine Begriffserklärung zu wichtigen Design Patterns – inklusive Prüfungsfragen und Tags.
In a Nutshell
Design Patterns sind bewährte Lösungsansätze für wiederkehrende Probleme in der Softwareentwicklung. Sie bieten standardisierte Entwurfsmuster für häufige Situationen und verbessern Code-Qualität, Wartbarkeit und Kommunikation.
Kompakte Fachbeschreibung
Design Patterns wurden durch die “Gang of Four” (GoF) populärisiert und beschreiben erprobte Lösungsstrategien für typische Probleme der objektorientierten Programmierung. Sie kategorisieren sich in Creational Patterns (Erzeugungsmuster wie Singleton, Factory), Structural Patterns (Strukturmuster wie Adapter, Decorator) und Behavioral Patterns (Verhaltensmuster wie Observer, Strategy, Iterator). Patterns fördern lose Kopplung, hohe Kohäsion und Wiederverwendbarkeit. Sie sind keine fertigen Algorithmen, sondern abstrakte Lösungsbeschreibungen, die auf spezifische Kontexte angepasst werden müssen.
Prüfungsrelevante Stichpunkte
- Creational Patterns: Singleton, Factory, Abstract Factory, Builder
- Structural Patterns: Adapter, Decorator, Facade, Proxy, Composite
- Behavioral Patterns: Observer, Strategy, Iterator, Command, Template Method
- Singleton: Globale Instanz, thread-safe Implementierung
- Observer: Publisher-Subscriber, lose Kopplung zwischen Objekten
- Factory: Objekterzeugung ohne konkrete Klassen zu kennen
- Adapter: Schnittstellenanpassung zwischen inkompatiblen Klassen
- Iterator: Sequenzieller Zugriff auf Collection-Elemente ohne interne Struktur preiszugeben
- Strategy: Austauschbare Algorithmen durch Interface-basierte Implementierung
Kernkomponenten
- Singleton Pattern (globale Instanz)
- Factory Pattern (Objekterzeugung)
- Observer Pattern (Beobachter-Muster)
- Adapter Pattern (Schnittstellenanpassung)
- Iterator Pattern (Sequenzieller Zugriff)
- Strategy Pattern (Algorithmen-Austausch)
- Decorator Pattern (dynamische Erweiterung)
- Template Method Pattern (Algorithmus-Gerüst)
- MVC Pattern (Architektur-Muster)
- Registry Pattern (zentrale Registrierung)
Praxisbeispiel
// Singleton Pattern Beispiel
public class DatabaseConnection {
private static DatabaseConnection instance;
private DatabaseConnection() {
// Private Constructor
}
public static synchronized DatabaseConnection getInstance() {
if (instance == null) {
instance = new DatabaseConnection();
}
return instance;
}
}
// Observer Pattern Beispiel
interface Observer {
void update(String message);
}
class EmailNotification implements Observer {
public void update(String message) {
sendEmail(message);
}
}
Erklärung: Singleton sichert globale Instanz, Observer ermöglicht Benachrichtigung bei Zustandsänderungen.
Vorteile und Nachteile
Vorteile
- Bewährte Lösungen für bekannte Probleme
- Verbesserte Kommunikation zwischen Entwicklern
- Fördern lose Kopplung und hohe Kohäsion
- Erhöhen Wiederverwendbarkeit und Wartbarkeit
Nachteile
- Können zu unnötiger Komplexität führen
- Lernkurve für Anfänger
- Manchmal Over-Engineering für einfache Probleme
- Erfordern kontextgerechte Anpassung
Typische Prüfungsfragen (mit Kurzantwort)
-
Zwei Hauptkategorien von Design Patterns? Creational (Erzeugung), Structural (Struktur), Behavioral (Verhalten).
-
Singleton Pattern Zweck? Sicherstellung, dass von einer Klasse genau eine Instanz existiert und global zugänglich ist.
-
Observer Pattern Anwendung? Wenn mehrere Objekte über Zustandsänderungen eines anderen Objekts informiert werden sollen.
-
Factory Pattern löst welches Problem? Objekterzeugung ohne konkrete Klassen im Client-Code kennen zu müssen.
-
Adapter vs. Decorator? Adapter passt Schnittstellen an, Decorator fügt Funktionalität dynamisch hinzu.
-
Iterator Pattern Vorteil? Ermöglicht einheitlichen Zugriff auf verschiedene Collection-Typen ohne interne Struktur preiszugeben.
-
Strategy Pattern verwenden? Wenn Algorithmen austauschbar sein sollen, ohne den Client-Code zu ändern.
-
MVC Pattern Komponenten? Model (Daten), View (Präsentation), Controller (Logik zur Verbindung von Model und View).