У проєктуванні ПЗ GRASP і GoF часто плутають, мов близнюків, хоча це різні штуки. Через це виникає типова плутанина: що з цього є принципами, патернами, і навіщо потрібні обидва. Розберімося коротко й по суті.
Що таке GRASP: пояснюємо дуже доступно
Абревіатура GRASP розшифровується, як General Responsibility Assignment Software Patterns. Це набір певних принципів ООП, сформульованих Крейгом Ларманом. І не просто зібраних в теорії, а доведених та сформованих через практичне використання.
Ключова ідея принципів GRASP
GRASP не пропонує вже готових шаблонів коду і не нав’язує якісь структури класів.
Натомість він вчить приймати обґрунтовані дизайнерські рішення, відповідаючи на базові питання про відповідальності в системі:
- хто має виконувати цю дію;
- який об’єкт володіє необхідними даними;
- де має бути бізнес-логіка;
- як зменшити залежності між класами;
- як уникнути «божественних» класів;
- як зробити код простішим для змін і розширення.
Фактично GRASP principles є набором практичних правил, які розробник постійно використовує під час проєктування.
Як працюють принципи GRASP на практиці
Уявіть, що це набір готових підказок, які допомагають зрозуміти, куди покласти логіку в коді. Якщо якийсь об’єкт знає потрібні дані, логічно, щоб саме він виконував пов’язану з ними дію. Наприклад, якщо об’єкт замовлення зберігає товари й ціни, то він і має рахувати загальну суму, а не контролер чи сторонній сервіс.
Контролер у такій системі виконує роль посередника. Він приймає запит від користувача або API й передає його потрібним об’єктам, не виконуючи бізнес-логіку сам. Кожен клас робить свою частину роботи і не намагається відповідати за все одразу. Завдяки цьому код стає простішим для читання та підтримки.
Якщо коротко, GRASP principles вчать думати так: «Хто має робити цю роботу і чому саме він?». Коли відповідальності розкладені правильно, код легше змінювати, тестувати й розширювати без постійних переробок.
Що таке GoF та як використовується у програмуванні
GoF розшифровується, як Gang of Four. Це набір класичних патернів проєктування, описаних у книзі Design Patterns: Elements of Reusable Object-Oriented Software.
Автори книги — чотири інженери-дослідники, відомі під спільною назвою Gang of Four.
Вони не «вигадали» патерни з нуля, а систематизували практики, які вже використовувалися в промисловій розробці, і надали їм:
- спільну мову;
- чітку структуру;
- стандартизовані назви.
Саме це зробило GoF patterns настільки впливовими й популярними.
Основна ідея GoF
Основна ідея GoF полягає в тому, щоб описати типові проблеми об’єктно-орієнтованого дизайну та перевірені способи їх розв’язання, які можна багаторазово застосовувати в різних системах. На відміну від GRASP, GoF працює на рівні конкретних рішень. Кожен GoF-патерн чітко описує:
- проблему, яка регулярно виникає;
- контекст, у якому вона з’являється;
- структуру рішення, ролі та взаємодію об’єктів;
- наслідки цього рішення для дизайну системи.
По суті, GoF відповідає на дуже прикладні запитання. Наприклад:
- як створювати об’єкти без жорсткої прив’язки до конкретних класів;
- як змінювати поведінку об’єкта, не лізучи в його код;
- як організувати взаємодію між об’єктами без щільних залежностей;
- як ізолювати частини системи, які найчастіше змінюються
GoF patterns дають розробнику набір перевірених рішень, але не підказують, коли саме їх варто використовувати.
Чому постійно плутають GRASP і GoF
GRASP і GoF найчастіше плутають тому, що обидва підходи використовуються на одному етапі — під час проєктування системи. Для багатьох розробників усе, що відбувається до написання коду, автоматично записується в категорію «design patterns». У результаті різні рівні мислення про дизайн зливаються в одну купу.
Плутанини додає й термінологія. У навчальних матеріалах слова «патерни», «дизайн» і «архітектура» часто вживають як взаємозамінні, не пояснюючи, де закінчуються принципи і починаються готові рішення. Через це GRASP principles сприймається як ще один набір патернів, хоча насправді він описує не рішення, а спосіб їх знаходити.
GoF patterns легко показувати на прикладах коду, тому їм традиційно приділяють більше уваги. GRASP же рідко розбирають детально: його або згадують між іншим, або взагалі оминають. Через це складається враження, що GoF це і є «справжній дизайн», а все інше, щось другорядне і факультативне.
Ситуацію остаточно заплутує звичка називати патерном будь-яке узагальнене дизайнерське правило. Усе, що не алгоритм і не фреймворк, легко отримує ярлик «патерн», хоча GRASP насправді є набором принципів, а не шаблонів рішень.
Як GRASP і GoF працюють разом
GRASP principles і GoF patterns не змагаються між собою і не замінюють одне одного. Вони працюють у парі, але на різних рівнях. GRASP задає основу дизайну та допомагає логічно розкласти відповідальності в системі. Саме на цьому етапі стає видно, де виникають зайві залежності, які частини системи потенційно нестабільні і які рішення виглядають надто жорсткими або перевантаженими.
Коли загальна структура вже зрозуміла, GoF-патерни перетворюються на інструменти реалізації. Наприклад, бажання зменшити зв’язність між компонентами природно підводить до використання спостерігачів або посередників.
GRASP допомагає визначити, чи потрібен патерн узагалі, а GoF підказує, який саме варто застосувати. У здоровому дизайні спочатку працюють принципи, а патерни підключаються лише тоді, коли вони реально спрощують систему, а не додають їй нових проблем.
YouTube
Висновок
GRASP і GoF плутають постійно, хоча вони відповідають на різні запитання. GRASP допомагає розкласти відповідальності в системі так, щоб код не перетворювався на хаос. GoF дає готові рішення для типових дизайнерських проблем. Хороший дизайн починається не з вибору патерну, а з правильного мислення про структуру системи. І лише коли принципів уже недостатньо, підключаються патерни, а не навпаки.
Якщо хочеться не просто знати ці терміни, а реально розуміти, коли і навіщо застосовувати GRASP та GoF у живому коді, варто подивитися курс GRASP & GOF Design Patterns від Сергія Немчинського. Курс не про механічне заучування шаблонів, а про логіку дизайнерських рішень, їх еволюцію та практичне застосування в сучасній розробці. Приходьте та освойте дизайн мислення.
