Design Patterns – Una guida rapida al pattern Facade.

Anche il diagramma è basato sull’esempio dato. Per semplificare questo diagramma possiamo separarlo in tre parti.

1. Cliente: Il cliente in questo esempio è il cliente di un ristorante che vuole ordinare del cibo.
2. Facciata: Il suo compito è quello di poter fornire al cliente un accesso più semplificato verso numerosi sottosistemi interdipendenti che sono considerati complicati. In questo esempio, l’ordine di cibo di un cliente richiederebbe una serie di chiamate a metodi accuratamente sequenziali di due diversi sottosistemi (Cameriere e Cucina).
3. Sottosistemi: I sottosistemi sono nascosti al cliente. Potrebbero anche non essere accessibili al client. Il cliente non può giocherellare con nessuno dei sottosistemi dove un semplice cambio di codice può rivelarsi fatale o addirittura rompere altre parti sconosciute del sistema stesso. In questo scenario, il cameriere e la cucina devono svolgere una serie di compiti. Il compito di un sottosistema a volte dipende dal compito di un altro. Per esempio, la cucina non può preparare il cibo se il cameriere non porta l’ordine alla cucina. Il cameriere non può servire il cliente se il cibo non è cotto.

Step 3 – Codice per esempio

Suggerisco di copiare il codice classe per classe dal mio repository git “Andreas Poyias” o i frammenti qui sotto (nell’ordine previsto) e incollarlo in uno qualsiasi degli editor C++ disponibili online come c++shell, jdoodle, onlineGDB ed eseguirlo per osservare l’output. Poi leggete i commenti o la descrizione qui sotto. Prendetevi il vostro tempo, leggendolo a fondo (questo significa un minuto, non meno e non più).

Sottosistemi

In questo esempio, i due sottosistemi sono il Waiter_Subsystem1e ilKitchen_Subsystem2. A prima vista, ogni sottosistema sembra essere indipendente, dato che possono fare certi compiti individualmente. Ma è vero?

#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 questo esempio, la classe Facade riguarda le ordinazioni di cibo nel ristorante. Per eseguire con successo un ordine di cibo, ci si basa su una specifica sequenza di chiamate di metodi e una chiamata dipende dalla precedente e così via. La cucina non può preparare il cibo se il cameriere non scrive l’ordine e lo invia alla cucina. La classe Facade fornisce ilorderFood compito al client per semplificarlo ed evitare qualsiasi abuso dovuto alla complessità esistente.

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

Funzione principale
La funzione principale opera come il client (la stessa delle guide precedenti). È così facile per il cliente essere in grado di creare un’istanza Facade e chiamare una funzione per fare il suo lavoro.

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

Ci sono alcuni benefici per l’uso del pattern Facade e alcuni punti da notare quando Facade deve essere approcciato.

• Facade definisce un’interfaccia di livello superiore che rende il sottosistema più facile da usare avvolgendo un sottosistema complicato.
• Questo riduce la curva di apprendimento necessaria per sfruttare con successo il sottosistema.
• Promuove anche il disaccoppiamento del sottosistema dai suoi potenzialmente molti client.
• D’altra parte, se Facade è l’unico punto di accesso al sottosistema, limiterà le caratteristiche e la flessibilità di cui i “power user” potrebbero aver bisogno.

Il prossimo blog sarà una rapida guida al design pattern Observer. Si tratta di un pattern comportamentale che non può mancare nel vostro archivio di conoscenze. Non dimenticate di mettere “mi piace” e “applaudire” al mio blog-post e di seguire il mio account. Questo per darmi la soddisfazione di aver aiutato alcuni colleghi sviluppatori e spingermi a continuare a scrivere. Se c’è un design pattern specifico che vorresti imparare allora fammelo sapere così posso fornirtelo in futuro.

Altre guide rapide sui design pattern:

1. Design Patterns – Una guida rapida a Abstract Factory.
2. Design Patterns – Una guida rapida a Bridge Pattern.
3. Design Patterns – Una guida rapida a Builder Pattern.
4. Design Patterns – Una guida rapida a Decorator Pattern.
5. Design Patterns – Una guida rapida a Facade Pattern.
6. Design Patterns – Una guida rapida a Observer Pattern.
7. Design Patterns – Una guida rapida a Singleton Pattern.