Separate the construction of a complex object from its representation so the same construction process can create different representations. (GoF)
A relational database contains information that can be consumed in different ways, depending on the needs of the client. Whereas one client might prefer to iterate over the data in a flat structure (like a Vector or an ArrayList), another might need to see the data’s parent-child relationships implied by the foreign keys that records contain (which link them to other tables) à la the Composite Pattern.
A Builder would hide the details of construction, allowing the clients to specify which form of the data was desired without coupling to the specific steps required to make it.
Qualities and principles
Each Builder has the single responsibility of building a specific version of the complex object that is needed. Clients couple to the interface of the Director, but not the builders. A client is only concerned with the builder that applies to its needs; the other builders, their specifics and their number, are not referenced by a given client, and thus the design is open-closed to new builders that make new versions of the complex object. The director interface comes from the needs of the clients. The builder interface comes from the nature of the object being built.
The director can be tested using a Mock of the builder interface. Each individual builder can be tested in a straightforward way, the specifics depending on the nature of the complex object being built.
Questions and concerns
There are different ways for the director to obtain the correct builder. The client may supply it, the director may determine this based on the context of the application, and so on. Sometimes another factory is used by the director to accomplish this. These issues must be dealt with on a case-by-case basis, as the nature of the problem will dictate what is correct.
This is Scott Bain. Visit us at www.netobjectives.com.