Вступ в патерни

1. Вступ до патернів
проєктування
Використання UML при аналізі патернів проєктування
Викладач: Верещагін О.О.

2. Тези
- Патерн (шаблон) – завдання знову і знову виникає у нашій роботі, а застосування патерну, вирішує його
найкращим способом, хоч мілійон разів, нічого не вигадуючи знову.
- Структура патернів комфортно описується UML діаграмами.
- Патерни не прив'язуються до конкретної мови програмування.
- По програмі навчання, переважна більшість прикладів, зображена на мові С#.
- Чому на ній? – швидкість навчання збільшується в рази, а різниця між С++ та С# не значна.
- Щоб розпочати патерни, потрібно вивчити SOLID.
- Майже завжди, патерни виконують правила SOLID.
- Все будується навколо принципі розробки: DRY, KISS, SLAP, YAGNI.
- Широке використання патернів у програмуванні почалося з опису базових 23 шаблонів проєктування
«Банди чотирьох».
- Про патерни GRASP.

3. Принципи розробки
Принцип DRY (Don't Repeat Yourself) - не повторюйте один і той же код або функціональність у різних
частинах програмного забезпечення, складайте їх у модулі або класи, які можна повторно
використовувати.
Принцип KISS (Keep It Simple, Stupid) - робіть програмне забезпечення максимально простим та
зрозумілим, уникайте складних алгоритмів, які можуть зробити код важким для розуміння та підтримки.
Принцип SOLID - це п'ять принципів об'єктно-орієнтованого проектування, які допомагають
створювати більш гнучке, масштабоване та легко змінюване програмне забезпечення. SOLID:
S - Single Responsibility Principle (Принцип єдиної відповідальності)
O - Open/Closed Principle (Принцип відкритості/закритості)
L - Liskov Substitution Principle (Принцип заміщення Лісков)
I - Interface Segregation Principle (Принцип розділення інтерфейсу)
D - Dependency Inversion Principle (Принцип інверсії залежності)

4. Принципи розробки
Принцип YAGNI (You Aren't Gonna Need It) - не розробляйте функціональність, яку ви не використовуєте на
даний момент, не прогнозуйте майбутні вимоги і не переповнюйте програмне забезпечення зайвим
функціоналом.
Принцип SLAP (Single Level of Abstraction Principle) - це принцип проєктування програмного забезпечення,
який рекомендує, щоб кожна функція мала один рівень абстракції, тобто містив лише один рівень
деталізації.
Приклад: функція, яка зчитує дані з бази даних та форматує їх для відображення на сторінці
вебдодатку. Ця функція може мати два рівні абстракції:
1. Рівень зчитування даних з бази даних (нижній рівень абстракції)
2. Рівень форматування даних для відображення на сторінці веб-додатку (верхній рівень
абстракції)
Кожен з цих рівнів може бути окремою функцією з одним рівнем абстракції. Функція, яка зчитує дані з бази
даних, може повертати простий список об'єктів, а функція, яка форматує дані, може використовувати цей список
об'єктів та повертати готовий для відображення код HTML. Таким чином, кожна функція має один рівень
абстракції, що спрощує їх розуміння та підтримку в майбутньому.

5. Принципи розробки
GRASP (General Responsibility Assignment Software Patterns) - це набір патернів, які допомагають
проектувати ефективне та масштабоване програмне забезпечення.
High Cohesion - це принцип, який означає, що клас або модуль повинен мати одну, чітко визначену
відповідальність. Тобто, він повинен виконувати одну конкретну функцію або групу пов'язаних функцій.
Кожен елемент програми повинен відповідати тільки за один аспект роботи системи. Це допомагає
зробити код більш зрозумілим, легким для зміни та тестування.
Low Coupling - це принцип, який означає, що класи та модулі повинні бути малозв'язаними між
собою. Тобто, зміна в одному класі або модулі не повинна впливати на інші класи або модулі. Це
допомагає зробити систему більш гнучкою та легкою для змін.

6. _
_

7. _
_

8. _
_

9. _
_

10. Low Cohesion (BLUE), High Coupling (RED) – BAD
_

11. В основі є шаблон Фасад
_

12. Історія виникнення патернів п…
1966 рік - Крістофер Александер видав книгу "Notes on the Synthesis of Form", в якій він описав свої
дослідження про синтез форм.
1977 рік - Грид Хеддінг видав книгу "Building Large Scale, Maintainable, Ada Systems Using Object-
Oriented Techniques", в якій він описав свої дослідження про проектування програмних систем з
використанням об'єктно-орієнтованого підходу.
1987 рік - Еріх Ґамма та Річард Хелм написали дисертацію "Design Patterns: Abstraction and Reuse of
Object-Oriented Design", в якій вони описали поняття "паттерни проектування" і довели їх важливість у
проектуванні програмного забезпечення.
1994 рік - Еріх Ґамма, Річард Хелм, Ральф Джонсон та Джон Вліссідес опублікували книгу "Design
Patterns: Elements of Reusable Object-Oriented Software", в якій вони описали 23 основних паттерни
проектування та їх використання у реальних проектах.

13. _
_

14. Історія виникнення патернів п…
Наступним кроком став опис Мартіна Фаулера «Enterprise Patterns», де розкриваються типові рішення
при розробці корпоративних додатків, наприклад, робота з базами даних, транзакціями і т.п.
Джошуа Керієвські показав, як можна постійним рефакторингом, керуючись базовими принципами
ООП, забезпечити еволюцію коду, переміщаючи його від одного патерну до іншого залежно від вимог.
Після початку акцентування уваги на модульному тестуванні (Unit Testing) з’явилося поняття
тестування програмного коду. Усі патерни були переосмислені з позицій тестування. При цьому,
наприклад, виявилося, що патерн Singleton — це антипатерн, а Abstract Factory взагалі замінили IoC
(Inversion of Control).
Після виходу книги «xUnit Test Patterns» у 2008 році з’явилися декілька десятків патернів тестування.

15. Причини виникнення патернів проєктування
Наприкінці 80-х років XX століття у сфері розробки програмного забезпечення, зокрема, об’єктно-
орієнтованому проєктуванні, накопичилося багато різних і схожих за своєю сутністю, рішень. Ці рішення
вимагали систематизації, узагальнення на всілякі ситуації, і навіть доступного описання, що сприяло
розумінню їх спеціалістами, які раніше їх використовували. Таке впорядкування знань в об’єктно-
орієнтованому проєктуванні дозволило повторно використовувати готові і вже перевірені рішення, а не
знову і знову «винаходити велосипед».
Вирішення проблеми систематизації накопиченого досвіду в об’єктно-орієнтованому проєктуванні, а
також представлення його широкому колу розробників, які взяли на себе патерни проєктування.

16. Поняття патерну проєктування
У загальному сенсі, патерн є зразком вирішення певної задачі. Тому, це рішення можна
використовувати у різних ситуаціях.
Під патерном проєктування (design pattern) розумітимемо опис взаємодії об᾿єктів і класів,
адаптованих для вирішення спільного завдання проєктування у конкретному контексті.
Використання патернів дозволяє проектувальникам вирішувати проблеми, які вже були вирішені в
минулому, і розробляти програмне забезпечення більш ефективно та швидко.
Патерни проектування не є конкретними алгоритмами, але натомість є загальними принципами
та концепціями, які можуть бути використані для розв'язання специфічних проблем.
Патерни проектування забезпечують певний рівень стандартизації та консистентності в
програмному забезпеченні, що полегшує розуміння, підтримку та розширення системи.

17. Поняття патерну проєктування
Алгоритми процедурного програмування також є патернами, але не проєктування, а обчислень.
Оскільки вони вирішують не архітектурні, а обчислювальні завдання.
Також слід підкреслити відмінність патернів проєктування від ідіом. Ідіоми — це патерни, що описують
типові рішення конкретною мовою програмування, а патерни проєктування не залежать від вибору мови
(хоча їх реалізації, найчастіше, залежні від мови програмування).

18. Складові патернів
1. Назва є унікальним ідентифікатором патерну.
2. Завдання визначає ситуацію, у якій можна використовувати патерн.
3. Рішення завдання проєктування у вигляді патерну визначає загальні функції кожного елемента
дизайну і відносини між ними. При цьому слід підкреслити, що розглядається не конкретна, а загальна ситуація, оскільки патерн
проєктування — це шаблон, який може застосовуватися багаторазово для вирішення типового завдання у різних контекстах.
4. Результати представляють наслідки застосування патерну. Вони описують переваги і недоліки
обраного рішення, його наслідки, різні компроміси і варіації патерна.
Патерн — це загальний опис хорошого способу вирішення задачі
Антипатерн — це неправильне, часто повторюване, рішення, яке не рекомендується використовувати

19. Практичне застосування патернів проєктування
При розробці дизайну системи слід керуватися такими основними принципами:
■ Завжди формувати простий дизайн: із двох запропонованих рішень, як правило, найкращим є
те, що простіше.
■ Слабка залежність: дизайн модуля повинен бути таким, щоб у разі його модифікації залежні
фрагменти системи не вимагали, або майже не вимагали, змін.
Де патерни? А вони з'являються в ході проектування, точніше типові проблеми. Тоді і варто їх
застосовувати.
Викорстовувати лише ті патерни, які забезпечать простоту системи в цілому, адже надмірне
використання патернів, особливо в штучно створених ситуаціях – ускладнює систему та порушує 1
правило!.
Уніфікація при спілкуванні розробників та у документації!

20. Коли застосовувати ПП?
Одним із індикаторів поганого дизайну системи можуть бути наступні негативні явища у програмному
коді (code smell):
■ Дубляж коду: однаковий (або майже однаковий код) у різних частинах проєкту.
■ Довгі методи: підпрограми з великою кількістю кодових ліній.
■ Великі класи: часто, на один клас припадає дуже багато різнорідних функцій.
■ Заздрість: клас надмірно використовує методи іншого класу.
■ Порушення приватності: клас надмірно залежить від деталей реалізації іншого класу.
■ Порушення наслідування: клас перевизначає спосіб базового класу і навіть порушує його договір
(тобто, первісне призначення).
■ Лінивий клас: клас, який робить замало, тобто клас із недостатньою чи нецілісною
функціональністю.
■ Надмірна складність: примусове використання складних рішень, в яких простий дизайн був би
достатнім.
■ Надмірно довгі ідентифікатори: у тому числі використання довгих назв для позначення
залежностей, які мають бути неявними.

21. Класифікація патернів
Для повноти картини коротко розглянемо класифікацію усіх патернів ООАП:
1. Архітектурні патерни. Описують фундаментальні методи структурування програмних систем. Ці
патерни відносяться до рівня систем та підсистем, а не класів. Патерни цієї категорії систематизував та
описав К. Ларман.
2. Патерни проєктування. Описують структуру програмних систем у термінах класів. Найбільш
відомими в цій галузі є 23 патерни, описані в [GoF95].
3. Патерни аналізу. Подають загальні схеми організації процесу об᾿єктно-орієнтованого моделювання.
4. Патерни тестування. Визначають загальні схеми організації процесу тестування програмних систем.
5. Патерни реалізації. Описують шаблони, які використовуються для написання програмного коду

22. Класифікація патернів
1. Основні патерни (Fundamental Patterns). Представляють найважливіші фундаментальні патерни,
які активно використовуються іншими патернами.
2. Породжуючі патерни (Creational Patterns). Визначають способи створення об᾿єктів у системі.
3. Структурні патерни (Structural Patterns). Описують методи побудови складних структур із класів та
об᾿єктів.
4. Поведінкові патерни (Behavioral Patterns). Описують методи взаємодії між об᾿єктами.
5. Патерни паралельного програмування (Concurrency Patterns). Призначені для координування
паралельних операцій; вирішують такі проблеми: боротьба за ресурси і взаємоблокування.
6. Патерни MVC. Містить такі патерни як MVC (Model — View — Controller), MVP (Model — View —
Presenter) та ін.
7. Патерни корпоративних систем (Enterprise Patterns). Надають рішення для побудови та інтеграції
великих корпоративних програмних систем.

23. Класифікація патернів
У праці [GoF95] представлено 23 патерни проєктування. За своїм призначенням ці патерни
класифікуються так:
1. Породжуючі патерни (Creational Patterns). Абстрагують процес інстанціювання; роблять систему
незалежною від того, як у ній створюються, компонуються і представляються об᾿єкти.
2. Структурні патерни (Structural Patterns). Вирішують питання про створення з класів та об’єктів
великих структур.
3. Поведінкові патерни (Behavioral Patterns). Розподіляють обов᾿язки між об᾿єктами; описують
методи їх взаємодії.

24. UML + ПП
В переважній більшості ПП, ми будем використовувати діаграму класів.
Швидко згадаємо діаграму класів 
Спробувати кахут.

25. Породжувальні патерни
Породжувальні патерни (англ. Creational patterns) — це патерни проєктування, що абстрагують
процес побудови об'єктів. Вони допоможуть зробити систему незалежною від способу створення,
композиції та представлення її об'єктів.
Патерн, який породжує класи, використовує наслідування, щоб варіювати створюваний клас, а
патерн, що створює об'єкти, делегує створення іншому об'єктові.
Ці патерни важливі, коли система більше залежить від композиції об'єктів, ніж від наслідування
класів.
Таким чином, замість прямого кодування фіксованого набору поведінок, визначається невеликий набір
фундаментальних поведінок, за допомогою композиції яких можна отримувати складніші.
Таким чином, для створення об'єктів з конкретною поведінкою потрібно щось більше, ніж просте
створення екземпляру класу.
Патерни, що породжують, інкапсулюють знання про конкретні класи, які застосовуються у системі та
приховують деталі того, як ці класи створюються і стикуються між собою.
Єдина інформація про об'єкти, що відома системі — їхні інтерфейси.

26. Singleton/Одинак
Назва: Singleton/Одинак.
Singleton — це клас, який гарантує, що існує один і лише один екземпляр класу, і надає глобальну
точку доступу до нього.
💩Проблема:Одинак вирішує відразу дві проблеми (порушуючи принцип єдиного обов’язку класу):
1. Гарантує наявність єдиного екземпляра класу.
2. Надає глобальну точку доступу
✅Рішення: Всі реалізації Одинака зводяться до того, аби приховати типовий конструктор та створити
публічний статичний метод, який і контролюватиме життєвий цикл об’єкта-одинака.
Особливості:
1. Екземпляр створюється лише тоді, коли в ньому виникає потреба. Це називається лінивою або відкладеною
ініціалізацією (lazy initialization).
2. Цей екземпляр створюється синглетоном «за лаштунками», тому класу-клієнту немає необхідності його
створювати.
3. За дотримання цього обмеження відповідає клас-одинак, а не клас-клієнт.
4. До цього єдиного екземпляру можна звертатися безпосередньо через глобальну точку доступу, що є
статичним методом, який повертає цей об’єкт

27. Singleton/Одинак
_

28. Singleton/Одинак
Простіше кажучи: Singleton гарантує, що створений об'єкт буде єдиним у застосунку і дає змогу
отримувати до нього доступ із будь-якої частини застосунку.
Ще простіше: хороший приклад цього патерну з життя - це класний журнал у школі. У кожного
класу він тільки один, і якщо вчитель запитає журнал, то завжди отримає один і той самий екземпляр.
Коли потрібен: стане в пригоді, якщо в застосунку є керуючий об'єкт, у якому зберігається весь
контекст застосунку. Наприклад, у сервісах зберігання даних.

29. Singleton/Одинак
Застосування:
- Системі потрібен тільки один екземпляр класу.
- Примірник класу має бути легко доступним усім компонентам системи.
- Потрібна глобальна змінна або її аналог.
- Потрібна наслідуваність і поліморфізм для статичного класу, але це не підтримується.
Уряд держави — вдалий приклад Одинака. У державі може бути тільки один офіційний уряд.
Незалежно від того, хто конкретно засідає в уряді, він має глобальну точку доступу «Уряд країни N».

30. Singleton/Одинак
_

31. Singleton/Одинак
У мові C++ це можна реалізувати за допомогою використання глобальної змінної або статичного поля
класу.
Але такий підхід має недоліки:
1) клієнтський код має вільний доступ до цієї змінної, що може призвести до її несанкціонованих змін;
2) у клієнтському коді існує потенційна можливість створення більше одного екземпляра такої змінної.
Слід зазначити, що у повністю об᾿єктно-орієнтованих мовах, якими є C# і Java, взагалі виключена
можливість визначення глобальних змінних. Тому, у таких мовах для визначення глобального стану можна
використовувати лише статичні поля класу.
Використання одинака надає більш гнучкі можливості, ніж статичні функції класів або
статичні класи C#.
Використання глобальних змінних і одинаків сприяє створенню «брехливих» інтерфейсів,
тобто інтерфейсів, які не показують явних залежностей з іншими необхідними для його
функціонування об’єктами

