Definition -
As the name suggests this pattern builds an object in a step by step manner. The pattern will follow a series of steps defined hence the designer should define a sequence. This pattern allows more granular control over the system. In this pattern there will be a director, a builder and a client. The client issues a request,
The director will order the builder to build an object according to the request and submits to the client. This pattern helps to simplify construction of a complex object into small easier steps.
Scenario -
Lets take an example of assembly line where in you want the software to take care of constructing different vehicles like hatchback or sedan.
Based on this if we have to use this pattern to design the software then -
1. We need to have a interface which will provide the standard steps for constructing the vehicles. Let us call this interface as vehiclebuilder.
2. We need to have concerete classes which will implement the builder class. Let us call these classes as hatchback builder and sedanbuilder.
hatchback.java
sedanbuilder.java
3. We will have a director who is responsible for invoking the classes based on the order it recieves from the client.
The client code will look -
Place to use -
1. To be used when creation has to be decoupled from the system.
2. When you need to add flexbility to add new functionality without affecting the system.
3. When you need more granular control over the runtime creation of objects.
Place not to use -
1. Too much flexbility and decoupling may add to complexity. This might result in maintainence overhead.
As the name suggests this pattern builds an object in a step by step manner. The pattern will follow a series of steps defined hence the designer should define a sequence. This pattern allows more granular control over the system. In this pattern there will be a director, a builder and a client. The client issues a request,
The director will order the builder to build an object according to the request and submits to the client. This pattern helps to simplify construction of a complex object into small easier steps.
Scenario -
Lets take an example of assembly line where in you want the software to take care of constructing different vehicles like hatchback or sedan.
Based on this if we have to use this pattern to design the software then -
1. We need to have a interface which will provide the standard steps for constructing the vehicles. Let us call this interface as vehiclebuilder.
package BuilderPattern;
public interface vehiclebuilder {
public void buildengine();
public void buildchassis();
public void assemble();
}
2. We need to have concerete classes which will implement the builder class. Let us call these classes as hatchback builder and sedanbuilder.
hatchback.java
package BuilderPattern;
public class hatchbackbuilder implements vehiclebuilder {
@Override
public void buildengine() {
System.out.println("Building engine for a hatchback");
}
@Override
public void buildchassis() {
System.out.println("Building chassis for a hatchback");
}
@Override
public void assemble() {
System.out.println("Assembling a hatchback");
}
}
sedanbuilder.java
package BuilderPattern;
public class sedanbuilder implements vehiclebuilder {
@Override
public void buildengine() {
System.out.println("Building engine for a sedan");
}
@Override
public void buildchassis() {
System.out.println("Building chassis for a sedan");
}
@Override
public void assemble() {
System.out.println("Assembling a sedan");
}
}
3. We will have a director who is responsible for invoking the classes based on the order it recieves from the client.
package BuilderPattern;
public class builddirector {
public void createvehicle(vehiclebuilder vb) {
vb.buildengine();
vb.buildchassis();
vb.assemble();
}
}
The client code will look -
package BuilderPattern;
public class builderpatterndemo {
public static void main(String args[]) {
builddirector bd=new builddirector();
vehiclebuilder builder=null;
builder=new hatchbackbuilder();
bd.createvehicle(builder);
}
}
Place to use -
1. To be used when creation has to be decoupled from the system.
2. When you need to add flexbility to add new functionality without affecting the system.
3. When you need more granular control over the runtime creation of objects.
Place not to use -
1. Too much flexbility and decoupling may add to complexity. This might result in maintainence overhead.
No comments:
Post a Comment