File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Builder Pattern - Why does it looks like another Creational pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Builder Pattern - Why does it looks like another Creational pattern" Watch "Builder Pattern - Why does it looks like another Creational pattern" New topic

Builder Pattern - Why does it looks like another Creational pattern

mini mehta
Ranch Hand

Joined: Oct 22, 2000
Posts: 120
Following is an example of builder pattern, from one of the SCEA books. I have following question about it.

1. Why does it looks just like any other creational pattern with lots of indirection.

2. What is the use of director object here? It is just adding to the indirection. What kind of role does it really plays apart from creating a Builder object.

3. Why do all patterns appear to be creational patterns to me, am I miss a point or i am just too thick?

package j2ee.architect.Builder;
public class BuilderPattern {
public static void main(String[] args) {
System.out.println("Builder Pattern Demonstration.");
// Create builder
System.out.println("Constructing builder.");
BuilderIF builder = new ConcreteBuilder();
// Create director
System.out.println("Constructing director.");
Director director = new Director(builder);
// Construct customer via director
System.out.println("Constructing customer.");
// Get customer via builder
CustomerIF customer = builder.getCustomer();
// Use customer method
System.out.println("Calling action on the customer.");

package j2ee.architect.Builder;
public interface BuilderIF {
public void buildCustomer();
public CustomerIF getCustomer();

package j2ee.architect.Builder;
public class ConcreteBuilder implements BuilderIF {
CustomerIF customer;
public void buildCustomer() {
customer = new ConcreteCustomer();
// You could add more customer processing here...
public CustomerIF getCustomer() {
return customer;

package j2ee.architect.Builder;
public class ConcreteCustomer implements CustomerIF {
public ConcreteCustomer() {
System.out.println("ConcreteCustomer constructed.");
public void action() {
System.out.println("ConcreteCustomer.action() called.");

package j2ee.architect.Builder;
public interface CustomerIF {
public void action();

package j2ee.architect.Builder;
public class Director {
BuilderIF builder;
public Director(BuilderIF parm) {
this.builder = parm;
public void construct() {
Bhagvan Kommadi
Ranch Hand

Joined: Oct 15, 2001
Posts: 36

Your observation is quite true.

check out this link where how creational patterns compete with each

other is discussed.

Bhagvan K
<a href="<a href="" target="_blank" rel="nofollow">Architect" target="_blank">[URL=]Architect Corner
Sol Mayer-Orn
Ranch Hand

Joined: Nov 13, 2002
Posts: 311
Warning - I'm not sure that's the official definition, that's just the humble opinion I've formed...
1) Builder is indeed an creational pattern. I believe the Director is a specialized case of a Factory. At the same time, and without contradiction, it could be argued that the Builder is a Strategy object , assisting the Director

2) The reason for separating Builder from Director is flexibility & "spearating the minimal factor of change". Usually, the director holds the general, high-level instructions for building a complex object. For instance, it could say "a Hotel is made out of 1 Lobby in the first floor, 1 Garden in the south, and a configurable number of guest rooms at the top floors".
The builder holds the details for how to construct & assemble parts, depending on specific data structure choices. For example, it could say "adding a room to an Hotel requires you to add a Node to a Linked list (supposing this is the current implementation of Hotel)".
This, of course, allows flexibility, because you may change the data structure without changing the building outline. The same "1 lobby, 1 garden, X rooms" Director will be able to work with a different Hotel/Builder implementation - e.g: "to add a room to an array-based Hotel, you'll need to add an item to the array, taking care to re-allocate it if array is currently full".

3) IMHO (& I say this with less confidence), Builder is reduntant if all your complex objects have the same interface. For instance, you wouldn't need the Builder if all your Hotels (LinkedListHotel, ArrayBasedHotel) have the same methods "addRoom", "addLobby"... (each implementing it so as to manipulate the appropriate structure).
However, builder would be usedful if your Hotels come from different legacy systems, having different API's.
E.g, if HotelClass1 has method "addRoom" while HotelClass2 has "insertNewRoom", then you can't used them directly from a general-purpose Director. You need to access them via Builders, that would provide a common interface.
I agree. Here's the link:
subject: Builder Pattern - Why does it looks like another Creational pattern
It's not a secret anymore!