32. Singleton/Одинак
Конструктор Одинака повинен бути прихований від клієнтів. Виклик методу getInstance повинен
стати єдиним способом отримати об’єкт цього класу.

33. Singleton/Одинак
Java і С#

34. Singleton/Одинак
✅ Переваги:
• Методи прив'язані до об'єкта, а не до статичного класу - можна передавати об'єкт за посиланням.
• Методи об'єкта значно легше тестувати та мокувати.
• Об'єкт створюється тільки за потреби: відкладена ініціалізація об'єкта.
• Прискорення початкового запуску програми, якщо є безліч одинаків, які не потрібні для запуску.
• Одинаку можна надалі перетворити на шаблон-стратегію або кілька таких об'єктів.
🤬 Недоліки:
• Порушує принцип єдиного обов’язку класу SRP SOLID.
• Залежність звичайного класу або методу від синглтона не видно в публічному контракті класу.
• Глобальні змінні це погано. Синглтон перетворюється в підсумку на одну здоровенну глобальну змінну.
• Проблеми багатопоточності:
• Ускладнюється контроль над міжпотоковими перегонами і затримками.
• Багатопотокового "одинака" складно писати "з голови": доступ до давно побудованого одинака в ідеалі не повинен відкривати м'ютекс. Краще
перевірені рішення.
• Конфлікт двох потоків із-за недобудованого одинака призведе до затримки.
• Якщо об'єкт створюється довго, затримка може заважати користувачеві або порушувати реальний час. У такому разі його
створення краще перенести в стадію ініціалізації програми.
• Проблеми тестування:
• Потрібні особливі функції для модульного тестування - наприклад, щоб перевести бібліотеку в "не-одинокий" режим і повністю ізолювати тести один
від одного.
• Потрібна особлива тактика тестування готової програми, адже пропадає навіть поняття "найпростіша запускаємість", адже запускаємість залежить від

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

