Design Patterns in
Automation

About
QA since 2019
From manual QA to automation QA
Athlete with 12 years of experience

Agenda
1. Що таке патерн
2. Навіщо знати патерни
3. Класифікація патернів
4. Огляд патернів

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

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

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

Decorator Facade Factory method Composite
Builder Singleton
Chain of
Responsibility

Одинак — це породжувальний патерн
проектування, який гарантує, що клас має
лише один екземпляр, та надає глобальну
точку доступу до нього.
Singleton

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

Фабричний метод — це породжувальний
патерн проектування, який визначає
загальний інтерфейс для створення
об’єктів.
Factory method

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

Будівельник — це породжувальний патерн
проектування, що дає змогу створювати
складні об’єкти крок за кроком.
Будівельник дає можливість
використовувати один і той самий код
будівництва для отримання різних
відображень об’єктів.
Builder

Коли код повинен створювати
різні уявлення якогось об’єкта
Коли потрібно збирати
складні об’єкти

Декоратор — це структурний патерн
проектування, що дає змогу динамічно
додавати об’єктам нову функціональність,
загортаючи їх у корисні «обгортки».
Decorator

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

Фасад — це структурний патерн
проектування, який надає простий
інтерфейс до складної системи класів,
бібліотеки або фреймворку.
Facade

Якщо потрібно надати простий
або урізаний інтерфейс до
складної підсистеми.
Розкласти підсистему
на окремі рівні.

Компонувальник — це структурний
патерн проектування, що дає змогу
згрупувати декілька об’єктів у
деревоподібну структуру, а потім
працювати з нею так, ніби це одиничний
об’єкт.
Composite

Якщо потрібно представити
деревоподібну структуру
об’єктів.
Якщо клієнти повинні
однаково трактувати прості
та складові об’єкти.

Ланцюжок обов’язків — це поведінковий
патерн проектування, що дає змогу
передавати запити послідовно ланцюжком
обробників. Кожен наступний обробник
вирішує, чи може він обробити запит сам і
чи варто передавати запит далі
ланцюжком.
Chain of Responsibility

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

Яке відношення має фаза місяця до результатів автоматизованого тестування?
Чи є дослідження, які показують, що результати тестування можуть залежати від
фази місяця? І якщо так, то чому?
twitter.com/p2h_global instagram.com/p2h_space