Шаблони дизайну - Швидкий посібник з фасадом.

Шаблон фасаду часто потрібен, коли існує велика кількість взаємозалежних класів або через те, що частини коду недоступні. Він використовується як камуфляж для покриття складнощів великої системи і тому забезпечує простий інтерфейс для клієнта. Іншими словами, це клас обгортки, який використовується для приховування деталей реалізації.

Візерунок фасаду класифікується як структурна конструкція. Цей шаблон дизайну стосується складу класів та об'єктів. Структурні структури створення класів використовують спадкування для складання інтерфейсів. Структурні об'єкти-шаблони визначають способи складання об'єктів для отримання нової функціональності. [за шаблонами дизайну пояснено просто]

Зображення вище - ідеальний приклад фасадної картини. Клієнт у ресторані замовляє їжу з меню, яке, мабуть, описано в пів рядку. Замовлення йде на кухню, а їжа повертається через деякий час. Просто! Замовник не хоче знати, хто буде різати м'ясо, наскільки довго воно буде готуватися і хто буде потім мити посуд. Замовник просто хоче з'їсти смачну страву, яка відповідає очікуванням. Тому меню служить фасадом, щоб полегшити замовника, уникаючи складностей, що надходять з кухні або навіть завдань, які офіціант покладає в рамках цього процесу.

Крок 1 - Ключові слова

Визначення ключових слів - секретний рецепт у цій серії швидких посібників. Цей метод допоміг мені по-справжньому зрозуміти шаблони дизайну, важко кодувати їх на увазі і зрозуміти відмінності між іншими моделями дизайну.

  1. Спрощення. Це мета цієї схеми дизайну. Спростіть складну систему.
  2. Обмеження: спрощення часто відбувається із «священною вартістю», обмеженням. Спрощуючи код, ми обмежуємо клієнтів від несанкціонованого доступу. Тому це заважає їм робити помилки, які важко було б сприймати у складній підсистемі.

Існує компроміс між спрощенням та обмеженням. Надмірне спрощення системи означає, що розробник занадто обмежений, тому менше свободи, ніж потрібно, що не завжди є доброю справою. Недостатнє спрощення візерунка фасаду означає, що є занадто багато свободи, що робить шаблон фасаду неактуальним. Пошук тонкого балансу - це те, що робить хороший, корисний та ефективний малюнок фасаду.

Крок 2 - Діаграма

Діаграма також базується на наведеному прикладі. Для спрощення цієї діаграми ми можемо розділити на три частини.

  1. Клієнт: Клієнт у цьому прикладі - замовник ресторану, який хоче замовити їжу.
  2. Фасад: Його завдання полягає в тому, щоб забезпечити клієнту більш спрощений доступ до численних взаємозалежних підсистем, які вважаються складними. У цьому прикладі для замовлення їжі клієнтом знадобиться серія ретельно секвенованих викликів методів двох різних підсистем (Офіціант і Кухня).
  3. Підсистеми: підсистеми приховані від клієнта. Вони також можуть бути недоступними для клієнта. Клієнт не може поспілкуватися з будь-якою з підсистем, де проста зміна коду може виявитися фатальною або навіть зламати інші невідомі частини самої системи. У такому сценарії офіціант і кухня повинні виконати ряд завдань. Завдання підсистеми іноді залежить від іншого завдання. Наприклад, кухня не може готувати їжу, якщо офіціант не доставить замовлення на кухню. Офіціант не може обслуговувати замовника, якщо їжа не готується.

Крок 3 - Код за прикладом

Я б запропонував скопіювати клас коду за класом з мого сховища git “Andreas Poyias” або фрагментів нижче (у наданому порядку) та вставити його в будь-який із доступних онлайн-редакторів C ++, як c ++ shell, jdoodle, onlineGDB та запустити це для спостереження за результатами. Потім прочитайте коментарі чи опис нижче. Не витрачайте час, ретельно читаючи його (це означає одну хвилину, не менше і не більше).

Підсистеми

У цьому прикладі дві підсистеми є Waiter_Subsystem1іKitchen_Subsystem2. На перший погляд, кожна підсистема здається незалежною, оскільки вони можуть виконувати певні завдання індивідуально. Але це правда?

