1

Лекція №18 (SE)

Тема: Класифікація шаблонів проектування програмного забезпечення

План

1. Архітектура ПЗ
2. Передумови розробки шаблонів(патернів)
3. Типи шаблонів

Архітектура програмного забезпечення - це структура програми або

обчислювальної системи, яка включає програмні компоненти, видимі зовні
властивості цих компонентів, а також відносини між ними. Основною ідеєю
напрямку програмної архітектури є ідея зниження складності системи шляхом
абстракції і розмежування повноважень.
Те, які ключові цілі має система, описується за допомогою сценаріїв, як
нефункціональні вимоги до системи, або також відомі як атрибути якості, що
визначають, як буде вести себе система. Атрибути якості системи включають в
себе відмовостійкість, збереження зворотної сумісності, розширюваність,
надійність, придатність до сервісного обслуговування, доступність, безпека,
зручність використання тощо. З точки зору користувача, програмна
архітектура дає напрям для руху і вирішення завдань, пов'язаних зі
спеціальністю кожного такого користувача, наприклад, розробника ПЗ, групи
підтримки ПЗ, фахівця із супроводу ПЗ, фахівця з розгортання ПЗ, тестера, а
також кінцевих користувачів.
Архітектура - це принцип організації компонентів усередині системи:
їх кількість, якість, інтерфейси і протоколи взаємодії.
Від архітектури залежить ціна на підтримку і розробку нових функцій,
трудовитрати на побудову цілої системи. Тобто формально від архітектури
залежить один із важливих параметрів розробки - собівартість. А побічно ще і
можливість повторного використання коду, а разом з ним і зменшення
трудовитрат на кожну подальшу розробку.
Будь-який програмний код має взаємозалежності одних частин від інших.
Класи вимагають наявності інших класів, одні функції викликають інші і т.д. У
міру зростання будь-якого проекту взаємозалежностей стає все більше і більше.
Вимоги до проекту змінюються, розробники іноді вносять швидкі й не завжди
вдалі рішення. Якщо залежностями грамотно не управляти, то проект неминуче
почне загнивати. Код стає складніше розуміти, він частіше ламається, стає менш
гнучким і важким для повторного використання. У результаті швидкість
розробки падає, проект чинить опір змінам, і ось вже серед розробників звучать
заклики «Давайте все переробимо! Наступного разу ми зробимо супер-
 2

архітектуру». Найбільш поширені ознаки поганого або загниваючого в плані

