Posted on

Builder pattern in Java

Builder falls under the type of creational pattern category. Builder pattern helps us to separate the construction of a complex object from its representation so that the same construction process can create different representations. Builder pattern is useful when the construction of the object is very complex. The main objective is to separate the construction of objects and their representations. If we are able to separate the construction and representation, we can then get many representations from the same construction.

Figure: – Builder concept

To understand what we mean by construction and representation lets take the example of the below ‘Tea preparation’ sequence.

You can see from the figure ‘Tea preparation’ from the same preparation steps we can get three representation of tea’s (i.e. Tea with out sugar, tea with sugar / milk and tea with out milk).

Figure: – Tea preparation

Now let’s take a real time example in software world to see how builder can separate the complex creation and its representation. Consider we have application where we need the same report to be displayed in either ‘PDF’ or ‘EXCEL’ format. Figure ‘Request a report’ shows the series of steps to achieve the same. Depending on report type a new report is created, report type is set, headers and footers of the report are set and finally we get the report for display.

 

Figure: – Request a report

Now let’s take a different view of the problem as shown in figure ‘Different View’. The same flow defined in ‘Request a report’ is now analyzed in representations and common construction. The construction process is same for both the types of reports but they result in different representations.

Figure: – Different View

We will take the same report problem and try to solve the same using builder patterns. There are three main parts when you want to implement builder patterns.

• Builder: – Builder is responsible for defining the construction process for individual parts. Builder has those individual processes to initialize and configure the product.
• Director: – Director takes those individual processes from the builder and defines the sequence to build the product.
• Product: – Product is the final object which is produced from the builder and director coordination.

First let’s have a look at the builder class hierarchy. We have a abstract class called as ‘ReportBuilder’ from which custom builders like ‘ReportPDF’ builder and ‘ReportEXCEL’ builder will be built.

 

Figure: – Builder class hierarchy

Figure ‘Builder classes in actual code’ shows the methods of the classes. To generate report we need to first Create a new report, set the report type (to EXCEL or PDF) , set report headers , set the report footers and finally get the report. We have defined two custom builders one for ‘PDF’ (ReportPDF) and other for ‘EXCEL’ (ReportExcel). These two custom builders define there own process according to the report type.

Figure: – Builder classes in actual code

Now let’s understand how director will work. Class ‘clsDirector’ takes the builder and calls the individual method process in a sequential manner. So director is like a driver who takes all the individual processes and calls them in sequential manner to generate the final product, which is the report in this case. Figure ‘Director in action’ shows how the method ‘MakeReport’ calls the individual process to generate the report product by PDF or EXCEL.

The third component in the builder is the product which is nothing but the report class in this case.

 

Figure: – The report class

Now let’s take a top view of the builder project. Figure ‘Client,builder,director and product’ shows how they work to achieve the builder pattern. Client creates the object of the director class and passes the appropriate builder to initialize the product. Depending on the builder the product is initialized/created and finally sent to the client.

Figure: – Client, builder, director and product 

The output is something like this. We can see two report types displayed with their headers according to the builder.

Figure: – Final output of builder

 

 

Source -http://ashishkhandelwal.arkutil.com/?p=1076

Pin it

Posted on

Three main categories of design patterns?


There are three basic classifications of patterns Creational, Structural, and Behavioral patterns.
Creational Patterns

• Abstract Factory:- Creates an instance of several families of classes
• Builder: – Separates object construction from its representation
• Factory Method:- Creates an instance of several derived classes
• Prototype:- A fully initialized instance to be copied or cloned
• Singleton:- A class in which only a single instance can exist

Note: – The best way to remember Creational pattern is by ABFPS (Abraham Became First President of States).
Structural Patterns

• Adapter:-Match interfaces of different classes.
• Bridge:-Separates an object’s abstraction from its implementation.
• Composite:-A tree structure of simple and composite objects.
• Decorator:-Add responsibilities to objects dynamically.
• Façade:-A single class that represents an entire subsystem.
• Flyweight:-A fine-grained instance used for efficient sharing.
• Proxy:-An object representing another object.

Note : To remember structural pattern best is (ABCDFFP)
Behavioral Patterns

• Mediator:-Defines simplified communication between classes.
• Memento:-Capture and restore an object’s internal state.
• Interpreter:- A way to include language elements in a program.
• Iterator:-Sequentially access the elements of a collection.
• Chain of Resp: – A way of passing a request between a chain of objects.
• Command:-Encapsulate a command request as an object.
• State:-Alter an object’s behavior when its state changes.
• Strategy:-Encapsulates an algorithm inside a class.
• Observer: – A way of notifying change to a number of classes.
• Template Method:-Defer the exact steps of an algorithm to a subclass.
• Visitor:-Defines a new operation to a class without change.

Note: – Just remember Music……. 2 MICS On TV (MMIICCSSOTV).

Posted on

Factory method pattern in Java

The factory method pattern is an object-oriented design pattern to implement the concept of factories. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. 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. The factory method design pattern handles these problems by defining a separate method for creating the objects, which subclasses can then override to specify the derived type of product that will be created.

Factory pattern comes into creational design pattern category, the main objective of the creational pattern is to instantiate an object and in Factory Pattern an interface is responsible for creating the object but the sub classes decides which class to instantiate. It is like the interface instantiate the appropriate sub-class depending upon the data passed. Here in this article we will understand how we can create an Factory Pattern in Java

The essence of the Factory method Pattern is to “Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses

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.

printSomething.java 

package techartifact.pattern.factory;

public abstract class PrintSomething {

public abstract void printTech();
}

Now we will have the concrete implementations of the PrintSomething class, JavaTech and J2eeTech, each providing a much simplified implementation for the printTech() method.

JavaTech.java

package techartifact.pattern.factory;

public class JavaTech extends PrintSomething {
@Override
 public void printTech()
 {
 System.out.println("this is java technology");
 }
}

We will having one more class for j2eeTech for j2ee technology.
J2eeTech.java 

package techartifact.pattern.factory;

public class J2eeTech extends PrintSomething {
 public void printTech()
 {
     System.out.println("this is j2ee technology");
 }
}

Now let us come to the core implementation, the Factory class itself. The PrintFactory class has one static method called showPrint() which the clients can invoke to get the PrintSomething object. Note the return type of the method, it is neither JavaTech nor J2eeTech, but the super type of the both, i.e, PrintSomething. Whether the return type of method is JavaTech or J2eeTech is decided based on the input operating system.

PrintFactory.java 

package techartifact.pattern.factory;

public class PrintFactory {

public static PrintSomething showPrint(String os){

   if (os.equals("Java"))
  {

        return new JavaTech();

  }
   else if (os.equals("J2ee"))
  {

    return new J2eeTech();

  }

return null

 }

}

In this we can makes use of the above PrintFactory class. The client is un-aware of the fact there is multiple implementations of the PrintSomething class. It accesses the printTech() operation through a single unified type PrintSomething

FactoryClient.java

package techartifact.pattern.factory;

public class FactoryClient {

  public static void main(String[] args) {

             PrintSomething psJava =PrintFactory.showPrint("Java");

             psJava.printTech();

             PrintSomething psJ2ee = PrintFactory.showPrint("J2ee");

             psJ2ee.printTech();

   }
}