Suggest an editImprove this articleRefine the answer for “What drawbacks does the Builder pattern have?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)The **Builder** pattern has a number of weaknesses, especially noticeable in simple or frequently changing systems: excess for simple objects, growth in the number of classes, and blurred responsibility. **Key point:** Builder is justified when the object is genuinely complex, multi-step, or immutable; otherwise it adds unnecessary architectural weight, complicating the code without real benefit.Shown above the full answer for quick recall.Answer (EN)ImageThe **Builder** pattern has a number of weaknesses, especially noticeable in simple or frequently changing systems. --- ### 1. **Excess for simple objects** If an object has only 2-3 parameters, using a builder is an **unnecessary layer of abstraction**. Creating a separate class just for a one-line `new Object(a, b)` only adds weight to the code and hurts readability. --- ### 2. **Growth in the number of classes** Each product usually requires **its own builder** (and sometimes a director too). In large systems this leads to an **increase in the number of files and classes**, which complicates navigation and maintenance. --- ### 3. **Blurred responsibility** Sometimes it is unclear **what is responsible for what**, the builder, the director, or the product itself. If the architecture is not well thought out, it is easy to end up with duplicated logic or unclear dependencies between them. --- ### 4. **Delayed initialization** The object is not created **immediately**, only after `build()` is called. This can lead to bugs if a developer forgets to call the final step and tries to use an unfinished builder. --- ### 5. **Limited applicability in thread-safe scenarios** A builder by itself is usually **not thread-safe**, especially if it is reused. To avoid bugs, you either have to create new builder instances or add synchronization. --- ### 6. **Difficulty when the product structure changes** If new required fields are added, you need to change the builder, the constructor, and possibly the director. This **breaks compatibility** with old code, especially if the builder is used by external clients. --- **Conclusion:** Builder is justified when the object is genuinely **complex, multi-step, or immutable**. In other cases it adds **unnecessary architectural weight**, complicating the code without real benefit.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.