коду проекту:
Закритість - система відчайдушно чинить опір змінам, неможливо сказати,
скільки часу займе реалізація тієї або іншої функціональності, тому що зміни,
швидше за все, торкнуться багатьох компонентів системи. Через це вносити
зміни стає занадто дорого, тому що вони вимагають багато часу.
Нестійкість, крихкість - система ламається в непередбачених місцях, хоча
зміни, були проведені до цього, зламані компоненти явно не зачіпали.
Нерухомість або монолітність - система побудована таким чином і
характер залежностей такий, що використовувати будь-які компоненти окремо
від інших не представляється можливим.
В’язкість - код проекту такий, що зробити що-небудь неправильно
набагато простіше, ніж зробити щось правильно.
Невиправдані повторення - розмір проекту набагато більший, ніж він міг
би бути, якби абстракції застосовувалися частіше.
Надмірна складність - проект містить рішення, користь від яких
неочевидна, вони приховують реальну суть системи, ускладнюючи її розуміння і
розвиток.
Як зробити кращу архітектуру?
За довгі роки розумні люди виробили деякі основоположні принципи ООП,
дотримання яких дозволяє створювати кращу архітектуру:
Висока зчепленість коду - код, відповідальний за яку-небудь одну
функціональність, повинен бути зосереджений в одному місці.
Низька зв’язаність коду - класи повинні мати мінімальну залежність від
інших класів.
Вказуй, а не питай - класи містять дані і методи для оперування цими
даними. Класи не повинні цікавитися даними з інших класів.
Не розмовляй з незнайомцями - класи повинні знати тільки про своїх
безпосередніх сусідів. Чим менше знає клас про існування інших класів або
інтерфейсів - тим більш стійкий код.
Всі ці рекомендації спрямовані на те, щоб постаратися розвести класи по
сторонах, зосередити сильні взаємозв'язки в одному місці і провести чіткі
розмежувальні лінії в коді.
Повторне використання коду (англ. code reuse) - методологія
проектування комп'ютерних та інших систем, що полягає в тому, що система
(комп'ютерна програма, програмний модуль) частково або повністю повинна
складатися з частин, написаних раніше компонентів і / або частин іншої системи.
Повторне використання - основна методологія, яка застосовується для
скорочення трудовитрат при розробці складних систем.
 3

Найпоширеніший випадок повторного використання коду - бібліотеки

програм. Бібліотеки надають загальну досить універсальну функціональність,
яка покриває обрану предметну область. Приклади: Бібліотека функцій для
роботи з комплексними числами, бібліотека функцій для роботи з 3Д-графікою,
бібліотека для використання протоколу TCP / IP, бібліотека для роботи з базами
даних.
Повторне використання коду за межами одного проекту практично
неможливо, якщо у вас немає розробленого проектного каркаса [framework]. У
різних проектах різні набори сервісів, що і ускладнює повторне використання
об'єкта. Що таке framework?
Коли людина вирішує якесь завдання багато разів поспіль, вона вчиться
вирішувати її швидко і ефективно! З точки зору web-програмування, framework-
система (CMF-система) це платформа, що дозволяє вирішувати завдання, які
постійно виникають при створенні інтернет-додатків. Не варто думати, що CMF-
система - це просто набір модулів для вирішення різнотипних завдань, яких в
Інтернеті безліч. Framework-система це щось більше. Це:
• Термінологія, яка дозволяє розробникам говорити лаконічно про дуже
складні речі;
• Набір архітектурних стандартів, які система накладає на інтернет-
додатки. Це знімає з розробників необхідність придумувати все з нуля і дозволяє
більш ефективно використовувати код повторно;
• Модулі для вирішення завдань «першої необхідності», що дозволяють
почати розробку з порожнього місця, не винаходячи нічого свого.
Розглядаючи поняття framework-системи, не можна обійти стороною,
поняття системи управління контентом. Дуже часто поняття CMF (Content
Management Framework) плутають з поняттям CMS (Content Management
System). Це невірно, тому що це принципово різні речі.
CMF-системи не можна порівнювати з CMS-системами! Це головне
правило, яке дуже часто порушують розробники при обговоренні питань
пов'язаних з розробкою та використанням CMF-систем. CMF і CMS різні
поняття, незважаючи на їх схожість.
CMS-система - це набір модулів для швидкого створення сайтів. На
відміну від CMF, CMS-система - це є завершений продукт, який орієнтований, в
першу чергу, не на програмістів, а на користувачів, не знайомих з складностями
створення інтернет-додатків. CMS-система (дуже часто її називають «движок
сайту») дозволяє за лічені години створити сайт або портал, який складається з
обмеженого набору готових модулів (новини, гостьова книга, форум). В
більшості своїй, CMS-системи створюються без урахування їх подальшого
зростання. Підсумок - відсутність жорсткої внутрішньої архітектури системи. Це
 4

істотно ускладнює процес супроводження проекту.

Якщо вам достатньо можливостей CMS-системи, то, швидше за все, Ви
будете задоволені. Однак якщо перед Вами постане питання про зміну дизайну
або розширення можливостей програми, то, в більшості випадків, Вам
доведеться вдатися за допомогою до кваліфікованих програмістів. І, можливо,
навіть їм буде не просто розібратися в цій CMS-системі.
Вищесказане відноситься до «чистих» CMS-систем. Тобто до CMS- систем,
які написані з нуля на порожньому місці. На щастя, ніхто не заважає
використовувати вигоди обох типів систем. Останнім часом в Інтернеті почали
з'являтися CMF / CMS-системи. Ці системи являють собою CMS-систему,
створену на фундаменті framework.
Якщо CMS-система являє собою закінчений продукт, то CMF-система - це
набір інструментів, за допомогою яких, можна створити абсолютно будь-який
продукт, зокрема і CMS-систему. Так як framework-система - це набір
інструментів, то для її використання потрібні програмісти, які можуть з цими
інструментами працювати. З цим пов'язаний ще один момент, характерний для
CMF - навчання персоналу для роботи з CMF-системою.
Продукти CMF-системи (додатки, написані на її основі) відрізняються
індивідуальністю та високим рівнем адаптації до конкретної ситуації, тому що
вони є програмними рішеннями, призначеними для вирішення конкретного кола
завдань у конкретному контексті. За допомогою CMF можна створювати будь-
які інтернет-додатки, починаючи гостьовими книгами, закінчуючи інтернет-
магазинами і веб-сервісами.
Патерни ООАП розрізняються ступенем деталізації і рівнем абстракції.
Пропонується наступна загальна класифікація патернів за категоріями їх
застосування:
• Архітектурні патерни
• Патерни проектування
• Патерни аналізу
• Патерни тестування
• Патерни реалізації
У сфері розробки програмних систем найбільше застосування отримали
патерни проектування GoF, деякі з них реалізовані в популярних середовищах
програмування. При цьому патерни проектування можуть бути представлені в
наочній формі за допомогою розглянутих позначень мови UML.
 5

Патерн проектування в контексті мови UML є параметризованою

кооперацію разом з описом базових принципів її використання.
При зображенні патерну використовується позначення параметризованої
кооперації мови UML (рис. 1), яка позначається пунктирним еліпсом. У правий
верхній кут еліпса вбудований пунктирний прямокутник, в якому перераховані
параметри кооперації, яка представляє той чи інший патерн.

Рис. 1. Зображення патерна в формі параметризованої кооперації

Шаблони проектування (патерн, design pattern) - це багато разів
застосовувана архітектурна конструкція, що надає рішення для загальної
проблеми проектування в рамках конкретного контексту й описує значимість
цього рішення.
Патерн не є закінченим зразком проекту, який може бути прямо
перетворений в код, скоріше це опис або зразок для того, як вирішити завдання,
таким чином, щоб це можна було використовувати в різних ситуаціях. Об'єктно-
орієнтовані шаблони часто показують відносини і взаємодії між класами або
об'єктами, без визначення того, які кінцеві класи чи об'єкти додатки будуть
використовуватися. Алгоритми не розглядаються як шаблони, так як вони
вирішують завдання обчислення, а не проектування.
У 1970-і роки архітектор Крістофер Олександр склав набір шаблонів
проектування. В області архітектури ця ідея не отримала такого розвитку, як
пізніше в області програмної розробки. Згідно з визначенням Крістофера
Олександра: "Кожне типове рішення описує якусь повторювану проблему і ключ
до її розгадки, причому таким чином, що ви можете користуватися цим ключем
багаторазово, жодного разу не прийшовши до одного й того ж результату" .
У 1991 році Ерік Гамма у співробітництві з Річардом Хелмом, Ральфом
Джонсоном і Джоном Вліссідсом публікує книгу Design Patterns - Elements of
Reusable Object-Oriented Software. У цій книзі описані 23 шаблона проектування.
ож команда авторів цієї книги відома громадськості під назвою Банда чотирьох
(Gang of Four, часто скорочується до GoF). Саме ця книга стала причиною
зростання популярності шаблонів проектування.
Іншим видатним діячем у галузі проектування програмних систем, який
підтримав використання патернів, є Мартін Фаулер, який написав книгу
"Архітектура корпоративних програмних додатків".
 6

Як зазначив Мартін Фаулер у своїй книзі "збираючись скористатися типовими

рішеннями, не забувайте, що вони тільки відправна точка, а не пункт
призначення".
У книзі Крейга Лармана "Застосування UML і шаблонів проектування"
описано 9 шаблонів GRASP (General Responsibility Assignment Software Patterns,
загальні зразки розподілу обов'язків) - патернів, використовуваних в об'єктно-
орієнтованому проектуванні для вирішення спільних завдань за призначенням
обов'язків класам і об'єктам.
Головна користь кожного окремого шаблону полягає в тому, що він описує
рішення цілого класу абстрактних проблем. Правильно сформульований шаблон
проектування дозволяє, відшукавши вдале рішення, користуватися ним знову і
знову.
Шаблони можуть пропагувати і погані стилі розробки додатків, і часто
сліпо застосовуються.
Також на сьогоднішній день існує ряд інших шаблонів:
• Carrier Rider Mapper, надання доступу до збереженої інформації;
• аналітичні шаблони, описують основний підхід для складання вимог для
програмного забезпечення (requirement analysis) до початку самого процесу
програмної розробки;
• комунікаційні шаблони, описують процес спілкування між окремими
учасниками / співробітниками організації;
• організаційні шаблони, описують організаційну ієрархію підприємства /
фірми;
• Анти-патерни (Anti-Design-Patterns) описують як не слід поступати при
розробці програм, показуючи характерні помилки в дизайні і в реалізації.

Таблица 14.1. Полный список паттернов проектирования GoF

Название
№ Перевод Назначение паттерна
паттерна
1 Abstract Factory Абстрактная Предоставляет интерфейс для создания
фабрика множества связанных между собой или
независимых объектов, конкретные
классы которых неизвестны.
2 Adapter(синоним Адаптер Преобразует существующий интерфейс
- Wrapper) (Обертка) класса в другой интерфейс, который
понятен клиентам. При этом
обеспечивает совместную работу классов,
невозможную без данного паттерна из-за
несовместимости интерфейсов.
3 Bridge Мост Отделяет абстракцию класса от его
реализации, благодаря чему появляется
 7

возможность независимо изменять то и

другое.
4 Builder Строитель Отделяет создание сложного объекта от
его представления, позволяя использовать
один и тот же процесс разработки для
создания различных представлений.
5 Chain of Цепочка Позволяет избежать жесткой зависимости
Responsibility обязанностей отправителя запроса от его получателя,
при этом объекты-получатели
связываются в цепочку, а запрос
передается по цепочке, пока какой-то
объект его не обработает.
6 Command Команда Инкапсулирует запрос в виде объекта,
обеспечивая параметризацию клиентов
типом запроса, установление очередности
запросов, протоколирование запросов и
отмену выполнения операций.
7 Composite Компоновщик Группирует объекты в иерархические
структуры для представления отношений
типа "часть-целое", что позволяет
клиентам работать с единичными
объектами так же, как с группами
объектов.
8 Decorator Декоратор Применяется для расширения имеющейся
функциональности и является
альтернативой порождению подклассов
на основе динамического назначения
объектам новых операций.
9 Facade Фасад Предоставляет единый интерфейс к
множеству операций или интерфейсов в
системе на основе унифицированного
интерфейса для облегчения работы с
системой.
10 Factory Method Фабричный Определяет интерфейс для разработки
метод объектов, при этом объекты данного
класса могут быть созданы его
подклассами.
11 Flyweight Приспособленец Использует принцип разделения для
эффективной поддержки большого числа
мелких объектов.
12 Interpreter Интерпретатор Для заданного языка определяет
представление его грамматики на основе
интерпретатора предложений языка,
 8

использующего это представление.

13 Iterator Итератор Дает возможность последовательно
перебрать все элементы составного
объекта, не раскрывая его внутреннего
представления.
14 Mediator Посредник Определяет объект, в котором
инкапсулировано знание о том, как
взаимодействуют объекты из некоторого
множества. Способствует уменьшению
числа связей между объектами, позволяя
им работать без явных ссылок друг на
друга и независимо изменять схему
взаимодействия.
15 Memento Хранитель Дает возможность получить и сохранить
во внешней памяти внутреннее состояние
объекта, чтобы позже объект можно было
восстановить точно в таком же
состоянии, не нарушая принципа
инкапсуляции.
16 Observer Наблюдатель Специфицирует зависимость типа "один
ко многим" между различными
объектами, так что при изменении
состояния одного объекта все зависящие
от него получают извещение и
автоматически обновляются.
17 Prototype Прототип Описывает виды создаваемых объектов с
помощью прототипа, что позволяет
создавать новые объекты путем
копирования этого прототипа.
18 Proxy Заместитель Подменяет выбранный объект другим
объектом для управления контроля
доступа к исходному объекту.
19 Singleton Одиночка Для выбранного класса обеспечивает
выполнение требования единственности
экземпляра и предоставления к нему
полного доступа.
20 State Состояние Позволяет выбранному объекту
варьировать свое поведение при
изменении внутреннего состояния. При
этом создается впечатление, что
изменился класс объекта.
21 Strategy Стратегия Определяет множество алгоритмов,
инкапсулируя их все и позволяя
 9

подставлять один вместо другого. При

этом можно изменять алгоритм
независимо от клиента, который им
пользуется.
22 Template Method Шаблонный Определяет структуру алгоритма,
метод перераспределяя ответственность за
некоторые его шаги на подклассы. При
этом подклассы могут переопределять
шаги алгоритма, не меняя его общей
структуры.
23 Visitor Посетитель Позволяет определить новую операцию,
не меняя описаний классов, у объектов
которых она вызывается.
Розглянемо приклад, який ілюструє використання патерну Наблюдатель для
відстеження змін в таблиці БД та відображенні цих змін на діаграмах. Для
визначеності можна використовувати таблицю БД MS Access і дві діаграми -
кругову і Стовпчикові. Фрагмент відповідної діаграми класів містить 5 класів
(рис. 2).

Рис. 2. Конкретна реалізація патерна проектування Наблюдатель

https://ppt-online.org/178744
 10

https://yapro.ru/article/6518 - гарна архітектура

https://bool.dev/blog/detail/gof-design-patterns - шаблони проектування

АНТИ-ПАТЕРНИ
https://habr.com/ru/post/260227/
https://bool.dev/blog/detail/antipatterny-v-programmirovanii-i-proektirovanii-
arkhitektury