Ontwerppatronen - Een korte handleiding voor gevelpatronen.

Gevelpatroon is vaak nodig wanneer er een groot aantal onderling afhankelijke klassen is of omdat delen van de code niet beschikbaar zijn. Het wordt gebruikt als camouflage om de complexiteit van een groot systeem te dekken en biedt daarom een ​​eenvoudige interface voor de client. Met andere woorden, het is een wrapper-klasse die wordt gebruikt om de implementatiedetails te verbergen.

Gevelpatroon is geclassificeerd als een structureel ontwerppatroon. Bij deze ontwerppatronen draait alles om de samenstelling van Klasse en Object. Structurele patronen voor het maken van klassen gebruiken overerving om interfaces samen te stellen. Structurele objectpatronen definiëren manieren om objecten samen te stellen om nieuwe functionaliteit te verkrijgen. [door Design Patterns eenvoudig uitgelegd]

De afbeelding hierboven is het perfecte voorbeeld van een gevelpatroon. Een klant in een restaurant bestelt eten van het menu, dat waarschijnlijk in een halve regel wordt beschreven. De bestelling gaat naar de keuken en het eten komt na een tijdje terug. Eenvoudig! De klant wil niet weten wie het vlees snijdt, hoe lang het wordt gekookt en wie daarna de afwas gaat doen. De klant wil gewoon een smakelijke maaltijd eten die aan de verwachtingen voldoet. Daarom dient het menu als de gevel om het de klant gemakkelijker te maken door de complexiteit uit de keuken of zelfs de taken die de ober via dit proces wordt toegewezen te vermijden.

Stap 1 - Zoekwoorden

Het definiëren van trefwoorden is het geheime recept in deze serie beknopte handleidingen. Deze methode heeft me geholpen de ontwerppatronen echt te begrijpen, ze hard te coderen en de verschillen tussen andere ontwerppatronen te begrijpen.

  1. Vereenvoudiging: dit is het doel van dit ontwerppatroon. Vereenvoudig een ingewikkeld systeem.
  2. Beperking: Vereenvoudiging komt vaak met een 'heilige kost', beperking. Door de code te vereenvoudigen, beperken we klanten van ongeautoriseerde toegang. Daarom voorkomt het dat ze fouten maken die moeilijk te zien zijn in een ingewikkeld subsysteem.

Er is een wisselwerking tussen vereenvoudiging en beperking. Een systeem te sterk vereenvoudigen betekent dat de ontwikkelaar te beperkt is, dus minder vrijheid dan nodig is, wat niet altijd een goede zaak is. Een te vereenvoudigde gevelpatroon betekent dat er te veel vrijheid is waardoor het gevelpatroon niet relevant is. Het vinden van de juiste balans is wat een goed, nuttig en effectief gevelpatroon maakt.

Stap 2 - Diagram

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

  1. Klant: de klant in dit voorbeeld is de klant van een restaurant dat eten wil bestellen.
  2. Gevel: het is zijn taak om de klant meer vereenvoudigde toegang te bieden tot tal van onderling afhankelijke subsystemen die als ingewikkeld worden beschouwd. In dit voorbeeld zou de voedselbestelling van een klant een reeks zorgvuldig opeenvolgende methodeaanroepen van twee verschillende subsystemen (Kelner en Keuken) vereisen.
  3. Subsystemen: de subsystemen zijn verborgen voor de client. Ze zijn mogelijk ook niet toegankelijk voor de client. De client kan met geen van de subsystemen spelen waar een eenvoudige codewijziging fataal kan blijken of zelfs andere onbekende delen van het systeem zelf kan breken. In dit scenario moeten de ober en de keuken een reeks taken uitvoeren. De taak van een subsysteem is soms afhankelijk van de anothers-taak. De keuken kan bijvoorbeeld geen eten bereiden als de ober de bestelling niet naar de keuken brengt. De ober kan de klant niet bedienen als het eten niet gaar is.

Stap 3 - Codeer als voorbeeld

Ik zou willen voorstellen om de code klasse per klasse te kopiëren uit mijn git-repository “Andreas Poyias” of de onderstaande fragmenten (in de aangegeven volgorde) en deze in een van de beschikbare online C ++ editors te plakken, zoals c ++ shell, jdoodle, onlineGDB en uitvoeren het om de uitvoer te observeren. Lees dan de opmerkingen of beschrijving hieronder. Neem de tijd om het grondig te lezen (dat betekent één minuut, niet minder en niet meer).

subsystemen

