Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Які недоліки має патерн Builder?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)У патерна **Builder** є низка слабких сторін, особливо помітних у простих або таких, що часто змінюються, системах: надлишковість для простих об'єктів, зростання кількості класів, розмивання відповідальності. **Ключове:** Builder виправданий, коли об'єкт дійсно складний, багатокроковий або immutable; в інших випадках він додає зайву архітектурну вагу, ускладнюючи код без реальної вигоди.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняУ патерна **Builder** є низка слабких сторін, особливо помітних у простих або таких, що часто змінюються, системах. --- ### 1. **Надлишковість для простих об'єктів** Якщо об'єкт має всього 2-3 параметри, використання білдера - це **зайвий рівень абстракції**. Створення окремого класу заради одного рядка `new Object(a, b)` лише обтяжує код і погіршує читабельність. --- ### 2. **Зростання кількості класів** Кожен продукт зазвичай вимагає **окремого білдера** (а іноді ще й директора). У великих системах це призводить до **збільшення кількості файлів і класів**, що ускладнює навігацію і підтримку. --- ### 3. **Розмивання відповідальності** Іноді неочевидно, **що за що відповідає** - білдер, директор чи сам продукт. Якщо архітектура не продумана, легко отримати дублювання логіки або неочевидні залежності між ними. --- ### 4. **Затримка ініціалізації** Об'єкт створюється **не одразу**, а лише після виклику `build()`. Це може призвести до помилок, якщо розробник забуде викликати фінальний крок і спробує використати незавершений білдер. --- ### 5. **Обмежена застосовність у потокобезпечних сценаріях** Білдер сам по собі зазвичай **не потокобезпечний**, особливо якщо використовується повторно. Щоб уникнути помилок, доводиться або створювати нові екземпляри білдера, або додавати синхронізацію. --- ### 6. **Складність при зміні структури продукту** Якщо додаються нові обов'язкові поля, потрібно змінювати і білдер, і конструктор, і можливого директора. Це **ламає сумісність** зі старим кодом, особливо якщо білдер використовується зовнішніми клієнтами. --- **Висновок:** Builder виправданий, коли об'єкт дійсно **складний, багатокроковий або immutable**. В інших випадках він додає **зайву архітектурну вагу**, ускладнюючи код без реальної вигоди.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.