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