Steg 1 – Nyckelord
Definition av nyckelord är det hemliga receptet i den här serien av snabbguider. Den här metoden hjälpte mig att verkligen förstå designmönstren, att hårdkoda dem i mitt huvud och att förstå skillnaderna mellan andra designmönster.
- Förenkling: Detta är målet med det här designmönstret. Att förenkla ett komplicerat system.
- Restriktion: Förenklingen kommer ofta med en ”helig kostnad”, en begränsning. Genom att förenkla koden begränsar vi klienterna från obehörig åtkomst. Därför hindrar det dem från att göra misstag som skulle vara svåra att uppfatta i ett komplicerat delsystem.
Det finns en avvägning mellan förenkling och begränsning. Att förenkla ett system för mycket innebär att utvecklaren blir alltför begränsad, alltså mindre frihet än nödvändigt vilket inte alltid är bra. Att underförenkla Facade-mönstret innebär att det finns för mycket frihet vilket gör Facade-mönstret irrelevant. Att hitta den fina balansen är det som gör ett bra, användbart och effektivt Facade-mönster.
Steg 2 – Diagram
Diagrammet är också baserat på det givna exemplet. För att förenkla diagrammet kan vi dela upp det i tre delar.
- Klient: Klienten i det här exemplet är kunden på en restaurang som vill beställa mat.
- Fasad: Det är dess uppgift att ge klienten förenklad tillgång till ett stort antal av varandra beroende delsystem som anses vara komplicerade. I det här exemplet skulle kundens beställning av mat kräva en rad noggrant ordnade metodanrop från två olika delsystem (servitör och kök).
- Delsystem: Undersystemen är dolda för klienten. De kan också vara otillgängliga för klienten. Klienten kan inte mixtra med något av delsystemen där en enkel kodändring kan visa sig vara dödlig eller till och med bryta andra okända delar av själva systemet. I detta scenario måste servitören och köket utföra en rad uppgifter. Ett delsystems uppgift är ibland beroende av en annan uppgift. Köket kan till exempel inte förbereda maten om inte servitören för in beställningen till köket. Servitören kan inte servera kunden om maten inte är tillagad.
Steg 3 – Kod genom exempel
Jag föreslår att du kopierar koden klass för klass från mitt git-arkiv ”Andreas Poyias” eller utdragen nedan (i den ordning som anges) och klistrar in den i någon av de C++-redigerare som finns tillgängliga på nätet, t.ex. c++shell, jdoodle, onlineGDB, och kör den för att observera resultatet. Läs sedan kommentarerna eller beskrivningen nedan. Ta god tid på dig och läs den noggrant (det betyder en minut, inte mindre och inte mer).
Subsystem
I det här exemplet är de två subsystemen Waiter_Subsystem1och Kitchen_Subsystem2. Vid en första anblick verkar varje delsystem vara oberoende eftersom de kan utföra vissa uppgifter individuellt. Men är detta sant?
#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: I det här exemplet handlar Facade-klassen om matbeställningar på restaurangen. För att utföra en matbeställning på ett framgångsrikt sätt är vi beroende av en viss sekvens av metodanrop och ett anrop är beroende av det föregående och så vidare. Köket kan inte förbereda maten om inte servitören skriver beställningen och skickar den till köket. Facadeklassen tillhandahållerorderFood uppgiften till klienten för att förenkla den och undvika missbruk på grund av den komplexitet som finns.
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();
}
};
Huvudfunktion
Huvudfunktionen fungerar som klient(samma som de föregående guiderna). Det är så enkelt för klienten att kunna skapa en Facade-instans och anropa en funktion för att göra sitt jobb.
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
Det finns några fördelar med att använda Facade-mönstret och några punkter att notera när man ska närma sig Facade.
- Facade definierar ett gränssnitt på högre nivå som gör delsystemet enklare att använda genom att omsluta ett komplicerat delsystem.
- Detta minskar den inlärningskurva som krävs för att framgångsrikt utnyttja delsystemet.
- Det främjar också en frikoppling av delsystemet från dess potentiellt många klienter.
- Å andra sidan, om Facade är den enda åtkomstpunkten för delsystemet kommer det att begränsa de funktioner och den flexibilitet som ”power users” kan behöva.
Nästa blogg kommer att vara en snabbguide till designmönstret Observer. Det är ett beteendemönster som är ett måste i ditt kunskapsförråd. Glöm inte att gilla/klappa mitt blogginlägg och följa mitt konto. Detta för att ge mig tillfredsställelse över att jag hjälpt några andra utvecklare och för att pusha mig att fortsätta skriva. Om det finns ett specifikt designmönster som du vill lära dig om så låt mig veta så att jag kan tillhandahålla det för dig i framtiden.
Andra snabbguider om designmönster:
- Designmönster – En snabbguide till abstrakt fabrik.
- Designmönster – En snabbguide till bryggmönster.
- Designmönster – En snabbguide till Builder-mönster.
- Designmönster – En snabbguide till Decorator-mönster.
- Designmönster – En snabbguide till Facade-mönster.
- Designmönster – En snabbguide till Observer-mönster.
- Designmönster – En snabbguide till Singleton-mönster.