36. Приклади Singleton
Клас для керування реєстрацією користувачів - Singleton може бути використаний для створення
об'єкту, який забезпечує керування реєстрацією користувачів, їх ідентифікацією та авторизацією в системі.
Менеджер подій - Singleton може бути використаний для створення об'єкту, який забезпечує
керування подіями в програмі, такими як клік миші, натискання клавіші, зміна стану об'єктів тощо.
Singleton може бути використаний для реалізації шаблону проектування Data Access Object (DAO) та
Repository.

37. Builder/Будівник
Згідно з Вікіпедією, Builder - породжувальний шаблон проектування, що надає спосіб створення
складеного об'єкта. Відокремлює конструювання складного об'єкта від його представлення так, що в
результаті одного й того самого процесу конструювання можуть виходити різні уявлення.
Простіше кажучи, Builder дає змогу створювати різні об'єкти із заданим станом, використовуючи
один і той самий код.
Ще простіше: приклад цього патерну в житті - купівля комп'ютера в магазині. Під час вибору ми
вказуємо, якими характеристиками повинна володіти техніка (наприклад, пам'ять 16 ГБ, процесор Intel
core i7 і так далі). Таким чином, ми можемо створювати різні види одного об'єкта.
Коли потрібен: стане в пригоді при складанні SQL-запиту, а також у юніт-тестах.

