Where would you use a Builder Pattern instead of an Abstract Factory?

Question

I've seen this question rise here and there a few times, but I never found and answer I was happy with.

From Wikipedia:

Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

But to the client isn't it the same thing? He gets the full object once it's built, so to him there is no added functionality.

The only way I see it is as a way or organizing the constructor code in steps, to force a structure for the implementation of the builders. Which is nice, but hardly a great step from the abstract factory.

---

This next bit from Wikipedia is a good reference to get to my point:

Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

If that's so, what kind of complexity would have to be introduced in your system where you would change from a Abstract Factory to a Builder?

My point is that I can't find and example where it's clear that an Abstract Factory won't suffice and you would need a Builder instead.

Answer 1

The AbstractFactory is for a family of related products. The Builder is for one product.

The Builder is for building a complex product step by step, while the AbstractFactory is to build in an abstract way (that is, once for several implementations) a less complex product.

---

Examples of what the difference means to the calling code:

• To the client code using an AbstractFactory, each method call builds one object. The client has to assemble them together. On the other side, a builder would assemble them internally, and deliver the full object graph as the last step of the building.

• The builder allow to pass and check parameters one by one for the client code. But he may build the final product in one step (for example, a call to a constructor, passing in all parameters at once, even sophisticated ones that have been build themselves). So the product of a builder could be an immutable object (or graph of) (which is priceless in multi-threaded environment, for performance and memory reasons).

---

UPDATED in response to this comment :

Lino > It's still bothering me, though :). I mean, if you are building composite objects, and you take the director out, passing the responsibility of calling the builder methods to the clients, then it works for me. Only then the builder would seem a perfect fit. But with the director, it doens't seem like much...

Precisely, the Builder has no director, it lets each client create a complex product according to it's specific needs. The client is the director, because the director's implementation is not reused.

If you need to reuse a few times a complex building process, then you can have a method to encapsulate this (and this method is your "director").

On the contrary, for the AbstractFactory, you typically need a reusable Director, that create products alike (provided with a Factory implementation).