Vaihe 1 – Avainsanat
Avainsanojen määrittely on tämän pikaopassarjan salainen resepti. Tämä menetelmä auttoi minua todella ymmärtämään suunnittelumalleja, kovakoodaamaan ne mieleeni ja ymmärtämään erot muiden suunnittelumallien välillä.
- Yksinkertaistaminen: Tämä on tämän suunnittelumallin tavoite. Yksinkertaistaa monimutkaista järjestelmää.
- Rajoittaminen: Yksinkertaistamiseen liittyy usein ”pyhä hinta”, rajoitus. Yksinkertaistamalla koodia rajoitamme asiakkaita luvattomalta käytöltä. Siksi se estää heitä tekemästä virheitä, joita olisi vaikea havaita monimutkaisessa osajärjestelmässä.
Yksinkertaistamisen ja rajoittamisen välillä on kompromissi. Järjestelmän liiallinen yksinkertaistaminen tarkoittaa sitä, että kehittäjää rajoitetaan liikaa, siis vähemmän vapautta kuin on tarpeen, mikä ei aina ole hyvä asia. Facade-kuvion ali-yksinkertaistaminen tarkoittaa, että vapautta on liikaa, mikä tekee Facade-kuviosta merkityksettömän. Hienon tasapainon löytäminen tekee hyvästä, hyödyllisestä ja tehokkaasta Facade-kuviosta.
Vaihe 2 – Kaavio
Kaavio perustuu myös annettuun esimerkkiin. Kaavion yksinkertaistamiseksi voimme jakaa sen kolmeen osaan.
- Client: Asiakas tässä esimerkissä on ravintolan asiakas, joka haluaa tilata ruokaa.
- Julkisivu: Sen tehtävänä on pystyä tarjoamaan asiakkaalle yksinkertaisempi pääsy kohti lukuisia toisistaan riippuvaisia osajärjestelmiä, joita pidetään monimutkaisina. Tässä esimerkissä asiakkaan ruokatilaus edellyttäisi kahden eri osajärjestelmän (Tarjoilija ja Keittiö) huolellisesti peräkkäisten metodikutsujen sarjaa.
- Osajärjestelmät: Alijärjestelmät ovat piilossa asiakkaalta. Ne saattavat myös olla asiakkaan ulottumattomissa. Asiakas ei voi näpelöidä mitään osajärjestelmiä, joissa pelkkä koodimuutos voi osoittautua kohtalokkaaksi tai jopa rikkoa muita tuntemattomia osia itse järjestelmästä. Tässä skenaariossa tarjoilijan ja keittiön on suoritettava joukko tehtäviä. Osajärjestelmän tehtävä on joskus riippuvainen toisen tehtävästä. Keittiö ei esimerkiksi voi valmistaa ruokaa, jos tarjoilija ei tuo tilausta keittiöön. Tarjoilija ei voi palvella asiakasta, jos ruoka ei ole kypsennetty.
Vaihe 3 – Koodi esimerkin mukaan
Esittäisin, että kopioit koodin luokka kerrallaan Git-arkistostani ”Andreas Poyias” tai alla olevista pätkistä (annetussa järjestyksessä) ja liität sen mihin tahansa saatavilla olevaan online-C++-editoriin, kuten c++shell, jdoodle , onlineGDB, ja suoritat sen havainnoidaksesi tulostetta. Lue sitten alla olevat kommentit tai kuvaus. Ota aikaa ja lue se perusteellisesti (se tarkoittaa yhtä minuuttia, ei vähempää eikä enempää).
Alajärjestelmät
Tässä esimerkissä kaksi alajärjestelmää ovat Waiter_Subsystem1jaKitchen_Subsystem2. Ensisilmäyksellä kumpikin osajärjestelmä vaikuttaa itsenäiseltä, koska ne voivat tehdä tiettyjä tehtäviä erikseen. Mutta onko tämä totta?
#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: Tässä esimerkissä Facade-luokka käsittelee ravintolan ruokatilauksia. Ruokatilauksen onnistunut suorittaminen perustuu tiettyyn metodikutsujen sekvenssiin, ja yksi kutsu on riippuvainen edellisestä ja niin edelleen. Keittiö, ei voi valmistaa ruokaa, jos tarjoilija ei kirjoita tilausta ja lähetä sitä keittiöön. Facade-luokka tarjoaaorderFood tehtävän asiakkaalle yksinkertaistaakseen sitä ja välttääkseen väärinkäytöksiä, jotka johtuvat olemassa olevasta monimutkaisuudesta.
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();
}
};
Pääfunktio
Pääfunktio toimii asiakkaana(sama kuin edellisissä oppaissa). Asiakkaan on niin helppoa pystyä luomaan Facade-instanssi ja kutsua funktiota tekemään tehtävänsä.
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
Facade-mallin käytöstä on muutamia etuja ja muutama huomioitava seikka, kun Facadea halutaan lähestyä.
- Facade määrittelee korkeamman tason rajapinnan, joka tekee osajärjestelmästä helpommin käyttökelpoisen käärimällä monimutkaisen osajärjestelmän.
- Tämä vähentää oppimiskäyrää, joka on tarpeen osajärjestelmän menestyksekkääseen hyödyntämiseen.
- Se myös edistää osajärjestelmän irrottamista sen mahdollisesti monista asiakkaista.
- Toisaalta, jos Facade on osajärjestelmän ainoa käyttöliittymä, se rajoittaa ”tehokäyttäjien” tarvitsemia ominaisuuksia ja joustavuutta.
Seuraavaan blogiin on tulossa pikaopas Observer-suunnittelumallin käyttöön. Se on käyttäytymismalli, joka on pakko saada tietovarastoosi. Älä unohda tykätä/taputtaa blogipostaustani ja seurata tiliäni. Tämä antaa minulle tyydytystä siitä, että olen auttanut joitakin kollegoja kehittäjät ja ajaa minua jatkamaan kirjoittamista. Jos on jokin tietty suunnittelumalli, josta haluaisit oppia, niin kerro minulle, niin voin tarjota sen sinulle tulevaisuudessa.
Muut pikaoppaat suunnittelumalleista:
- Suunnittelumallit – pikaopas abstraktiin tehtaaseen.
- Suunnittelumallit – pikaopas siltamalliin.
- Design Patterns – A quick guide to Builder Pattern.
- Design Patterns – A quick guide to Decorator Pattern.
- Design Patterns – A quick guide to Facade Pattern.
- Design Patterns – A quick guide to Observer Pattern.
- Design Patterns – A quick guide to Singleton Pattern.