38. _
_

39. Builder/Будівник
Коли застосовувати?
• Загальний алгоритм побудови складного об᾿єкта не повинен залежати від специфіки кожного з його
етапів.
• В результаті того самого алгоритму конструювання треба отримати різні продукти.
Уявімо, що ми маємо конвеєр для випуску автомобілів. Суть конвеєра полягає у поетапній побудові
складного продукту, яким у цьому випадку є автомобіль. Конвеєр визначає загальну послідовність кроків
(тобто алгоритм) конструювання. При цьому, специфіка кожного з кроків визначається, головним чином,
моделлю автомобіля, що збирається. Такий розподіл загального алгоритму побудови та специфіки кожного
з етапів дозволять компанії значно заощадити: на одному конвеєрі можуть випускатися автомобілі різних
моделей з різними характеристиками.

40. Builder/Будівник
Із загально-технологічного погляду, автомобіль на конвеєрі проходить такі етапи (кроки):
1. Складання кузова.
2. Встановлення двигуна.
3. Встановлення коліс.
4. Фарбування.
5. Підготовка салону
Технічні деталі процесів, що відбуваються на кожному кроці, вже відомі певній технології виробництва
моделі автомобіля. Нехай завод може виробляти автомобілі таких моделей: автомобілі класу «міні»,
спортивні автомобілі, позашляховики. За таким розподілом виробничого процесу для компанії не
становитиме проблем доповнити спектр моделей, що випускаються за новими зразками без змін
загального конвеєрного циклу.