#include 
використання простору імен std;
клас Waiter_Subsystem1
{
загальнодоступний:
  void writeOrder () {cout << "Офіціант пише замовлення клієнта \ n";}
  void sendToKitchen () {cout << "Надіслати замовлення на кухню \ n";}
  void serveCustomer () {cout << "Клієнт Yeeei обслуговується !!! \ n";}
};
клас Kitchen_Subsystem2
{
загальнодоступний:
    пустота приготовленняFood () {cout << "Готувати їжу \ n";}
    void callWaiter () {cout << "Офіціант виклику \ n";}
    void washingDives () {cout << "Мити посуд \ n";}
};

Фасад: У цьому прикладі клас "Фасад" - про замовлення їжі в ресторані. Щоб успішно виконати замовлення на їжу, ми покладаємось на певну послідовність викликів методу, і один виклик залежить від попереднього тощо. Кухня не може готувати їжу, якщо офіціант не напише замовлення і відправить його на кухню. Клас Facade надає клієнту завдання theorderFood, щоб спростити його та уникнути будь-яких зловживань через складність, яка існує.

клас Order_Facade
{
приватний:
    Waiter_Subsystem1waiter;
    Кухня_система2 кухня;
загальнодоступний:
    недійсне замовленняFood ()
    {
        cout << "Серія взаємозалежних дзвінків у різних підсистемах: \ n";
        waiter.writeOrder ();
        офіціант.sendToKitchen ();
        кухня.приготуватиFood ();
        kitchen.callWaiter ();
        офіціант.резерв. Замовник ();
        кухня.мити посуд ();
    }
};

Основна функція
Основна функція працює як клієнт (те саме, що і попередні посібники). Клієнт так легко може створити екземпляр Facade і викликати функцію, щоб виконувати свою роботу.

int main (int argc, char * argv [])
{
    // Простий для клієнта
    // не потрібно знати наказ чи то
    // залежності між різними підсистемами.
    Замовлення_Фасад фасаду;
    facade.orderFood ();
повернути 0;
}
// Вихід
// Серія взаємозалежних дзвінків у різних підсистемах:
// Офіціант пише замовлення клієнта
// Надіслати замовлення на кухню
//  Готувати їжу
// Виклик офіціанта
// Клієнт Yeeei обслуговується !!!
//  Мити посуд

Існує кілька переваг щодо використання фасадної схеми та кілька моментів, які слід зазначити, коли потрібно підійти до фасаду.

  • Фасад визначає інтерфейс вищого рівня, який робить підсистему простішою у використанні, обертаючи складну підсистему.
  • Це зменшує криву навчання, необхідну для успішного використання підсистеми.
  • Він також сприяє від'єднанню підсистеми від потенційно багатьох клієнтів.
  • З іншого боку, якщо Фасад є єдиною точкою доступу для підсистеми, це обмежить функції та гнучкість, які можуть знадобитися «споживачам енергії».

Наступний блог - це короткий посібник щодо схеми дизайну Observer. Це поведінковий зразок, необхідний для вашого сховища знань. Не забудьте сподобатися / заплескати мій пост у блозі та слідкуйте за моїм обліковим записом. Це дає мені задоволення, що я допоміг деяким колегам-розробникам і змусив мене продовжувати писати. Якщо є конкретна модель дизайну, про яку ви хотіли б дізнатися, то повідомте мене, щоб я могла надавати її вам у майбутньому.

Інші швидкі посібники щодо моделей дизайну:

  1. Шаблони дизайну - Швидкий посібник по абстрактній фабриці.
  2. Шаблони дизайну - Швидкий посібник з мостового візерунка.
  3. Шаблони дизайну - Швидкий посібник щодо шаблону для будівельників.
  4. Шаблони дизайну - Швидкий посібник з візерунком декораторів.
  5. Шаблони дизайну - Швидкий посібник по візерунку фасадів.
  6. Шаблони дизайну - Швидкий посібник із шаблону спостерігача.
  7. Шаблони дизайну - Швидкий посібник по Singleton Pattern.