CSC/ECE 517 Fall 2012/ch2a 2w18 as

From PG_Wiki
Jump to: navigation, search

Abstract Factory and Builder Patterns

Design Patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges[1]. Design Patterns in Object - Oriented Languages help show the relationship between the different classes and objects in the program.

Design Patterns can be categorized as:

Abstract Factory and Builder Patterns are examples of Creational Patterns.

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes[2].

The Builder Pattern allows for object level access control by acting as a pass through entity or a placeholder object[2].


Creational Patterns

Creational Patterns are Design Patterns that somehow control the mechanism by which objects are created. They generally help to provide the following capabilities [3]:

Abstract Factory

The basic purpose of the Abstract Factory method Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes".[4]

Abstract Factory Patterns are used when a client needs to create an instance of a class from a group of similarly related classes. The client does not know (or care) which type of class the client gets an instance of. The type of class returned to the client depends on some condition (and is not of the client's choosing) which is usually stored in some sort of a configuration file. The abstract factory looks up this configuration file then returns the corresponding class to the client.

The client has no need to specify the type, since it has already been specified in the configuration file. In particular, this means:[5]

UML Diagram




Let's say we are creating a Habitat which we populate with trees and animals. However, we need to ensure that the combination of trees and animals makes sense, viz. a client should add Algae and Frog together in the habitat, or Tiger and Tree, but not Tiger and Algae or Frog and Tree. We simply create two factories, one for adding Tigers and Trees and one for adding Frogs and Algae. The object dedicated to creating the compatible set of objects is the abstract factory.

   class Tiger
     # Tiger specific class implementation
   class Tree
     # Tree specific class implementation
   class Frog
     # Frog specific class implementation
   class Algae
     # Algae specific class implementation
   class PondOrganismFactory
     def new_animal(name)
     def new_plant(name)
   class JungleOrganismFactory
     def new_animal(name)
     def new_plant(name)
   class Habitat
     def initialize(number_animals, number_plants, organism_factory)
       @organism_factory = organism_factory
       @animals = []
       number_animals.times do |i|
         animal = @organism_factory.new_animal("Animal#{i}")
         @animals << animal
       @plants = []
       number_plants.times do |i|
         plant = @organism_factory.new_plant("Plant#{i}")
         @plants << plant

We can now feed different abstract factories to our habitat, and also ensure that no illogical combinations of plants and animals exist in our created habitat.

   jungle =, 4,
   pond = 2, 4,


Now let's look at an implementation in Java. The code shows how we can implement a type of button, and clicking the button will display a different message depending on the type of operating system the code is run on. The output should be either "I'm a WinButton" or "I'm an OSXButton" depending on which kind of factory was used. Note that the Application has no idea what kind of GUIFactory it is given or even what kind of Button that factory creates.

   interface Buttonlike {
       public void paint();
   interface GUIFactorylike {
       public Buttonlike createButton();
   class WinFactory implements GUIFactorylike {
       public Buttonlike createButton() {
           return new WinButton();
   class OSXFactory implements GUIFactorylike {
       public Buttonlike createButton() {
           return new OSXButton();
   class WinButton implements Buttonlike {
       public void paint() {
           System.out.println("I'm a WinButton");
   class OSXButton implements Buttonlike {
       public void paint() {
           System.out.println("I'm an OSXButton");
   class Application {
       public Application(GUIFactorylike factory) {
           Buttonlike button = factory.createButton();
   public class ApplicationRunner {
       public static void main(String[] args) {
           new Application(createOsSpecificFactory());
       public static GUIFactorylike createOsSpecificFactory() {
           int sys = readFromConfigFile("OS_TYPE");
           if (sys == 0) return new WinFactory();
           else return new OSXFactory();


The Builder Pattern is a design pattern that abstracts steps of construction of objects so that different implementations of these steps can construct different representations of objects[6].

Complex applications require complex objects. Complex objects are usually made of sub-objects. These sub-objects generally have their own properties and configurations[7]. For example consider a Car object. The Car object is made of many sub-objects like Steering Wheel, Wheels and Transmission. The Steering Wheel could be hydraulic driven or electronic. The Wheels could be tubeless or tubed. The Transmission could be automatic or manual. So to configure a Car object you will first have to configure the individual components and then put them together to build the Car.

The Builder pattern allows you to build complex objects by specifying only its type and contents and not be worried about the implementation details. As a result different representations can be created using the same set of simple objects.


Let us understand the Builder pattern better with a couple of examples.


Suppose we have to build a Computer which consists of several components like a hard disk, motherboard, disk drives and display. Each of the components can be customized - hard disk can have some specified size, display could be Low-Def or Hi-Def, disk drives could be DVD or Blu-Ray. The motherboard itself has a CPU which could be Dual-Core or Quad-Core. It also has memory of some specified size. Lets define a Computer and other related objects in Ruby[8]:

class Computer
  attr_accessor :display
  attr_accessor :motherboard
  attr_reader   :drives
  def initialize(display=:low-def,, drives=[])
    @motherboard = motherboard
    @drives = drives
    @display = display

class CPU
  # CPU details...

class DualCoreCPU < CPU
  # DualCore CPU details...

class QuadCoreCPU < CPU
  # QuadCore CPU details...

class Motherboard
 attr_accessor :cpu
 attr_accessor :memory_size
 def initialize(, memory_size=1000)
    @cpu = cpu
    @memory_size = memory_size

class Drive
 attr_reader :type # either :hard_disk, :blu_ray or :dvd
 attr_reader :size # in MB
 attr_reader :writable # true if this drive is writable
 def initialize(type, size, writable)
    @type = type
    @size = size
    @writable = writable

We can then define a ComputerBuilder class that lets one specify the configuration of each new Computer object you create and assembles them together.

class ComputerBuilder
 attr_reader :computer
 def initialize
   @computer =
 def turbo(has_turbo_cpu=true)
   @computer.motherboard.cpu =
 def display=(display)
 def memory_size=(size_in_mb)
   @computer.motherboard.memory_size = size_in_mb
 def add_blu_ray(writer=false)
   @computer.drives <<, 760, writer)
 def add_dvd(writer=false)
   @computer.drives <<, 4000, writer)
  def add_hard_disk(size_in_mb)
    @computer.drives <<, size_in_mb, true)

Now the ComputerBuilder object can be used to specify the configuration needed on the Computer. This is done in the Engineer class which specifies the configuration of Computer required. The Engineer directs the ComputerBuilder on what components must be added.

class Engineer
 builder =
 computer =


Not lets have a look at another example in Java[9]. Suppose a Cook wants to serve Pizzas. A pizza is made of some dough and can a variety of sauses and toppings.

/** "Product" */
class Pizza {
   private String dough = "";
   private String sauce = "";
   private String topping = "";

   public void setDough(String dough)     { this.dough = dough; }
   public void setSauce(String sauce)     { this.sauce = sauce; }
   public void setTopping(String topping) { this.topping = topping; }

   public String getDough()     { return this.dough; }
   public String getSauce()     { return this.sauce; }
   public String getTopping()   { return this.topping; }

/** "Builder" */
class PizzaBuilder {
   private Pizza pizza;

   public Pizza getPizza() { return pizza; }
   public PizzaBuilder() { pizza = new Pizza(); }

   public void addDough(String dough)     { pizza.setDough(dough); }
   public void addSauce(String sauce)     { pizza.setSause(pizza.getSauce() + ", " + sause); }
   public void addTopping(String topping) { pizza.setTopping(pizza.getTopping() + ", " + topping); }

/** "Director" */
class Cook {
   private PizzaBuilder pizzaBuilder;

   public Pizza getPizza() { return cookTastyPizza(); }

   public Pizza cookTastyPizza() {
      pizzaBuilder = new PizzaBuilder();
      pizzaBuilder.addDough("Pan Baked");
      return pizzaBuilder.getPizza();

The Cook is the Director, which uses the PizzaBuilder to add ingredients to a Pizza. The Director does not need to know the implementation details of how the ingredients are added to the Pizza (though you'd want a real Cook to know). Only specifying the contents is sufficient.

In both examples, the scenario required that an object be created by using multiple components. The object can be created in different flavors by varying the components used. The Builder pattern is very useful in these scenarios as it lets us specify the components required and abstracts the details related to implementation.

Class Diagram

Lets look at the class diagram for the Builder Pattern:


The client of the ComputerBuilder or PizzaBuilder i.e the code which instantiates the ComputerBuilder or PizzaBuilder object is called the Director. The Builder class creates the complex objects and at the same time hides the implementation details from the Director.


Abstract Factory Pattern Builder Pattern
To provide an interface for creating families of related or dependent objects without specifying their concrete classes. To separate the construction of complex objects and their representation, thus allowing the same construction process to create different representations.
Used to provide handles to various types of factories that allow the client to create fixed instances of types of classes. Used to provide types of objects and not factories.
Does not allow customization of objects being created - since client may not even be aware of the type of object it gets. Allows customization of objects that are being created.
Creates the object at one go. Creates the object in parts and then returns the whole object to the client.


  1. (n.d.). .net design patterns. Retrieved from DoFactory website:
  2. 2.0 2.1 (1995). Design patterns : elements of reusable object-oriented software. Reading, Mass: Addison-Wesley.
  3. Stelting, S. (2002). Creational patterns. In Applied java patterns (p. 5). Palo Alto, California: Sun Microsystems. Retrieved from
  4. ^ [|Gamma, Erich]; Richard Helm, Ralph Johnson, John M. Vlissides (2009-10-23). "Design Patterns: Abstract Factory" (in English) (HTML). informIT. Archived from the original on 2009-10-23. Retrieved 2012-05-16. "Object Creational: Abstract Factory: Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes."
  5. (2012, October 25). Abstract factory pattern. Retrieved from Wikipedia website:
  6. (2012, October 17). Builder pattern. Retrieved from Wikipedia website:
  7. (n.d.). Builder pattern. Retrieved from OODesign website:
  8. Olsen, R. (2007). Easier object construction with the builder. In Design patterns in ruby (pp. 250-253). Addison Wesley.
  9. (2012, October 26). Builder pattern. Retrieved from Wikipedia website:
Personal tools