In dit voorbeeld zijn de twee subsystemen Waiter_Subsystem1 en theKitchen_Subsystem2. Op het eerste gezicht lijkt elk subsysteem onafhankelijk te zijn, omdat ze bepaalde taken afzonderlijk kunnen uitvoeren. Maar is dit waar?

# include 
namespace std; gebruiken;
klasse Waiter_Subsystem1
{
openbaar:
  void writeOrder () {cout << "Ober schrijft bestelling klant \ n";}
  void sendToKitchen () {cout << "Bestelling naar keuken verzenden \ n";}
  void serveCustomer () {cout << "Yeeei klant wordt bediend !!! \ n";}
};
klasse Kitchen_Subsystem2
{
openbaar:
    void prepareFood () {cout << "Cook food \ n";}
    void callWaiter () {cout << "Call Waiter \ n";}
    void washDishes () {cout << "Afwassen \ n";}
};

Gevel: In dit voorbeeld gaat de klasse Gevel over etenbestellingen in het restaurant. Om een ​​voedselbestelling succesvol uit te voeren, vertrouwen we op een specifieke reeks methodeaanroepen en is één oproep afhankelijk van de vorige, enzovoort. De keuken kan het eten niet bereiden als de ober de bestelling niet schrijft en naar de keuken stuurt. De klasse Facade biedt de opdracht orderFood aan de client om deze te vereenvoudigen en misbruik door de bestaande complexiteit te voorkomen.

klasse Order_Facade
{
privaat:
    Waiter_Subsystem1waiter;
    Kitchen_Subsystem2 keuken;
openbaar:
    void orderFood ()
    {
        cout << "Een reeks onderling afhankelijke oproepen op verschillende subsystemen: \ n";
        waiter.writeOrder ();
        waiter.sendToKitchen ();
        kitchen.prepareFood ();
        kitchen.callWaiter ();
        waiter.serveCustomer ();
        kitchen.washDishes ();
    }
};

Hoofdfunctie
De hoofdfunctie werkt als de client (hetzelfde als de vorige handleidingen). Het is zo gemakkelijk voor de klant om een ​​Facade-instantie te maken en een functie aan te roepen om zijn werk te doen.

int main (int argc, char * argv [])
{
    // Eenvoudig voor de klant
    // het is niet nodig om de bestelling of de
    // afhankelijkheden tussen verschillende subsystemen.
    Order_Facade gevel;
    facade.orderFood ();
terugkeer 0;
}
// Uitgang
// Een reeks onderling afhankelijke oproepen op verschillende subsystemen:
// Ober schrijft bestelling van klant
// Stuur bestelling naar keuken
//  Eten koken
// Bel ober
// Yeeei-klant wordt bediend !!!
//  Doe de afwas

Er zijn een paar voordelen voor het gebruik van het gevelpatroon en een paar aandachtspunten wanneer de gevel moet worden benaderd.

  • Facade definieert een interface op een hoger niveau die het subsysteem gebruiksvriendelijker maakt door een ingewikkeld subsysteem in te pakken.
  • Dit vermindert de leercurve die nodig is om succesvol gebruik te maken van het subsysteem.
  • Het bevordert ook de ontkoppeling van het subsysteem van zijn potentieel veel clients.
  • Aan de andere kant, als de Facade het enige toegangspunt voor het subsysteem is, beperkt dit de functies en flexibiliteit die "krachtige gebruikers" nodig kunnen hebben.

De volgende blog is een beknopte handleiding voor het ontwerppatroon van de waarnemer. Het is een gedragspatroon dat een must is voor uw kennisrepository. Vergeet niet mijn blogpost leuk te vinden / te klappen en mijn account te volgen. Dit is om mij de voldoening te geven dat ik sommige mede-ontwikkelaars heb geholpen en me aanspoort om te blijven schrijven. Als er een specifiek ontwerppatroon is waarover u meer wilt weten, laat het me dan weten zodat ik het u in de toekomst kan bieden.

Andere snelgidsen over ontwerppatronen:

  1. Design Patterns - Een korte handleiding voor Abstract Factory.
  2. Design Patterns - Een korte handleiding voor Bridge Pattern.
  3. Design Patterns - Een korte handleiding voor Builder Pattern.
  4. Design Patterns - Een korte handleiding voor Decorator Pattern.
  5. Ontwerppatronen - Een korte handleiding voor gevelpatroon.
  6. Ontwerppatronen - Een korte handleiding voor het waarnemerspatroon.
  7. Design Patterns - Een korte handleiding voor Singleton Pattern.