1

I'm trying to understand builder pattern usages and so to call to separate is usage types in groups. Here is what I discovered:

  • Builder can be used to provide immutability (avoiding telescoping) for an object he is building. So called Joshua Bloch's builder. So, we use builder to facilitate building of object with a lot of fields.
  • Builder can build some objects that need to be structured and follow some structure rools. For example XmlBuilder, that builds xml and can fail when wrong data is passed (e.g. not closing a tag, or so on). In this case builder validates inner object on each build step.

But what about GoF's builder? With Director, abstract Builder and different implementations.. I have never seen such implementation in production. Have you ever seen such examples?

  • Yes, I implemented a builder in form of an inheritance hierarchy - (in a closed source product, so no code to share here). We used it to create a complex XML document with different contents, actually different results from different types of calculations. The "Director" in GoF is just a placeholder for the point in code where the builder is used/called from, so that is nothing "special", you will find such a place whereever a Builder is used. – Doc Brown Sep 11 '16 at 20:02
7

A key to the understanding of the GoF design patterns is their intent. For the builder it is:

Separate the construction of a complex object from its representation so that the same construction process can create different representations

Simplified variant

When looking at the solution proposed by GoF, what strikes most is the separate building and assembly of parts: the structure distinguishes the Director and the Builder and enables a step by step construction:

  • This aspect of the pattern apparently stroke Joshua Bloch as well, because his approach uses this separation to set a lot of optional parameters.
  • This sequence of events also allows for validating parts before assembling the result, as you've notice in this XmlBuilder.

While being very useful, I think however that these examples focus only on one aspect of the pattern and miss the real intent. Thus their structure appears simplified by merging either Director and Builder or Builder and ConcreteBuilder.

The missing intent

For GoF, it's not only about the separation between Director and Builder to build by step, but also the separation between Builder and ConcreteBuilded:

  • If you look well at pattern structure, you'll notice that the Builder provides the polymorphic/virtual buildPart() methods. But getResult() to obtain the final product is a method of ConcreteBuilder that is not included in the abstract Builder's interface. So it can use different parameters or return different types.
  • The GoF sequence diagram on page 99 shows furthermore that a Client calls the Director for constructing the object and trigger the building of parts (perhaps using temporary objects), but that it's up to the client to call getResult() directly from ConcreteBuilder.
  • In fact, the client knows the ConcreteBuilder (may be even it instantiates it) and calls the Director by referfencing it.

This makes clear that this pattern is not so for building the parts and assemble the whole (which after all is nothing more than a helper to simplify providing all the elements at once), but more for returning very different "representations" (classes) using the same procedure for constructing the parts.

Real life use of the complete pattern

The typical use in real life is to build composite objects having different types of implementation/representation, such as for example different graphical representations/views (e.g. Entity/Relationship or UML model), different input or output formats (e.g. JSON or XML document) or encodings (e.g ASCII vs UTF16/32).

A concrete use could for example be ADO.net with DbCommandBuilder that is implemented by concrete SqlCommandBuilder, OracleCommandBuilder, ODBCCommandBuilder to generate db specific commands.

  • Thats really helpful, thanks a lot, Christophe! One more question, if you don't mind. So, the only goal of Director is to define an algorithm for building any Builder representation? – Ivan Nikolaychuk Sep 12 '16 at 5:31
  • 2
    @IvanNikolaychuk yes! The director defines the construction process based on the builder's abstract interface. It can then apply the construction algorithm using any concrete builder to get the desired representation. Note that there can be several directors for a builder. – Christophe Sep 12 '16 at 6:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.