https://padlet.com/patrick_wade1/q4hsb899ynh2 Quelle https://www.philipphauer.de/study/se/design-pattern/facade.php en-us 2019-12-16 09:22:56 UTC 2024-06-03 11:31:02 UTC hello@padlet.com patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424432273 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."]]> 2019-12-16 09:23:23 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424432273 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424434274 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.]]> 2019-12-16 09:31:45 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424434274 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424434511 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.]]> 2019-12-16 09:32:34 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424434511 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424434804 2019-12-16 09:33:44 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424434804 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437213 2019-12-16 09:42:20 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437213 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437330 2019-12-16 09:42:48 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437330 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437741

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.

]]> 2019-12-16 09:44:20 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437741 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437930 2019-12-16 09:45:05 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424437930 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424438319 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.
} ]]> 2019-12-16 09:46:38 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424438319 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424438424 Sekretaer sekretaer = new Sekretaer();
sekretaer.schreibenVersenden("Dieser Text soll verschickt werden");]]> 2019-12-16 09:47:10 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424438424 patrick_wade1 https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424438578

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.

]]> 2019-12-16 09:47:45 UTC https://padlet.com/patrick_wade1/q4hsb899ynh2/wish/424438578