What is the difference between Builder Design pattern and Factory Design pattern?
The Factory pattern can almost be seen as a simplified version of the Builder pattern.
In the Factory pattern, the factory is in charge of creating various subtypes of an object depending on the needs.
The user of a factory method doesn't need to know the exact subtype of that object. An example of a factory method createCar
might return a Ford
or a Honda
typed object.
In the Builder pattern, different subtypes are also created by a builder method, but the composition of the objects might differ within the same subclass.
To continue the car example you might have a createCar
builder method which creates a Honda
-typed object with a 4 cylinder engine, or a Honda
-typed object with 6 cylinders. The builder pattern allows for this finer granularity.
Diagrams of both the Builder pattern and the Factory method pattern are available on Wikipedia.
A factory is simply a wrapper function around a constructor (possibly one in a different class). The key difference is that a factory method pattern requires the entire object to be built in a single method call, with all the parameters passed in on a single line. The final object will be returned.
A builder pattern, on the other hand, is in essence a wrapper object around all the possible parameters you might want to pass into a constructor invocation. This allows you to use setter methods to slowly build up your parameter list. One additional method on a builder class is a build() method, which simply passes the builder object into the desired constructor, and returns the result.
In static languages like Java, this becomes more important when you have more than a handful of (potentially optional) parameters, as it avoids the requirement to have telescopic constructors for all the possible combinations of parameters. Also a builder allows you to use setter methods to define read-only or private fields that cannot be directly modified after the constructor has been called.
Basic Factory Example
// Factory
static class FruitFactory {
static Fruit create(name, color, firmness) {
// Additional logic
return new Fruit(name, color, firmness);
}
}
// Usage
Fruit fruit = FruitFactory.create("apple", "red", "crunchy");
Basic Builder Example
// Builder
class FruitBuilder {
String name, color, firmness;
FruitBuilder setName(name) { this.name = name; return this; }
FruitBuilder setColor(color) { this.color = color; return this; }
FruitBuilder setFirmness(firmness) { this.firmness = firmness; return this; }
Fruit build() {
return new Fruit(this); // Pass in the builder
}
}
// Usage
Fruit fruit = new FruitBuilder()
.setName("apple")
.setColor("red")
.setFirmness("crunchy")
.build();
It may be worth comparing the code samples from these two wikipedia pages:
http://en.wikipedia.org/wiki/Factory_method_pattern
http://en.wikipedia.org/wiki/Builder_pattern
With design patterns, there usually is no "more advantageous" solution that works for all cases. It depends on what you need to implement.
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.
- Builder often builds a Composite.
- 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.
- Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
Wikipedia entry for factory design pattern: http://en.wikipedia.org/wiki/Factory_method_pattern
Wikipedia entry for builder design pattern: http://en.wikipedia.org/wiki/Builder_pattern