Design Patterns – Een snelle gids voor Facade pattern.

Het diagram is ook gebaseerd op het gegeven voorbeeld. Om dit diagram te vereenvoudigen kunnen we het in drie stukken opsplitsen.

1. Client: De client in dit voorbeeld is de klant van een restaurant die eten wil bestellen.
2. Facade: De taak van de façade is om de cliënt een vereenvoudigde toegang te verschaffen tot talrijke, onderling afhankelijke subsystemen die als ingewikkeld worden beschouwd. In dit voorbeeld zou de bestelling van voedsel van een cliënt een reeks zorgvuldig opeenvolgende methode-aanroepen van twee verschillende subsystemen (Ober en Keuken) vereisen.
3. Subsystemen: De subsystemen zijn verborgen voor de cliënt. Ze kunnen ook niet toegankelijk zijn voor de client. De cliënt kan met geen van de subsystemen rommelen, waarbij een eenvoudige codewijziging fataal kan blijken te zijn of zelfs andere onbekende delen van het systeem zelf kan breken. In dit scenario moeten de kelner en de keuken een reeks taken uitvoeren. De taak van een subsysteem is soms afhankelijk van de taak van een ander. De keuken kan bijvoorbeeld het eten niet bereiden als de kelner de bestelling niet naar de keuken brengt. De ober kan de klant niet bedienen als het eten niet gaar is.

Stap 3 – Code door voorbeeld

Ik zou willen voorstellen om de code klasse voor klasse te kopiëren van mijn git repository “Andreas Poyias” of de onderstaande knipsels (in de gegeven volgorde) en deze in een van de beschikbare online C++ editors te plakken zoals c++shell, jdoodle , onlineGDB en voer het uit om de output te observeren. Lees dan het commentaar of de beschrijving hieronder. Neem de tijd, lees het grondig (dat betekent een minuut, niet minder en niet meer).

Subsystemen

In dit voorbeeld zijn de twee subsystemen de Waiter_Subsystem1 en deKitchen_Subsystem2. Op het eerste gezicht lijkt elk subsysteem onafhankelijk te zijn, aangezien zij bepaalde taken afzonderlijk kunnen uitvoeren. Maar is dat ook zo?

#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";}
};

Facade: In dit voorbeeld gaat de Facade-klasse over voedselbestellingen in het restaurant. Om een voedselbestelling met succes uit te voeren, zijn we afhankelijk van een specifieke opeenvolging van methode-aanroepen en de ene aanroep is afhankelijk van de vorige enzovoort. De keuken kan het eten niet bereiden als de kelner de bestelling niet schrijft en naar de keuken stuurt. De Facade klasse geeft deorderFood taak aan de client om het te vereenvoudigen en misbruik te voorkomen door de complexiteit die er is.

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();
}
};

Main functie
De main functie werkt als de client (hetzelfde als de vorige gidsen). Het is zo gemakkelijk voor de client om een Facade-instantie te kunnen maken en een functie aan te roepen om zijn werk te doen.

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

Er zijn een paar voordelen voor het gebruik van het Facade-patroon en een paar punten die moeten worden opgemerkt wanneer Facade moet worden benaderd.

• Facade definieert een interface op een hoger niveau die het subsysteem gemakkelijker te gebruiken maakt door een ingewikkeld subsysteem in te pakken.
• Dit vermindert de leercurve die nodig is om met succes gebruik te maken van het subsysteem.
• Het bevordert ook het ontkoppelen van het subsysteem van zijn potentieel vele clients.
• Aan de andere kant, als de Facade het enige toegangspunt is voor het subsysteem, zal het de functies en flexibiliteit beperken die “power users” nodig kunnen hebben.

De volgende blog zal een snelle gids zijn voor het Observer-ontwerppatroon. Het is een gedragspatroon dat je niet mag missen in je kennisbank. Vergeet niet om mijn blog-post te liken/clappen en mijn account te volgen. Dit is om me de voldoening te geven dat ik enkele mede ontwikkelaars heb geholpen en me te stimuleren om te blijven schrijven. Als er een specifiek ontwerppatroon is waar je meer over zou willen leren, laat het me dan weten zodat ik het in de toekomst voor je kan verzorgen.

Andere quick-guides over ontwerppatronen:

1. Design Patterns – A quick guide to Abstract Factory.
2. Design Patterns – A quick guide to Bridge Pattern.
3. Design Patterns – Een snelgids voor Builder Pattern.
4. Design Patterns – Een snelgids voor Decorator Pattern.
5. Design Patterns – Een snelgids voor Facade Pattern.
6. Design Patterns – Een snelgids voor Observer Pattern.
7. Design Patterns – Een snelgids voor Singleton Pattern.