Factory Pattern

Definition -
   
    When you can abstract the functionalities and use that object to call other classes which implement the

Scenario -

    Let us take an example of the production line itself, where the client places an order for a vehicle and depending on the order a hatchback or a sedan car is created.
In this case -
1. A abstract class called carmanufacture which have an execute funtion to process the request of the client. 

package SimpleFactoryPattern;

public class hatchback extends carmanufacture{

    @Override
    public void manufacture() {
        
        System.out.println("Manufacturing hatchback");
        
    }

}

2. There are two sub classes called hatchback and sedan which will extend the abstract class.

hatchback.java

package SimpleFactoryPattern;

public class hatchback extends carmanufacture{

    @Override
    public void manufacture() {
        
        System.out.println("Manufacturing hatchback");
        
    }

}

sedan.java    

package SimpleFactoryPattern;

public class sedan extends carmanufacture {

    @Override
    public void manufacture() {
        
        System.out.println("Manufacturing sedan");
        
    }
    
    

}

3. To see the pattern in action use the following code - 

package SimpleFactoryPattern;

public class factorydemo {
    
    public static void main(String args[]) {
        
        carmanufacture car=null;
        
        String order = "Hatchback";
        
        if(order.equalsIgnoreCase("Hatchback")) {
            car = new hatchback();
            
        }
        
        else if(order.equalsIgnoreCase("Sedan")) {
            car=new sedan();
        }
        
        car.manufacture();
        
    }

}

Place to use -
1) When you want the client to decide on the sub class at run time.
2) When you can abstract a class and there is not too much deviation in the way the different sub classes work.

Place not to use -
1) Can easily over complicate design.
2) When there are too many changes and each change introduces few attributes / functionalities not used by others then it might result in change.

Builder Pattern

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.

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.