41. Builder/Будівник
Визначимо клас «Конвеєр», який буде прототипом реального конвеєра, тобто визначатиме загальну
послідовність кроків конструювання. Метод «Зібрати» цього класу виконуватиме процес
конструювання у вигляді виконання цих етапів (кроків) незалежно від технічних деталей реалізації
кожного етапу.
Відповідальність за реалізацію етапів конструювання покладемо на абстрактний клас, який назвемо
«ТехнологіяМоделі». Внаслідок застосування конкретних підкласів класу «ТехнологіяМоделі» ми
отримуємо різні моделі автомобілів, тобто екземпляри різних класів автомобілів. У нашому випадку
визначимо такі підкласи класу «ТехнологіяМоделі»: «ТехнологіяМініАвто»,
«ТехнологіяСпортивнийАвто», «ТехнологіяПозашляховик». Кожна з цих технологій передбачає
випуск відповідних моделей авто: «МініАвто», «СпортивнийАвто», «Позашляховик».

42. Builder/Будівник
Для початку виробництва автомобіля необхідно задати конкретну технологію для конвеєра і
викликати метод «Зібрати». Після завершення процесу складання, готовий автомобіль можна отримати у
об’єкта технології за допомогою методу «ОтриматиРезультат()»
Побудована модель має низку переваг:
1) певна технологія конструювання будується за загальним шаблоном під час реалізації дій, які він
визначає;
2) загальний алгоритм процесу конструювання не залежить від деталей, специфічних для конкретної
технології;

