20. Januar 2013

Entwurfsmuster: Fassade

Die folgenden Posts sollen eine Serie bilden, in der etablierte Entwurfsmuster (engl. Design-Patterns), die sich für den alltäglichen Einsatz in der Softwareentwicklung bewährt haben, vorgestellt werden sollen. Entwurfsmuster sind Lösungsmodelle für immer wiederkehrende Probleme beim Entwurf objektorientierter Software und bieten Lösungsansätze, die meist durch die Beschreibung von Klassen und Interfaces, sowie deren Funktion und Beziehung zueinander, beschrieben werden.

Den Anfang dieser Reihe von Posts soll die sogenannte "Fassade", ein relativ simples Entwurfsmuster bilden. Die Fassade (engl. Facade-Pattern) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung, das zu der Kategorie der Strukturmuster gehört und dessen Ziel es ist, eine Vielzahl verschiedener Schnittstellen eines Subsystems über eine einzige, einheitliche und oftmals vereinfachte Schnittstelle, verfügbar zu machen.

Dazu wird eine Schnittstelle definiert, die nur ausgewählte, von den Clients benötigte, Methoden anbietet. Aufrufe dieser Methoden werden intern an die jeweils zuständigen Klassen des Subsystems delegiert. Das folgende UML-Diagram verdeutlicht das Prinzip des Fassade-Patterns und zeigt beispielhaft wie die Delegation an die einzelnen Komponenten des Subsystems aussehen könnte.

Das Fassade-Pattern als UML-Klassendiagramm


Vorteile:
  • Die Fassade entkoppelt die einzelnen Klassen des Subsystems von den Clients, die sie verwenden. Dadurch können die Implementierungen und Schnittstellen der Subsystem-Klassen geändert werden, ohne die Clients anpassen zu müssen.
  • Die Verwendung des Subsystems wird erleichtert, weil dessen Komplexität durch die Fassade versteckt.
Nachteile:
  • Wenn Clients die Fassade umgehen und das Subsystem direkt ansprechen, wird das komplette Entwurfsmuster ausgehebelt. Normalerweise ist diese Möglichkeit technisch jedoch nicht zu verhindern. 
  • Wenn sich Schnittstellen innerhalb des Subsystems ändern, so muss jedes Mal die Fassade angepasst werden.
Fassaden können außerdem nach Bedarf weitere Verantwortlichkeiten wie Zugangskontrolle, Transaktionsmanagement oder Session-Handling übernehmen und die Clients von dem Subsystem, durch die Verwendung asynchroner Kommunikationsmechanismen, entkoppeln.

Keine Kommentare:

Kommentar veröffentlichen