Патерни важать... повсюди

Багато років тому, коли я починав вивчення ООП та патернів розробки, я мав таку гадку, що ті непрості та, ймовірно, круті штуки мають бути впроваджені в якихось дійсно великих застосунках, аби проявилися всі їхні принадливі переваги, описані Бандою Чотирьох, та засяяли у всій їх величі. Це мало бути чимось на кшталт розподіленої архітектури з командою з десятків розробників, мати тисячі клієнтів, щоденно нові вимоги, що означає найвищй рівень супроводу - в моїй уяві щось штибу такого було чимось найменшим, що давало змогу лишень починати думати щодо впровадженні всіх отих "патернів". І, оскільки о тій порі я працював над простими, орієнтованими на вміст, веб сайтами, побудованими на Umbraco CMS, нагода якось застосувати ті патерни була дуже невеликою. Ти маєш контролери, маєш нудний будівний підхід "сервіс/репозиторій", що його запровадив ЛІДЕР КОМАНДИ, котрий колись написав ПЕРШУ СОТНЮ РЯДКІВ КОДУ для проєкту — це означає, що твій клопіт полягає лише в тому, щоб КРУДити речі настільки однотипно, наскільки це можливо, крок ліворуч/праворуч заборонений, покривати їх тестами та бути вдячним Всесвіту.

І я дійсно був вдячний Всевіту, оскільки, серед багатьох інших добрих речей в моєму житті, він дав мені змогу дізнатися про такого собі Зорана Хорвата, автора багатьох курсів з c#, чиї оповідання про ті патерни розробки були просто приголомшливими. Його спосіб пояснення був саме таким, якого я потребував — курс про те, як створювати об'єкти, курс про те, як з ними будувати поведінку, як розділяти відповідальність, і в цілому — як керувати загальною складністю застосунку в цілому. Не кваплячись, зазирачи в найдрібніші деталі кожного прикладу, Зоран Хорват своїми курсами дав мені нагоду зловити чимало митей прозріння — то є дуже вартісне!

Працюючи з ASP NET MVC та Umbraco CMS, я бачив, що вони побудовані на патернах. Це стає очевидним, коли їх використовуєш — бачиш, як вони працюють, які засоби вони надають розробнику та яким чином вони дозволяють розширити їхній вбудований функціонал. Я почав ті патерни відчувати дещо інтуітивно; а також я дуже хотів побудувати з їх використанням щось дійсно велике але... нічого великого на моєму розробницькому горизонті якось не спостерігалось.

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

І наскільки ж я був здивований, коли, неочікувано для самого себе, плануючи впровадження для того застосунку, я зрозумів, що мій розум пропонує мені оті самі "патерни"! Розділення відповідальностей, устатковування залежностей, фабрики, сінглтони, ланцюжки відповідальностей та навіть візитер природнім чином знайшли своє місце в тій невеликій програмі. Здавалося, вчергове втілилася стародавня мудрість — "що у великому, те і в малому". Я отримав багато задоволення, розробляючи той тристарядковий застосунок.

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

Пізніше я мав таку ж ситуацію на іншому проєкті, де стояла задача апргейду веб сайту, побудованому на Umbraco CMS, з версії 8 на 10. Головною проблемою такого апгрейду є той факт, що система Umbraco 8 написана на .NET Framework, а Umbraco 10 вже проапгрейджена до .NET Core. Це означає багато змін в коді застосунку, отже, сама по собі задача є доволі значною. Також є відмінності в тому, як вміст зберігається в базі даних — Umbraco 10 використовує більш легкі об'єкти JSON для їх зберігання в таблиці. Більше того, вміст на старому сайті було запроваджено з використанням певного пакету розширення, який вже став застарілим на час виходу Umbraco 10, оскількии його функціонал було базово додано до новий версій CMS. Отже, як частину своєї роботи на проєкті я (знову!) потребував створення окремого інструменту апгрейду вмісту, щоб той інструмент проходив по контентному дереву, брав би елементи вмісту один за одним, дивився б на старий визначник типу, міняв би його на відповідний новий, оновлював би формат зберігання властивостей та зберігав би назад в базу даних.

І (знову!) щось таке, що я називаю "патернове мислення", природньо стало в пригоді та потішило мене гарним вирішенням тієї не такої вже й складної задачі.

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

Як то сказано — це не про лук та стріли, це про лучника.