Category Archives: Creational Pattern

Abstract Factory Pattern – Creational Patterns

Download Sample Here

The Abstract Factory pattern is one level of abstraction higher than the factory pattern. You can use this pattern when you want to return one of several related classes of objects, each of which can return several different objects on request. In other words, the Abstract Factory is a factory object that returns one of several factories.

One classic application of the abstract factory is the case where your system needs to support multiple “look-and-feel” user interfaces, such as Windows-9x, Motif or Macintosh. You tell the factory that you want your program to look like Windows and it returns a GUI factory which returns Windows-like objects. Then when you request specific objects such as buttons, check boxes and windows, the GUI factory returns Windows instances of these visual interface components.

In Java 1.2 the pluggable look-and-feel classes accomplish this at the system level so that instances of the visual interface components are returned correctly once the type of look-and-feel is selected by the program. Here we find the name of the current windowing system and then tell the PLAF abstract factory to generate the correct objects for us.

String laf = UIManager.getSystemLookAndFeelClassName();

try {



catch (UnsupportedLookAndFeelException exc){

System.err.println(“UnsupportedL&F: ” + laf);


catch (Exception exc){

System.err.println(“Error loading ” + laf);


This pattern is one level of abstraction higher than factory pattern. This means that the abstract factory returns the factory of classes. Like Factory pattern returned one of the several sub-classes, this returns such factory which later will return one of the sub-classes.

Let’s understand this pattern with the help of an example given in the sample code. Suppose we need to get the specification of various parts of a computer based on which work the computer will be used for.

The different parts of computer are, say Monitor, RAM and Processor. The different types of computers are PC, Workstation and Server.  So, here we have an abstract base class Computer. This class, as you can see, has three methods all returning different parts of computer. They all return a method called Parts. The specification of Parts will be different for different types of computers. Let’s have a look at the class Parts. And now let’s go to the sub-classes of Computer. They are PC, and Server.

When to use Abstract Factory Pattern?

One of the main advantages of Abstract Factory Pattern is that it isolates the concrete classes that are generated. The names of actual implementing classes are not needed to be known at the client side. Because of the isolation, you can change the implementation from one factory to another.

Download Sample Here


Builder Pattern – Creational Pattern

Download Sample Here

The Builder Pattern is a software design pattern. The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects.

The Builder Pattern separates the construction of a complex object from its representation, so that several different representations can be created depending on the needs of the program.

Often, the Builder Pattern is used to build Products in accordance to the Composite pattern, a structure pattern.

Class Diagram

Class Diagram representation of Builder Pattern

Class Diagram of Builder Pattern

Builder: Abstract interface for creating objects (product).

Concrete Builder: Provide implementation for Builder. Construct and assemble parts to build the objects.

Director: The Director class is responsible for managing the correct sequence of object creation. It receives a Concrete Builder as a parameter and executes the necessary operations on it.

Product: The Product is the final object that will be created by the Director using Builder.

  • 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 are built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.

Consequences of the Builder Pattern

  •  A Builder lets you vary the internal representation of the product it builds. It also hides the details of how the product is assembled.
  •  Each specific builder is independent of the others and of the rest of the program. This improves modularity and makes the addition of other builders relatively simple.
  •  Because each builder constructs the final product step-by-step, depending on the data, you have more control over each final product that a Builder constructs.
  • A Builder pattern is somewhat like an Abstract Factory pattern in that both return classes made up of a number of methods and objects. The main difference is that while the Abstract Factory returns a family of related classes, the Builder constructs a complex object step by step depending on the data presented to it.

Download Sample Here

Factory Pattern – Creational Pattern

Download Sample Here

The factory pattern is a creational design pattern used in software development to encapsulate the processes involved in the creation of objects.

The creation of an object often requires complex processes not appropriate to include within a composing object. The object’s creation may lead to a significant duplication of code, may require information not accessible to the composing object, may not provide a sufficient level of abstraction, or may otherwise not be part of the composing object’s concerns.

Use the factory pattern when:

  • The creation of the object precludes reuse without significantly duplicating code.
  • The creation of the object requires access to information or resources not appropriate to contain within the composing object.
  • The lifetime management of created objects needs to be centralised to ensure consistent behavior.

In simple words, if we have a super class and n sub-classes, and based on data provided, we have to return the object of one of the sub-classes, we use a factory pattern.

Let’s take an example to understand this pattern.

Example: Let’s suppose an application asks for entering the name and sex of a person. If the sex is Male (M), it displays welcome message saying Hello Mr. <Name> and if the sex is Female (F), it displays message saying Hello Ms <Name>

Download Sample Here