Design Patterns – Eine Kurzanleitung zum Facade-Muster.

Das Diagramm basiert ebenfalls auf dem angegebenen Beispiel. Um dieses Diagramm zu vereinfachen, können wir es in drei Teile aufteilen.

1. Client: Der Client ist in diesem Beispiel der Kunde eines Restaurants, der Essen bestellen will.
2. Fassade: Ihre Aufgabe ist es, dem Kunden einen vereinfachten Zugang zu zahlreichen voneinander abhängigen Subsystemen zu ermöglichen, die als kompliziert angesehen werden. In diesem Beispiel würde die Essensbestellung eines Kunden eine Reihe sorgfältig aufeinanderfolgender Methodenaufrufe von zwei verschiedenen Subsystemen (Kellner und Küche) erfordern.
3. Subsysteme: Die Subsysteme sind vor dem Kunden verborgen. Sie können auch für den Client nicht zugänglich sein. Der Kunde kann an keinem der Subsysteme herumfummeln, wo eine einfache Code-Änderung sich als fatal erweisen oder sogar andere unbekannte Teile des Systems selbst zerstören könnte. In diesem Szenario haben der Kellner und die Küche eine Reihe von Aufgaben zu erledigen. Die Aufgabe eines Teilsystems ist manchmal von der Aufgabe des anderen abhängig. Zum Beispiel kann die Küche das Essen nicht zubereiten, wenn der Kellner die Bestellung nicht in die Küche bringt. Der Kellner kann den Kunden nicht bedienen, wenn das Essen nicht gekocht ist.

Schritt 3 – Code nach Beispiel

Ich würde vorschlagen, den Code Klasse für Klasse aus meinem Git-Repository „Andreas Poyias“ oder die Schnipsel unten (in der angegebenen Reihenfolge) zu kopieren und in einen der verfügbaren Online-C++-Editoren wie c++shell, jdoodle, onlineGDB einzufügen und ihn auszuführen, um die Ausgabe zu beobachten. Lesen Sie dann die Kommentare oder die Beschreibung unten. Nehmen Sie sich die Zeit, sie gründlich zu lesen (das bedeutet eine Minute, nicht weniger und nicht mehr).

Subsysteme

In diesem Beispiel sind die beiden Subsysteme das Waiter_Subsystem1und dasKitchen_Subsystem2. Auf den ersten Blick scheint jedes Subsystem unabhängig zu sein, da sie bestimmte Aufgaben einzeln erledigen können. Aber ist das wirklich so?

#include <iostream>
using namespace std;class Waiter_Subsystem1
{
public:
void writeOrder() { cout << " Waiter writes client's order\n";}
void sendToKitchen(){ cout << " Send order to kitchen\n";}
void serveCustomer(){ cout << " Yeeei customer is served!!!\n";}
};class Kitchen_Subsystem2
{
public:
void prepareFood(){ cout << " Cook food\n";}
void callWaiter() { cout << " Call Waiter\n";}
void washDishes() { cout << " Wash the dishes\n";}
};

Fassade: In diesem Beispiel geht es bei der Klasse Facade um Essensbestellungen in einem Restaurant. Um eine Essensbestellung erfolgreich auszuführen, sind wir auf eine bestimmte Abfolge von Methodenaufrufen angewiesen, wobei ein Aufruf vom vorherigen abhängt und so weiter. Die Küche kann das Essen nicht zubereiten, wenn der Kellner die Bestellung nicht geschrieben und an die Küche geschickt hat. Die Facade-Klasse stellt dieorderFood Aufgabe dem Client zur Verfügung, um sie zu vereinfachen und jeglichen Missbrauch aufgrund der vorhandenen Komplexität zu vermeiden.

class Order_Facade
{
private:
Waiter_Subsystem1waiter;
Kitchen_Subsystem2 kitchen;
public:
void orderFood()
{
cout << "A series of interdependent calls on various subsystems:\n";
waiter.writeOrder();
waiter.sendToKitchen();
kitchen.prepareFood();
kitchen.callWaiter();
waiter.serveCustomer();
kitchen.washDishes();
}
};

Hauptfunktion
Die Hauptfunktion arbeitet als Client (wie die vorherigen Anleitungen). Es ist so einfach für den Client, eine Facade-Instanz zu erstellen und eine Funktion aufzurufen, um seine Arbeit zu erledigen.

int main(int argc, char *argv)
{
// Simple for the client 
// no need to know the order or the 
// dependencies among various subsystems.
Order_Facade facade;
facade.orderFood();return 0;
}// Output
// A series of interdependent calls on various subsystems:
// Waiter writes client's order
// Send order to kitchen
// Cook food
// Call Waiter
// Yeeei customer is served!!!
// Wash the dishes

Es gibt einige Vorteile für die Verwendung des Facade-Musters und einige Punkte, die zu beachten sind, wenn Facade angegangen werden soll.

• Facade definiert eine übergeordnete Schnittstelle, die das Subsystem einfacher zu verwenden macht, indem sie ein kompliziertes Subsystem umhüllt.
• Das reduziert die Lernkurve, die notwendig ist, um das Subsystem erfolgreich zu nutzen.
• Es fördert auch die Entkopplung des Subsystems von seinen potentiell vielen Clients.
• Auf der anderen Seite, wenn die Fassade der einzige Zugangspunkt für das Subsystem ist, wird es die Funktionen und die Flexibilität einschränken, die „Power-User“ benötigen.

Der nächste Blog wird ein kurzer Leitfaden für das Observer-Designmuster sein. Es handelt sich um ein Verhaltensmuster, das Sie unbedingt in Ihrem Wissensschatz haben sollten. Vergessen Sie nicht, meinen Blog-Beitrag zu liken/klatschen und meinem Account zu folgen. Das gibt mir die Genugtuung, dass ich einigen anderen Entwicklern geholfen habe und spornt mich an, weiter zu schreiben. Wenn es ein bestimmtes Entwurfsmuster gibt, über das Sie etwas lernen möchten, dann lassen Sie es mich wissen, damit ich es Ihnen in Zukunft zur Verfügung stellen kann.

Weitere Kurzanleitungen zu Entwurfsmustern:

1. Entwurfsmuster – Eine Kurzanleitung zu Abstract Factory.
2. Entwurfsmuster – Eine Kurzanleitung zu Bridge Pattern.
3. Design Patterns – Eine Kurzanleitung zu Builder Pattern.
4. Design Patterns – Eine Kurzanleitung zu Decorator Pattern.
5. Design Patterns – Eine Kurzanleitung zu Facade Pattern.
6. Design Patterns – Eine Kurzanleitung zu Observer Pattern.
7. Design Patterns – Eine Kurzanleitung zu Singleton Pattern.