Тема 5. Структурні паттерни

Структурні паттерни розглядають питання про компонуванні системи на основі класів і об’єктів. При цьому можуть використовуватися такі механізми [18]:

- спадкування, коли базовий клас визначає інтерфейс, а підкласи – реалізацію. Структури на основі успадкування виходять статичними;

- композиція, коли структури будуються шляхом об’єднання об’єктів деяких класів. Композиція дозволяє отримувати структури, які можна змінювати під час виконання.

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

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

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

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

Структурні паттерни поділяються на [11]:

- паттерни рівня класу;

- паттерни рівня об’єктів.

Паттерн Міст (Bridge)

Призначення. Паттерн Міст – це структурний паттерн, що відокремлює абстракцію від її реалізації так, щоб те і інше можна було змінювати незалежно [24].

Частота використання.

Мотивація застосування. Паттерн передбачає створення двох ієрархій. Перша ієрархія визначає інтерфейс абстракції, який доступний користувачеві. Усі деталі реалізації, пов’язані з особливостями середовища ховаються в другій ієрархії. У даному випадку під реалізацією розуміють ті об’єкти, в яких абстрактний і похідні від нього класи використовують для реалізації своїх функцій, а не ті класи, що називаються конкретними і є похідними від абстрактного класу (рис. 5.1).

Рис. 5.1. Схема розподілу абстракції та реалізації

Відділення означає забезпечення незалежної поведінки елементів, або, принаймні, явна вказівка на те, що між ними існують деякі відносини. Абстракція – це концептуальне представлення про те, як різні елементи зв’язані один з одним. Brіdge – один із самих важких для розуміння паттернів. До деякої міри це викликано тим, що він є дуже могутнім і часто застосовується у всіляких ситуаціях. Крім того, він суперечить розповсюдженій практиці застосування механізму спадкування для реалізації спеціальних випадків. У системі можуть існувати класи, відносини між якими будуються у відповідності з наступною об’єктно-орієнтованої ієрархією: абстрактний базовий клас оголошує інтерфейс, а конкретні підкласи реалізують його потрібним чином. Якщо для деякої абстракції можливо декілька реалізацій, то зазвичай застосовують спадкування. Абстрактний клас визначає інтерфейс абстракції, а його конкретні підкласи по-різному реалізують його. Але такий підхід не завжди володіє достатньою гнучкістю. Спадкування жорстко прив’язує реалізацію до абстракції, що ускладнює незалежну модифікацію, розширення і повторне використання абстракції від її реалізації. Такий підхід є стандартним в ООП, однак, йому властиві наступні недоліки [25]:

- система, побудована на основі спадкування, є статичною. Реалізація жорстко прив’язана до інтерфейсу. Змінити реалізацію об’єкта деякого типу в процесі виконання програми вже неможливо;

- система стає важко підтримуваною, якщо кількість споріднених похідних класів стає великим;

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

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

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

Паттерн Міст необхідно використовувати, коли:

- необхідно уникнути постійної прив’язки абстракції до реалізації. Так, наприклад, буває, коли реалізацію необхідно вибирати під час виконання програми;

- і абстракції, і реалізації повинні розширюватися новими підкласами;

- необхідно комбінувати різні абстракції і реалізації та змінювати їх незалежно;

- зміни в реалізації абстракції не повинні позначатися на клієнтах, тобто клієнтський код не повинен перекомпілюватися;

- кількість класів починає швидко рости – це ознака того, що ієрархію слід розділити на дві частини;

- необхідно створити графічні або віконні системи, що повинні працювати на різних платформах.

Проблемна предметна область. Наприклад, необхідно запрограмувати новий ергономічний універсальний пульт ДУ для телевізора [10]. Відомо, що в програмуванні необхідно використовувати принципи ООП – хоча архітектура базується на одній абстракції, у ній буде задіяна безліч реалізацій – по одній для кожної моделі телевізора (рис. 5.2). У реалізації (рис. 5.2) може змінюватися тільки реалізація, але не інтерфейс.

Рис. 5.2. Діаграма класів для абстракції предметної області

Інтерфейс пульта не буде визначений в остаточному вигляді з першого разу. Більш того, передбачається, що продукт буде удосконалюватися з одержанням даних зворотного зв’язку від користувачів. Таким чином, мінятися будуть як пульти, так і телевізори. Абстрагувавши користувальницький інтерфейс, маємо можливість зміни реалізації для численних моделей телевізорів, що належать користувачам. Але, як очікується, абстракція теж буде змінюватися згодом на підставі отриманих відкликань користувачів. Як же створити об’єктно-орієнтовану архітектуру, що дозволяла б змінювати як реалізацію, так і абстракцію? Паттерн Міст дозволяє змінювати реалізацію й абстракцію, для чого вони розміщаються в двох різних ієрархіях класів (рис. 5.3).

Рис. 5.3. Предметна область в термінах паттерна Міст

Загальна структура паттерну Bridge показана на рисунку 5.4.

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