Designmønstre - En hurtig guide til Fasademønster.

Facademønster er ofte nødvendigt, når der er et stort antal indbyrdes afhængige klasser, eller fordi dele af koden ikke er tilgængelig. Det bruges som en camouflage til at dække kompleksiteten i et stort system og giver derfor en enkel grænseflade til klienten. Med andre ord er det en indpakningsklasse, der bruges til at skjule implementeringsdetaljerne.

Fasademønster klassificeres som et strukturelt designmønster. Dette designmønster handler om klasse- og objektsammensætning. Strukturelle klasseskabningsmønstre bruger arv til at komponere grænseflader. Strukturelle objektmønstre definerer måder at komponere objekter for at få ny funktionalitet. [af designmønstre forklaret ganske enkelt]

Billedet ovenfor er det perfekte eksempel på et facademønster. En kunde i en restaurant bestiller mad fra menuen, som sandsynligvis er beskrevet i en halv linje. Ordren går til køkkenet, og maden kommer tilbage efter et stykke tid. Enkel! Kunden vil ikke vide, hvem der vil skære kødet i hvor længe det skal koges, og hvem der skal vaske opvasken bagefter. Kunden vil bare spise et velsmagende måltid, der lever op til forventningerne. Derfor fungerer menuen som facade for at gøre det lettere for kunden ved at undgå kompleksiteterne, der kommer fra køkkenet eller endda de opgaver, som tjeneren tildeles gennem denne proces.

Trin 1 - Nøgleord

Definition af nøgleord er den hemmelige opskrift i denne serie af hurtigguider. Denne metode hjalp mig med virkelig at forstå designmønstre, hardkode dem i mit sind og forstå forskellene mellem andre designmønstre.

  1. Forenkling: Dette er målet med dette designmønster. Forenkle et kompliceret system.
  2. Begrænsning: Forenkling kommer ofte med en ”hellig pris”, begrænsning. Ved at forenkle koden begrænser vi klienter fra uautoriseret adgang. Derfor forhindrer det dem i at begå fejl, der ville være vanskelige at opfattes i et kompliceret delsystem.

Der er en afveksling mellem forenkling og begrænsning. Overforenkling af et system betyder, at udvikleren er overbegrænset, derfor mindre frihed end nødvendigt, hvilket ikke altid er en god ting. Underforenkling af facademønster betyder, at der er for meget frihed, der gør facademønsteret irrelevant. At finde den fine balance er det, der gør et godt, nyttigt og effektivt facademønster.

Trin 2 - Diagram

Diagrammet er også baseret på det givne eksempel. For at forenkle dette diagram kan vi opdele i tre stykker.

  1. Klient: Klienten i dette eksempel er kunden på en restaurant, der ønsker at bestille mad.
  2. Facade: Dets job er at være i stand til at give kunden en mere forenklet adgang til adskillige indbyrdes afhængige delsystemer, der betragtes som komplicerede. I dette eksempel kræver en klients fødevareordre en række omhyggeligt sekventerede metodekald fra to forskellige undersystemer (Tjener og køkken).
  3. Delsystemer: Delsystemerne er skjult for klienten. De er muligvis heller ikke tilgængelige for klienten. Klienten kan ikke fikle med nogen af ​​delsystemerne, hvor en simpel kodeændring kan vise sig at være dødelig eller endda ødelægge andre ukendte dele af selve systemet. I dette scenarie skal tjeneren og køkkenet udføre en række opgaver. Et undersystems opgave er undertiden afhængig af anothers-opgaven. F.eks. Kan køkkenet ikke tilberede maden, hvis tjeneren ikke bringer ordren til køkkenet. Tjeneren kan ikke betjene kunden, hvis maden ikke koges.

Trin 3 - Kode ved eksempel

Jeg vil foreslå at kopiere kodeklassen efter klasse fra mit git-arkiv "Andreas Poyias" eller uddragene nedenfor (i den angivne rækkefølge) og indsætte den i en hvilken som helst af de tilgængelige online C ++ -redaktører som c ++ shell, jdoodle, onlineGDB og køre det for at observere output. Læs derefter kommentarer eller beskrivelse nedenfor. Brug din tid på at læse den grundigt (det betyder et minut, ikke mindre og ikke mere).

