Vorlage:Gesprochene Wikipedia Die Applikations-Fassade ist ein Analysemuster aus der Softwaretechnik von Martin Fowler, welches die Organisation von Schichtenarchitekturen verbessert. Das Grundprinzip ähnelt dem des EntwurfsmustersFassade“ der GoF. Beide Muster vereinfachen die Nutzung eines komplexen Subsystems durch den Zugriff über eine spezielle Schnittstelle.

Prinzip der GoF-Fassade


Inhaltsverzeichnis

Schichtenarchitektur[Bearbeiten | Quelltext bearbeiten]

Der Einsatz der Applikations-Fassade setzt eine Aufteilung der Anwendung in mehrere Schichten voraus (Multi-Tier-Architektur):

Typischerweise kann die Präsentationsschicht nur einfache Datentypen verarbeiten, während die Domäne komplizierte abstrakte Datentypen enthält. Daher muss die Applikationslogik die aus der Domänenschicht kommenden Daten für die einfacher gehaltene Präsentationsschicht übersetzen. Umgekehrt ist sie dafür verantwortlich die vom Nutzer eingegebenen Daten in geeigneter Form in die Domäne einzubringen. Um die Programmierung von Nutzeroberflächen zu erleichtern kann an dieser Stelle das Applikations-Fassade-Muster eingesetzt werden.

Aufteilung der Anwendung in Schichten

In Umgebungen in denen die Anwendung auf verschiedene Prozesse verteilt ist (z.B. Client-Server-System), sollte die Fassade ebenfalls verteilt werden. Anfragen der Präsentationsschicht an die clientseitige Fassade werden dann von dieser an eine Fassade auf dem Server weitergereicht und dort bearbeitet.

Siehe auch: Anwendungsdomäne

Prinzip[Bearbeiten | Quelltext bearbeiten]

Die Idee, die hinter der Applikations-Fassade steckt ist im Grunde recht simpel. Genau wie die Fassade eines Hauses versteckt sie das komplizierte Gerippe, das die eigentliche Substanz bildet. Dabei erzeugt sie eine logische Sichtweise. Da man auf ein Geschäftsmodell meist viele Sichtweisen haben kann, gibt es häufig mehr als nur eine Applikations-Fassade. Der Trick ist einzelne Teile aus der Domänenschicht so zusammenzubringen und verfügbar zu machen, dass ein logisches Abbild entsteht.

Stellen wir uns z.B. das Softwaresystem einer Bank vor. In der Domänenschicht gibt es Kundenstammdaten, Konten, Depots, Kredite, Transaktionen, etc. Die Vetriebsabteilung klassifiziert Kunden nach diesen Daten. Hier kann eine Fassade „klassifizierter Kunde“ eingeführt werden. Sie wird eine Methode getClassification() anbieten, die zwar nach außen einfach auftritt; der Algorithmus, der die Bewertung in der Domäne sucht und konsistent hält mag aber komplex sein. Er durchsucht die Objekte der Domäne abhängig vom jeweiligen Kunden und gibt einen String („A“, „B“, ...) zurück. Für die Ausgabe der Klassifizierung eines Kunden auf dem Bildschirm reicht dann ein einfacher Aufruf der Methode:

ClassifiedCustomer classifiedCus = ClassifiedCustomer.getByName("Max Mustermann");
System.out.println(classifiedCus.getClassification());

Implementierung[Bearbeiten | Quelltext bearbeiten]

Zur Umsetzung der Applikations-Fassade macht Martin Fowler recht konkrete Angaben (was für ein Analysemuster eher erstaunlich ist). Jede Applikations-Fassade besitzt ein subject, also ein bestimmtes Objekt aus der Domäne. Dieses Objekt wird als Startpunkt aller vorzunehmenden Aktionen verwendet. Die Sichtbarkeit des Subjektes ist auf private zu setzen.

In unserem obigen Beispiel wäre das Subjekt der Applikations-Fassade „klassifizierter Kunde“ ein einfaches Objekt vom Typ „Kunde“. Von ihm aus kann ClassifiedCustomer zu den einzelnen Konten, Depots und Transaktionsdaten navigieren oder eben die Einstufung in ein Klassifizierungssystem finden und bearbeiten. Damit ist die Klassifizierung nun ein Attribut der Applikations-Fassade ClassifiedCustomer. Aber Achtung: alle Attribute einer Fassade sollten von Typen sein, die auch in der Domänenschicht vorkommen.

Siehe auch: Objektorientierte Programmierung

Aksessoren[Bearbeiten | Quelltext bearbeiten]

Martin Fowler nennt die Aksessoren der Applikationsfassade retrieval method und meint damit das, was man im Allgemeinen unter einem Getter versteht. Diese Methode hat demnach die Aufgabe den aktuellen Wert eines Attributs aus der Domänenschicht zu holen und zurückzugeben. In manchen Fällen kann diese Aufgabe wesentlich komplizierter sein als es auf den ersten Blick scheint.

