# data[].attributes.body
Der Sekretär vereinfacht die Benutzung unseres Klassensystems durch den Client. Dieser muss fortan kein Wissen mehr um die notwendigen Klassen und Verarbeitungsschritte zum Aufsetzen und Verschicken eines Schreibens besitzen. Natürlich kann die Schnittstelle des Sekretärs beliebig um weitere Methoden zur einfachen Nutzung anderer Systemfunktionalitäten erweitert werden.

Clients, die nur ausgewählte Klassen unseres Systems nutzen wollen oder anspruchsvollere Aufgaben mit dem System erledigen möchten, für die die Schnittstelle des Sekretärs nicht ausreicht, können die Klassen weiterhin direkt nutzen. Natürlich kann dies auch verhindert werden. Siehe Variationen.

Wartbarkeit und Änderungsstabilität durch verringerte Abhängigkeiten und lose Kopplung zwischen Client und System. Der Client ist fortan nur noch von einer einzigen Klasse abhängig: dem Sekretär, der den Zugriff auf das System vereinheitlicht und vereinfacht. Änderungen an Klassen des Systems haben keinen direkten Einfluss mehr auf Code der Clients, solange diese auch ausschließlich den Sekretär nutzen. Änderungen an Systemklassen (andere Drucker-API oder Textverarbeitungs-API) schlagen höchstens bis in die Implementierung der Sekretärmethode schreibenAufsetzen() durch. Die Sekretär-API nach außen bleibt jedoch konstant. Siehe Vorteile.

Betrachten wir den Sekretär als Einstiegspunkt zu unserem System, so ist es auch denkbar, innerhalb des Systems weitere solcher Einstiegspunkte und Subsysteme zu definieren (beispielsweise eine Klasse Postfiliale mit einer vereinfachten Schnittstelle zum Frankieren und Absenden von Post mit den Systemklassen Briefmarkenautomat und Briefkasten). Dadurch realisieren wir einen Schichtenaufbau unseres Systems.

Keine Coderedundanz und Gefahr von Inkonsistenz beim Client. Da der Code zum Aufsetzen und Versenden von Dokumenten zentral bei dem Sekretär implementiert wurde, kann jeder Client diesen nutzen und muss ihn nicht jedes mal neu implementieren.

# data[].attributes.body
Sekretaer sekretaer = new Sekretaer();
sekretaer.schreibenVersenden("Dieser Text soll verschickt werden");

# data[].attributes.body
class Sekretaer {

public void schreibenVersenden(String text){
//Gegeben: Alle benötigten Klassen sind korrekt instanziiert, initialisiert und bekannt

//Computer muss angeschaltet werden.
computer.an();
//Das Textverarbeitungsprogramm muss geöffnet werden.
Textverarbeitungsprog textverarbeitungsprog = computer.getTextverarbeitungsprog();
textverarbeitungsprog.oeffnen();
//Mit dem Textverarbeitungsprogramm muss das Dokument erstellt werden
Dokument dokument = textverarbeitungsprog.getDokument(text);
//Drucker muss angeschaltet werden
drucker.an();
//Drucker muss konfiguriert werden
drucker.konfigurieren();
//Papier muss in den Drucker gelegt werden
drucker.papierNachfuellen();
//Das Dokument muss gedruckt werden
computer.drucke(dokument);
//Der Drucker sollte ausgeschaltet werden
drucker.aus();
//Der Computer sollte ausgeschaltet werden
computer.aus();
//Das Dokument muss mit dem Stift unterschrieben werden
stift.unterschreiben(dokument);
//Das Dokument muss mit dem Stempel gestempelt werden
stempel.stempel(dokument);
//Das Dokument muss mit Hilfe des Briefmarkenautomaten frankiert werden
briefmarkenautomat.briefmarkeBezahlen(dokument, 2);
//Das Dokument muss schließlich in den Briefkasten geworfen werden.
briefkasten.briefEinwerfen(dokument);
}

//Instanzvariable der genutzten Objekte Computer, Drucker, Stift etc.
}

# data[].attributes.body
Systemwissennotwendig. Jeder Client muss nicht nur jede benötigte Klasse des Systems kennen, sondern auch ihr Zusammenspiel und ihre Funktionsweise, um sie nutzen zu können.

Abhängigkeiten und geringe Änderungsstabilität. Da jeder Client viele verschiedene Klassen kennen muss, steigen seine Abhängigkeiten. Er ist hart an das System gekoppelt. Änderungen am System (Dokumente sollen speziell eingepackt werden, Briefmarken werden teuerer, die Drucker-API ändert sich, ein neues Textverarbeitungsprogramm mit anderer API wird eingeführt, Macs werden statt PCs verwendet ;-) ) führen zwangläufig dazu, dass der Clientcode bricht oder nicht mehr korrekt funktioniert - und das gilt für jeden Client, der das System nutzt. Die Folge ist hoher Wartungsaufwand.

Coderedundanz und Gefahr von Inkonsistenz. Alle Clients, die ein Schreiben aufsetzen, drucken und verschicken wollen, müssen immer den gleichen Code schreiben. Dabei kann es sehr schnell passieren, dass Schritte ausgelassen werden oder die APIs falsch verwendet wird.

# data[].attributes.body
Die Facade  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.

# data[].attributes.body
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.

# data[].attributes.body
Gang of Four Definition:
"Biete eine einheitliche Schnittstelle zu einer Menge von Schnittstellen eines Subsystems.
Die Fassadenklasse definiert eine abstrakte Schnittstelle, welche die Verwendung des Subsystems vereinfacht."