На співбесіді кандидат без запинки розшифровує кожну літеру SOLID і розповідає про Strategy та Observer. Потім отримує просте завдання: спроєктувати модуль замовлень для інтернет-магазину. І тут пауза. Хвилина, друга. На дошці з’являються п’ять інтерфейсів, дві фабрики й жодної відповіді на питання, де зберігається статус замовлення.
Так буває, коли правила вивчені окремо від контексту, від відповідальностей і від того, чим кожне рішення обернеться через півроку.
Що дають SOLID-принципи і де закінчується їхня зона дії
Що таке SOLID, пам’ятає майже кожен, хто готувався до співбесіди на Java чи C#. Це п’ять принципів об’єктно-орієнтованого дизайну, які систематизував Роберт Мартін: одна відповідальність на клас, розширення без переписування, коректна підстановка нащадків, вузькі інтерфейси, залежність від абстракцій. Кожну літеру ми вже детально розібрали в статті про SOLID-принципи і код, який не підводить.
Принципи SOLID працюють як лінійка. Прикладаєш її до класу і бачиш: ось тут він робить три речі одночасно, а тут модуль верхнього рівня намертво прив’язаний до бази даних. Для оцінки коду інструмент дуже зручний.
Та лінійка не підкаже, що будувати. Вона не скаже, чи потрібен системі окремий сервіс для платежів, чи мають дані оновлюватися синхронно, чи можна дозволити затримку в кілька секунд. Кожен принцип SOLID відповідає на питання про форму коду. Питання про форму системи лишаються відкритими.
Чому знання патернів ще не означає вміння проєктувати систему
Патерни GoF (23 шаблони проєктування з книги Гамми, Гелма, Джонсона та Вліссідеса 1994 року) описують перевірені рішення конкретних проблем. Factory ховає складне створення об’єктів. Strategy дозволяє міняти алгоритм, не чіпаючи код, який його викликає. Observer розв’язує зв’язок між тим, хто генерує подію, і тим, хто на неї реагує.
У кожного з них є умова застосування. Є проблема, є рішення. Немає проблеми, і патерн перетворюється на зайвий шар коду.
Типова помилка виглядає так. Розробник тиждень тому розібрався зі Strategy і тепер бачить її скрізь. Два варіанти розрахунку знижки? Strategy. Три типи сповіщень? Знову вона. За місяць у проєкті десять інтерфейсів з однією реалізацією кожен, а новенькому в команді потрібен день, щоб знайти, де насправді рахується ціна.
Пошукові запити на кшталт solid паттерн чи паттерн solid добре показують цю плутанину. SOLID шукають як ще один патерн, хоча це набір принципів, якими патерни якраз і оцінюють. Відчути різницю між знанням шаблону і доречним застосуванням допомагає курс GRASP & GoF Design Patterns, де Сергій Немчинський розбирає шаблони на прикладах з реальних проєктів.
Де між ООП, SOLID і патернами з’являється архітектурне мислення
Пара ООП SOLID стоїть у вимогах майже кожної вакансії, і вчать ці теми зазвичай як окремі розділи підручника. Насправді вони складаються в ланцюжок, де кожна ланка спирається на попередню:
- ООП дає інструменти: класи, інкапсуляцію, поліморфізм.
- GRASP (шаблони розподілу відповідальностей, які описав Крейг Ларман) допомагає вирішити, який клас що має робити.
- SOLID задає принципи здорового дизайну, щоб цей розподіл не розсипався при перших змінах.
- GoF пропонує готові рішення для типових ситуацій, що виникають по дорозі.
Бездоганне знання всіх чотирьох рівнів ще не дає архітектурного мислення. Воно з’являється вище, коли розробник дивиться на систему цілком і бачить наслідки вибору: що подорожчає, що спроститься, що зламається першим. Грейді Буч, один з авторів UML, писав:
«Архітектура складається зі значущих проєктних рішень, які формують систему, а значущість вимірюється вартістю змін».
Як ці рівні з’єднуються між собою, детально показано в матеріалі про те, як ООП, GRASP, SOLID та GoF складаються в одну систему.
Як SOLID працює на практиці, коли єдиної правильної відповіді немає
Хто вбиває в пошук solid на практиці, зазвичай хоче побачити приклад коду. Спробуймо інакше і візьмімо рішення, у якого немає еталонної відповіді.
Сервіс замовлень напряму викликає API одного платіжного провайдера. Бізнес каже, що колись, можливо, додасть другого. Можливо. Коли саме, ніхто не знає.
Принцип інверсії залежностей підказує сховати оплату за інтерфейс. Це година роботи і ще один рівень абстракції, через який доведеться продиратися при кожному дебагу. Якщо другий провайдер з’явиться через два місяці, рішення окупиться. Якщо не з’явиться ніколи, команда роками підтримуватиме абстракцію заради гіпотетичного майбутнього.
Далі цікавіше. Провайдер іноді відповідає по десять секунд. Чекати відповіді в тому самому запиті чи відправляти платіж у чергу й повідомляти користувача пізніше? SOLID тут мовчить. Це вже питання про швидкість, надійність, складність інфраструктури і терпіння клієнтів.
Архітектурне рішення завжди є trade-off (компромісом між кількома бажаними, але несумісними властивостями). Підтримуваність проти швидкості розробки. Гнучкість проти простоти. Хто цього не бачить, той або переускладнює все підряд, або не закладає нічого.
Які питання ставить розробник з архітектурним мисленням
Досвідчений архітектор рідко починає з питання, який патерн сюди вставити. Патерн з’являється наприкінці, як відповідь. Спершу йдуть інші питання, куди приземленіші:
- де має жити ця відповідальність і хто за неї відповідає;
- від чого залежатиме компонент і що буде, коли ця залежність зміниться;
- що доведеться переписувати через півроку, коли прийдуть нові вимоги;
- наскільки рішення ускладнює систему для людини, яка відкриє код уперше;
- що станеться, коли навантаження виросте вдесятеро;
- чи розв’язуємо ми реальну проблему, чи будуємо красиву архітектуру для себе.
Останнє питання найнеприємніше. Відповідь на нього регулярно викидає з проєкту половину запланованих абстракцій. Зате код, що лишається, легше читати, тестувати й змінювати. Власне, заради цього колись і придумали всі ці абревіатури.
YouTube
Перестань збирати абревіатури й почни зважувати рішення
Архітектурному мисленню не вчаться з конспекту. Воно росте з практики, і цю практику можна організувати свідомо. Розбирай чужі рішення в open source проєктах і питай себе, чому автори зробили саме так. Записуй компроміси, на які йдеш сам, хоча б двома реченнями в описі пул-реквесту. Проходь code review з обох боків і аргументуй кожне зауваження. Вчися пояснювати, чому патерн тут не потрібен. Це складніше, ніж пояснити, навіщо він потрібен.
Теорію теж варто перебудувати. ООП, GRASP, SOLID і GoF працюють як одна система, і вивчати їх варто так само. На цьому побудована книга Сергія Немчинського Фундамент архітектури: засновник FoxmindEd показує, де ці підходи перетинаються і де кожен з них закінчується.
SOLID-принципи та патерни дають словник. Архітектура починається там, де ти зважуєш наслідки рішення і можеш пояснити команді, чому обрано саме його. Візьми наступну задачу на роботі й спершу дай відповідь про зміни та залежності. Патерн почекає.
