Entwurfsmuster

Observer Pattern

Idee: Das Observer Pattern ermöglicht eine Entkopplung zwischen einem Subjekt (z. B. eine Datenquelle) und vielen Beobachtern (z. B. grafische Oberflächen oder Module). Wenn das Subjekt seinen Zustand ändert, benachrichtigt es automatisch alle registrierten Beobachter.

Ziel: Automatische, dynamische Synchronisation, ohne dass die Beobachter aktiv nachfragen müssen.

Praktisch:

• Das Subjekt kennt seine Beobachter nicht im Detail, nur deren Schnittstelle.
• Beobachter können sich an- oder abmelden.

Typische Fälle:

• UI-Elemente bei Änderungen aktualisieren.
• Event-Listener in Java GUIs oder bei Nachrichten-Übertragungssystemen.

Beispiel in Java:

interface Observer {
    void update();
}

class Subject {
    private List<Observer> observers = new ArrayList<>();
    void addObserver(Observer o) { observers.add(o); }
    void notifyObservers() { for (Observer o : observers) o.update(); }
}

Singleton Pattern

Idee: Das Singleton Pattern stellt sicher, dass nur genau ein Objekt einer Klasse existiert und bietet einen globalen Zugriffspunkt darauf.

Ziel: Zentrale Steuerung und kontrollierter Zugriff auf ein einziges Objekt.

Praktisch:

• Der Konstruktor ist privat, damit keine weiteren Instanzen erzeugt werden können.
• Eine statische Methode verwaltet die Erzeugung und Rückgabe der Instanz.

Typische Fälle:

• Logger-Klassen (damit alle Komponenten denselben Logger verwenden).
• Konfigurationsmanager.
• Caches, wo eine globale Instanz alle Daten hält.

Beispiel in Java:

public class Singleton {
    private static Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Factory Pattern (Factory Method)

Idee: Das Factory Pattern verschiebt die Verantwortung für das Erzeugen von Objekten von der aufrufenden Klasse in eine spezielle „Fabrik“-Klasse oder -Methode.

Ziel: Flexibilität bei der Instanziierung und Austauschbarkeit von Implementierungen ohne Anpassung der aufrufenden Logik.

Praktisch:

• Die aufrufende Klasse muss nicht wissen, welche konkrete Klasse sie bekommt.
• Neue Typen können später hinzugefügt werden, ohne die Factory-Nutzer zu ändern.

Typische Fälle:

• Erzeugen unterschiedlicher Datenbankverbindungen je nach Konfiguration (MySQL, PostgreSQL…).
• Erzeugen verschiedener UI-Komponenten je nach Betriebssystem (WindowsButton, MacButton...).

Beispiel in Java:

interface Animal { void speak(); }

class Dog implements Animal { 
    public void speak() { System.out.println("Woof"); } 
}

class Cat implements Animal { 
    public void speak() { System.out.println("Meow"); } 
}

class AnimalFactory {
    static Animal createAnimal(String type) {
        if ("dog".equalsIgnoreCase(type)) return new Dog();
        else if ("cat".equalsIgnoreCase(type)) return new Cat();
        else throw new IllegalArgumentException("Unknown type");
    }
}

MVC Pattern (Model-View-Controller)

Idee: MVC teilt eine Anwendung in drei getrennte Verantwortlichkeiten:

• Model: Die Daten und Geschäftslogik.
• View: Die Präsentation der Daten (z. B. GUI, Webseiten).
• Controller: Die Steuerung und Verarbeitung von Eingaben.

Ziel: Trennung von Anliegen (Separation of Concerns), damit jede Schicht unabhängig entwickelt, gewartet oder getestet werden kann.

Praktisch:

• Der Benutzer interagiert mit der View (z. B. klickt auf einen Button).
• Der Controller verarbeitet die Eingabe, ändert das Model.
• Das Model benachrichtigt (z. B. via Observer-Pattern) die View über Änderungen.

Typische Fälle:

• Webanwendungen (Spring MVC, JSF, ASP.NET MVC).
• Desktopanwendungen (JavaFX, Swing, Android-Apps).

Beispiel in Java:

class Model {
    private String data;
    // getter und setter
}

class View {
    void display(String data) { System.out.println("Data: " + data); }
}

class Controller {
    private Model model;
    private View view;
    
    Controller(Model model, View view) {
        this.model = model;
        this.view = view;
    }

    void updateData(String data) {
        model.setData(data);
        view.display(model.getData());
    }
}

Zusammenfassung

• Observer: Push/Pull-Mechanismus für Statusänderungen
• Singleton: Eine einzige Instanz, global verfügbar
• Factory: Erstellen von Objekten ohne feste Kopplung an konkrete Klassen
• MVC: Trennung von Darstellung, Daten und Steuerlogik

Pattern	Hauptidee	Typischer Nutzen
Observer	Subjekt informiert dynamisch Beobachter	Live-Updates ohne Abfrage
Singleton	Nur eine Instanz, globaler Zugriff	Zentrale Steuerung
Factory	Erzeugung von Objekten entkoppeln	Austauschbare Implementierungen
MVC	Trennung von Daten, UI, Steuerung	Bessere Wartbarkeit, klare Struktur