43. _
_

44. _
_

45. Builder/Будівник
_

46. Builder/Будівник
Учасники патерну:
■ Builder (ТехнологіяМоделі) — будівельник
▷ Забезпечує інтерфейс для поетапного конструювання складного об᾿єкта (продукту) з
елементів.
■ ConcreteBuilder (ТехнологіяМініАвто та ін.) — конкретний будівельник
▷ Реалізує етапи побудови складного об᾿єкта, визначені у базовому класі Builder.
▷ Створює результат побудови (Product) і слідкує за покроковим конструюванням.
▷ Визначає інтерфейс доступу до результату конструювання.
■ Director (Конвеєр) — розпорядник
▷ Визначає загальний алгоритм конструювання, використовуючи реалізації окремих кроків
можливості класу Builder
■ Product (МініАвто та ін.) — продукт
▷ Складний об’єкт, що виходить у результаті конструювання.

47. Builder/Будівник
Зв’язки між учасниками:
■ Клієнт конфігурує розпорядника (Director) екземпляром конкретного будівельника.
■ Розпорядник викликає методи будівельника для конструювання частин продукту.
■ Конкретний будівельник створює продукт і слідкує за його конструюванням.
■ Конкретний будівельник представляє інтерфейс доступу до продукту
Є можливість змінювати внутрішню структуру створюваного продукту (або створити новий продукт).
Оскільки продукт конструюється через абстрактний інтерфейс класу Builder, додавання нового продукту
досить визначити новий вид будівельника (тобто реалізувати новий підклас класу Builder).

48. Будівельник, приклад JAVA
_

49. _
_

50. _
_

51. _
_

52. _
_

53. Builder/Будівник v2
_

54. Builder/Будівник v2
_

55. Builder/Будівник v3
Змушуємо слідувати крокам
На рівні компілятора!
Тут навмисні помилки 

56. Builder/Будівник v3.1 (guru)
_

57. ДЗ
Напишіть програму, яка дозволяє керувати списком студентів.
1. Створіть клас-сутність Student, який має мінімум 7 полів та 8 поле - список оцінок.
2. Створіть декілька класів-білдерів, який дозволяє покроково створювати об'єкти Student різних
видів, з необов'язковими полями. Наприклад, можна створювати студентів із світу Гаррі Поттера.
3. Створіть клас-директор, який контролює кроки побудови студента у певному порядку АБО класи-
білдери, самі контролюють кроки.
4. Створіть клас-сінглтон StudentsDatabase, який забезпечує CRUD функції:
findById() – findAll() – save() – update() – delete()
6. Створіть клас-тест, де продемонструйте використання створеної системи.
(за бажанням) Реалізуйте консольний інтерфейс для взаємодії з програмою
Які мови? C++, C#, Java, PHP, Kotlin.

58. _
_