What drawbacks does the Builder pattern have?

The 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.