delsystemer

I dette eksempel er de to undersystemer Waiter_Subsystem1 og the Kitchen_Subsystem2. Ved første øjekast synes hvert delsystem at være uafhængigt, da de kan udføre visse opgaver individuelt. Men er det sandt?

# inkluder 
ved hjælp af navneområde std;
klasse Waiter_Subsystem1
{
offentlig:
  void writeOrder () {cout << "Tjeneren skriver klientens ordre \ n";}
  void sendToKitchen () {cout << "Send ordre til køkken \ n";}
  void serveCustomer () {cout << "Yeeei-kunde serveres !!! \ n";}
};
klasse Kitchen_Subsystem2
{
offentlig:
    void PreparFood () {cout << "Cook mad \ n";}
    void callWaiter () {cout << "Ring tjeneren \ n";}
    void washDishes () {cout << "Vask opvasken \ n";}
};

Facade: I dette eksempel handler Facade-klassen om madordrer i restauranten. For at udføre en madbestilling med succes, er vi afhængige af en bestemt række af metodekald, og et opkald er afhængig af det foregående osv. Køkkenet kan ikke tilberede maden, hvis tjeneren ikke skriver ordren og sender den til køkkenet. Facade-klassen giver theorderFood-opgaven til klienten til at forenkle den og undgå misbrug på grund af den eksisterende kompleksitet.

klasse Order_Facade
{
privat:
    Waiter_Subsystem1waiter;
    Kitchen_Subsystem2 køkken;
offentlig:
    void orderMad ()
    {
        cout << "En række indbyrdes afhængige opfordringer til forskellige undersystemer: \ n";
        waiter.writeOrder ();
        waiter.sendToKitchen ();
        kitchen.prepareFood ();
        kitchen.callWaiter ();
        waiter.serveCustomer ();
        kitchen.washDishes ();
    }
};

Hovedfunktion
Hovedfunktionen fungerer som klient (det samme som de tidligere guider). Det er så let for klienten at være i stand til at oprette en Facade-instans og kalde en funktion for at udføre sit job.

int main (int argc, char * argv [])
{
    // Enkelt for klienten
    // ingen grund til at kende ordren eller
    // afhængigheder mellem forskellige delsystemer.
    Order_Facade facade;
    facade.orderFood ();
retur 0;
}
// Output
// En række indbyrdes afhængige opfordringer til forskellige delsystemer:
// Tjeneren skriver kundens ordre
// Send ordre til køkkenet
//  Lav mad
// Ring til tjeneren
// Yeeei kunde serveres !!!
//  Tag opvasken

Der er et par fordele ved brugen af ​​Facade-mønster og et par punkter, der skal bemærkes, når Facade skal kontaktes.

  • Facade definerer en grænseflade på højere niveau, der gør delsystemet lettere at bruge ved at indpakke et kompliceret delsystem.
  • Dette reducerer den læringskurve, der er nødvendig for at kunne udnytte undersystemet med succes.
  • Det fremmer også afkobling af delsystemet fra dets potentielt mange klienter.
  • På den anden side, hvis facaden er det eneste adgangspunkt for delsystemet, vil det begrænse de funktioner og fleksibilitet, som "strømbrugere" muligvis har brug for.

Den næste blog vil være en hurtig guide til Observer designmønster. Det er et adfærdsmønster, der er et must for dit videnlager. Glem ikke at lide / klappe mit blog-indlæg og følge min konto. Dette er for at give mig den tilfredshed, at jeg hjalp nogle medudviklere og presser mig til at fortsætte med at skrive. Hvis der er et specifikt designmønster, som du gerne vil lære om, så fortæl mig det, så jeg kan give det til dig i fremtiden.

Andre hurtigguider om designmønstre:

  1. Designmønstre - En hurtig guide til Abstract Factory.
  2. Designmønstre - En hurtig guide til Bridge Pattern.
  3. Designmønstre - En hurtig guide til Builder Pattern.
  4. Designmønstre - En hurtig guide til Decoratormønster.
  5. Designmønstre - En hurtig guide til Fasademønster.
  6. Designmønstre - En hurtig guide til observatørmønster.
  7. Designmønstre - En hurtig guide til Singleton-mønster.