Design Pattern | Facade

  • Montag, 07. März 2016 19:32
Artikel bewerten
(0 Stimmen)

Das Facade Design Pattern definiert eine vereinfachte Schnittstelle zur Benutzung eines Systems oder einer Menge von Objekten. Das Facade Design Pattern kann der Kategorie: "Structural Patterns" zugeordnet werden.

Gegeben sei ein komplexes Subsystem mit vielen Klassen und Abhängigkeiten zwischen ihnen. Clients die dieses Subsystem oder Teile davon nutzen möchten, müssen sich mit den verschiedenen Schnittstellen der enthaltenen Klassen befassen und die Funktionsweise verstehen. Dabei bauen sie zwangläufig viele Abhängigkeiten zu verschiedenen Objekten auf und koppeln sich eng an die Klassen des Subsystems.

Die Facade (dt. Fassade) wird zwischen Clients und dem Subsystem geschaltet. Es "kapselt" dabei das Subsystem, beinhaltet die komplexe Logik zum Arbeiten mit dem Subsystem und bietet für den Client eine vereinfachte Schnittstelle (Methoden) nach außen an. Die Fassade delegiert die Clientaufrufe ans Subsystem. Dadurch kann der Client das System über die Facade nutzen, ohne die Klassen, ihre Beziehungen, und Abhängigkeiten zu kennen.

UML:

a) Klassendiagramm:

b) Sequenzdiagramm: 

 

 

Anwendungsfälle:

Das Facade Design Pattern kann angewandt werden, wenn...

  • ... eine vereinfachte Schnittstelle zur Nutzung eines komplizierten Subsystems oder Menge von Objekten benötigt wird. Eine Facade bildet eine eingestellte Perspektive auf das Subsystem. Anspruchsvolle Clients können weiterhin das Subsystem direkt nutzen.
  • ... die Reduzierung der Abhängigkeiten zwischen dem Client und dem benutzten Subsystem angestrebt wird. Die Clients sind fortan nur noch von der Facade abhängig und damit vom Subsystem entkoppelt. Die Unabhängigkeit und Portabilität des Subsystems steigt.
  • ... ein System in Schichten unterteilt werden soll. Die Schichten kommunizieren nur noch über Fassaden, die den Zugang zum Subsystem darstellen. Somit wird das System unterteilt und die Abhängigkeiten zwischen den Teilsystemen gesenkt.

Vorteile:

  • Vereinfachte Schnittstelle. Der Client kann ein komplexes System einfacher verwenden, ohne die Klassen des Systems zu kennen und sich mit ihren mannigfaltigen Schnittstellen auseinander zu setzen. Eine Auseinandersetzung mit der Komplexität des Systems ist nicht mehr notwendig. Stattdessen kann eine einzige wohldefinierte Schnittstelle der Fassade genutzt werden.
  • Entkopplung des Client vom Subsystem. Da der Client nur noch gegen die Fassade arbeiten, ist er unabhängig von Änderungen im Subsystem. Wartungen und Modifikationen am Subsystem bedeuten nur noch Änderungen innerhalb des Systems und höchstens der Fassadenimplementierung. Die Schnittstelle der Fassade nach außen bleibt davon unbetroffen. Kein Code der Clients bricht.

Nachteile:

Der Hauptnachteil ist die weitere Indirektionsstufe, die eingeführt werden muss.

Fazit:

Änderungen im Subsystem pflanzen sich nicht mehr unkontrolliert durch die gesamte Applikation fort, sondern höchstens bis zur Implementierung der Facade. Die Facadeschnittstelle bleibt konstant. Die durch das Facade Design Pattern gewonnene Änderungsstabilität und den gesenkten Änderungsaufwand sei in folgenden Abbildungen illustriert. Eine Fassade verringerte die Abhängigkeiten des Clients, da die Anzahl der Objekte, die vom Client gehändelt werden müssen, signifikant gesenkt werden kann. Jedoch können wenn gewünscht anspruchsvolle Clients weiterhin die Fassade übergehen und die Objekte des Subsystems direkt verwenden, sollte die bereitgestellte Schnittstelle der Fassade einmal nicht ausreichen.

Letzte Änderung am %AM, %13. %447 %2016 %09:%Apr
Kommentare einblenden

Copyright © 2017 ABAP-Workbench.de