Nehmen wir an ein Kunde unserer Bank will den aktuellen Stand seines Gesamtvermögens wissen. So müssen die Salden aller Konten, alle Kredite und alle Depots berücksichtigt und beaufschlagt werden. Ausserdem stellt sich die Frage, wie sichergestellt werden kann, dass die Rechnung die aktuellsten Werte enthält. Solche schwierigen Vorgänge versteckt die Applikations-Fassade hinter einer einfachen Methodenschnittstelle:

classifiedCus.getTotalBalance();

Bei der Implementierung solcher Methoden ist darauf zu achten, dass der Rückgabetyp sich vom tatsächlichen Typen des untersuchten Attributes unterscheidet. Während für das Attribut hier z.B. ein komplexer Datentyp (Quantity,Money) angewendet werden sollte, wird die grafische Oberfläche eher eine Fließkommazahl erwarten.

Manipulatoren[Bearbeiten | Quelltext bearbeiten]

Natürlich muss eine Applikations-Fassade auch Methoden zur Manipulation der Attribute anbieten, sog. update methods. Diese Setter können ebenfalls eine sehr hohe Komplexität erreichen. Nicht selten erfordern sie beachtlichen Einsatz. Zwischen den Objekten der Domänenschicht bestehen viele Beziehungen, gerade deshalb setzt man ja die Applikations-Fassade ein. Wird nun eines dieser Objekte verändert, so müssen auch abhängige Objekte unter Umständen aktualisiert werden.

Suchen wir als Beispiel einen unserer Kunden, der als „C-Kunde“ eingestuft ist (also am unteren Ende unseres Systems rangiert) und aktualisieren wir mit der update method sein Konto aufgrund eines unerwarteten Geldsegens:

classifiedCus.setBalance(new Quantity(1000000,Unit.get("Euro"))); 

Offensichtlich muss nun auch dafür gesorgt werden, dass die Einstufung des Kunden automatisch aktualisiert wird. Alternativ könnte auch die Einstufung als nicht aktuell markiert und bei der nächsten Abfrage auf den neuesten Stand gebracht werden.

Doch damit nicht genug. Es sind noch viele Szenarien denkbar, welche die Implementierung einer update method verkomplizieren können. Z.B. könnte es in einem System unzulässig sein beim Setzen eines Attributes seinen alten Wert einfach zu überschreiben. Dann muss bei einer Aktualisierung der alte Wert irgendwie gesichert oder markiert werden. Aber auch Update-Methoden für als Collections ausgeprägte Attribute machen die Implementierung aufwändig. In diesem Fall werden zwei Methoden notwendig: eine zum Hinzufügen von Werten zur Liste und eine zum Löschen.

Validierer[Bearbeiten | Quelltext bearbeiten]

Werden Daten in die Domänenschicht eingebracht, also Werte von Objekten verändert muss sichergestellt werden, daß diese Daten auch plausibel sind. In einfachen Fällen kann es ausreichen für qualitative Merkmalstypen eine Liste mit möglichen Ausprägungen und für quantitative Merkmale Grenzen bereitzuhalten. Dies geschieht in Form einer legal values method. Die Validierungsmethode überprüft dann einfach ob der gegebene Wert in der Liste der erlaubten Werte aufgeführt ist, bzw. ob er innerhalb der vorgegebenen Grenzen liegt. Manchmal ist die Überprüfung auf Zulässigkeit aber auch nicht ganz so einfach, z.B. wenn es sich um Datumsangaben handelt.

Standardwerte[Bearbeiten | Quelltext bearbeiten]

Schließlich gehört zur Applikations-Fassade noch eine sog. default method. Hinter ihr verbirgt sich ein wirkungsvoller Trick zur weiteren Reduktion der Komplexität. Belegt man einen Datensatz beim Anlegen zunächst mit Standardwerten, dann kann man beim Einpflegen der initialen Werte einfach auf die Update-Methode zurück greifen. Die Umsetzung der Standardwerte-Methode ist sehr einfach, sie ist im Grunde eine spezieller Getter. So lässt sich das System ohne großen Aufwand vereinfachen.

UML-Diagramm der Domänenschicht aus Martin Fowlers Artikel Application Facades
UML-Diagramm der Applikationslogik aus Martin Fowlers Artikel Application Facades
Übersicht: Methoden der Applikations-Fassade
Methode OO-Name Funktion
retrieve get Aksessor
update set Manipulator
legal values   Liste zulässiger Werte / Grenzwerte
validation   Validierer
default   Standardwert setzen

Mehrere Applikations-Fassaden[Bearbeiten | Quelltext bearbeiten]

Der Einsatz mehrerer Applikations-Fassaden bietet weitere Möglichkeiten die Architektur der Anwendung zu verbessern. Verwendet eine Ansicht der Präsentationsschicht Informationen aus mehreren Fassaden, kann sie dem Anwender völlig neue Darstellungen zur Verfügung stellen. Auch Vererbung kann bei Fassaden sinnvoll eingesetzt werden. In unserem Beispiel einer Banken-Software existiert wahrscheinlich eine Applikations-Fassade „Customer“, „ClassifiedCustomer“ ist also nur eine Spezialisierung. Solche Vorgehensweisen verbessern das System zusätzlich hinsichtlich Flexibilität und Stabilität.

Literatur[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]