Проблемні предметні області

1. У реальному світі багато де застосовується структура паттерна Фасад. Гарним прикладом служить будь-який ресторан швидкого харчування, де необхідно просто підійти до каси і замовити їжу, а подальша структура кафе, як правило, не цікавить. Але в кафе також є офіс, у який теж можливо прийти, і звернутися до нього по «вузькому» інтерфейсу (наприклад, стати постійним клієнтом). Таким чином, ресторан містить дві мінімально залежні одну від одної підсистеми, що разом складаються в одну велику систему (рис. 5.21).

Рис. 5.21. Схема проблемної предметної області

Спроектувати і потім побудувати величезний додаток «відразу» дуже складно. Архітектори вирішили цю задачу розбивкою програми на більш дрібні підсистеми, це дозволяє будувати якусь одну частину програми не відволікаючись на інші її аспекти, а після побудови переходити до написання наступної підсистеми. А якщо будувати системи не залежними друг від друга можна одержати «безпечну» замінність її компонентів або цілих підсистем, також, одержуючи незалежну підсистему, можливо використовувати її повторно в інших проектах, і нарешті якщо в команді програмістів більше однієї людини – це дасть змогу доручити кожному(або декільком) з них написати окремі підсистеми, а потім просто зібрати їх у цілий додаток.

З іншого боку, щоб скористатися незнайомою підсистемою необхідно перечитувати чимало документації про цю структуру, і розбиратися як нею користуватися. Якщо декілька людей працюють з подібною складною системою, навряд чи є потреба кожному з них вивчити особливості її функціонування у всіх подробицях. Замість того, щоб витрачати час кожного працівника групи, краще буде доручити написати підпрограми, що забезпечують іншим співробітникам єдиний інтерфейс для роботи із системою. Той, кому доручать це завдання, повинний буде визначити, як інші члени групи мають намір використовувати систему і який APІ (прикладний програмний інтерфейс) буде оптимальним. Потім йому буде потрібно визначити новий клас (або класи), що надає необхідний інтерфейс. Це дозволить іншим членам групи просто звертатися до даного інтерфейсу, замість того, щоб витрачати час на докладне вивчення складної системи (рис. 5.22).

Рис. 5.22. Додавання до архітектури програмної системи фасадного інтерфейсу

Розбиття на підсистеми полегшує проектування складної системи в цілому. Загальна мета всякого проектування – звести до мінімуму залежність підсистем одна від одної і обмін інформацією між ними. Один із способів рішення цієї задачі – введення об’єкта фасад, що надає єдиний спрощений інтерфейс до більш складних системних засобів. Це і є шаблон проектування Facade. Він спрощує використання складної системи, окремої частини системи або забезпечує звертання до системи деяким специфічним чином. Є складна система, і необхідно використовувати тільки якусь її частину (окремий модуль). У результаті застосування шаблона Facade одержимо нову, більш просту у використанні систему, що буде точно відповідати нашим потребам. Основна частина роботи як і раніше буде виконуватися вихідною системою. Шаблон Facade надає лише колекцію методів, простих у розумінні і використанні. Ці методи звертаються до основної системи для реалізації знову визначених функцій зовнішньої системи.

при використанні паттерна Фасад створюється клас, який спрощує й уніфікує набір більш складних класів, які утворять якусь підсистему. На відміну від багатьох інших паттернів, Фасад відносно простий; у ньому немає запаморочливих абстракцій, в яких приходиться подовгу розбиратися. Але від цього він не стає менш корисним. Визначення чітко і недвозначно говорить, що метою фасаду є спрощення роботи з підсистемою за рахунок використання спрощеного інтерфейсу. Це добре видно з діаграми класів паттерну (рис. 5.23).

Рис. 5.23. Діаграма класів паттерна Фасад

Поиск по сайту: