Etape 1 – Mots-clés
Définir des mots-clés est la recette secrète de cette série de guides rapides. Cette méthode m’a aidé à vraiment comprendre les design patterns, à les coder en dur dans mon esprit et à comprendre les différences entre les autres design patterns.
- Simplification : C’est l’objectif de ce design pattern. Simplifier un système compliqué.
- Restriction : La simplification s’accompagne souvent d’un « coût sacré », la restriction. En simplifiant le code, on restreint les clients d’un accès non autorisé. Par conséquent, cela les empêche de faire des erreurs qui seraient difficiles à percevoir dans un sous-système compliqué.
Il y a un compromis entre la simplification et la restriction. Sur-simplifier un système signifie que le développeur est sur-restrictionné, donc moins de liberté que nécessaire ce qui n’est pas toujours une bonne chose. Sous-simplifier le modèle Facade signifie qu’il y a trop de liberté, ce qui rend le modèle Facade non pertinent. Trouver le juste milieu est ce qui fait un bon, utile et efficace motif Facade.
Étape 2 – Diagramme
Le diagramme est également basé sur l’exemple donné. Pour simplifier ce diagramme, nous pouvons le séparer en trois parties.
- Client : Le client dans cet exemple est le client d’un restaurant qui veut commander de la nourriture.
- Façade : Son travail consiste à pouvoir fournir au client un accès plus simplifié vers de nombreux sous-systèmes interdépendants considérés comme compliqués. Dans cet exemple, la commande de nourriture d’un client nécessiterait une série d’appels de méthodes soigneusement séquencés de deux sous-systèmes différents (serveur et cuisine).
- Sous-systèmes : Les sous-systèmes sont cachés au client. Ils peuvent également ne pas être accessibles au client. Le client ne peut pas bricoler avec l’un des sous-systèmes où un simple changement de code peut s’avérer fatal ou même casser d’autres parties inconnues du système lui-même. Dans ce scénario, le serveur et la cuisine doivent accomplir une série de tâches. La tâche d’un sous-système dépend parfois de celle d’un autre. Par exemple, la cuisine ne peut pas préparer la nourriture si le serveur n’apporte pas la commande à la cuisine. Le serveur ne peut pas servir le client si la nourriture n’est pas cuite.
Etape 3 – Code par l’exemple
Je vous suggère de copier le code classe par classe de mon dépôt git « Andreas Poyias » ou les extraits ci-dessous (dans l’ordre fourni) et de le coller dans l’un des éditeurs C++ en ligne disponibles comme c++shell, jdoodle , onlineGDB et de l’exécuter pour observer la sortie. Lisez ensuite les commentaires ou la description ci-dessous. Prenez votre temps, en le lisant complètement (cela signifie une minute, pas moins et pas plus).
Sous-systèmes
Dans cet exemple, les deux sous-systèmes sont le Waiter_Subsystem1et leKitchen_Subsystem2. A première vue, chaque sous-système semble être indépendant car ils peuvent effectuer certaines tâches individuellement. Mais est-ce vrai ?
#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 : Dans cet exemple, la classe Facade concerne les commandes de nourriture dans le restaurant. Pour exécuter une commande de nourriture avec succès, nous nous appuyons sur une séquence spécifique d’appels de méthodes et un appel dépend du précédent et ainsi de suite. La cuisine ne peut pas préparer la nourriture si le serveur ne rédige pas la commande et ne l’envoie pas à la cuisine. La classe Facade fournit laorderFood tâche au client pour la simplifier et éviter toute mauvaise utilisation due à la complexité qui existe.
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();
}
};
Fonction principale
La fonction principale fonctionne comme le client(le même que les guides précédents). Il est si facile pour le client de pouvoir créer une instance de Facade et d’appeler une fonction pour faire son travail.
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
Il y a quelques avantages pour l’utilisation du pattern Facade et quelques points à noter quand Facade doit être approché.
- Facade définit une interface de niveau supérieur qui rend le sous-système plus facile à utiliser en enveloppant un sous-système compliqué.
- Cela réduit la courbe d’apprentissage nécessaire pour réussir à exploiter le sous-système.
- Cela favorise également le découplage du sous-système de ses potentiellement nombreux clients.
- D’un autre côté, si la Facade est le seul point d’accès au sous-système, elle limitera les fonctionnalités et la flexibilité dont les « power users » peuvent avoir besoin.
Le prochain blog sera un guide rapide du design pattern Observer. C’est un pattern comportemental qui est un must have à votre référentiel de connaissances. N’oubliez pas d’aimer/claquer mon blog-post et de suivre mon compte. Cela me donne la satisfaction d’avoir aidé des collègues développeurs et me pousse à continuer à écrire. S’il y a un design pattern spécifique que vous aimeriez apprendre, alors faites-le moi savoir afin que je puisse vous le fournir à l’avenir.
Autres guides rapides sur les design patterns:
- Design Patterns – Un guide rapide sur Abstract Factory.
- Design Patterns – Un guide rapide sur Bridge Pattern.
- Design Patterns – Un guide rapide du Builder Pattern.
- Design Patterns – Un guide rapide du Decorator Pattern.
- Design Patterns – Un guide rapide du Facade Pattern.
- Design Patterns – Un guide rapide du Observer Pattern.
- Design Patterns – Un guide rapide du Singleton Pattern.