Factory Method VS Simple Factory

Factory Method VS Simple Factory

While taking Interview of a senior developer, Often I asked a question to the candidate that do you know Design pattern?

They Said yes and then I ask them what are some design patterns you familiar with and use in your project?

Most of the cases I got answer Factory pattern and Singleton Pattern!!!.


As this is an article on Factory I just ignore Singleton interview discussion here.

Next question from my side is, tell me a business case and write down code fragments for Factory method.

But unfortunately, they gave the example of Shape a well-known example in google, and end up with writing a Simple factory which is not considered as a Design pattern :).

In this article, I will not show How to write Simple factory or Factory method rather than I will discuss what are they exactly and when to use them.


In the course of taking  interviews, I realize some points,
  1. we are actually trying to memorize the Design pattern not able to understand what the problem context it tries to solve.
  2. Another realization is we are not analyzing the Business justification first and then apply pattern based on this rather we try to find where in the business requirements we can fit the pattern that I know.




Simple Factory:

When To Use: If your program only bothers about creating a family of Products so a client of your code can get any products of that family at runtime you should use the Simple factory.




Coding :

To achieve the same, we create an interface where we define the set of methods which are required for creating the desired Products, Those methods implementation can be varied in Actual implementations.


Now, We will Create a TopLevel class which usually has a Static method where the client passes the desired parameter to get the Actual implementation.

Please Note that Simple factory uses a Static method and returns the actual implementation based on the parameter pass by a client. Here Client may be another code which uses your API or a request from The Web etc.

Coding Template :

Say we want to create TV and our client want to get different kinds of TV from our program like LCD, LED, Black&White, COLOR,3D etc.

So we will create an Interface ITV which has a method createTV(),
Children of ITV interface actually provide the implementation of createTV() and client calls them through a static method by passing parameter(main method).



Interface

/**
*
*/
package com.example.factory;

/**
* @author Shamik Mitra
*
*/
public interface ITV {
   
    public void createTV();

}


SimpleFactory


/**
*
*/
package com.example.factory;

/**
* @author Shamik Mitra
*
*/
public class TVSimpleFactory {
   
    enum TVMODE{COLOR,LED,LCD,THREEDIM};
   
    public static ITV getTV(TVMODE mode){
       
        if(mode.equals(TVMODE.LED)){
            return new ITV(){

                @Override
                public void createTV() {
                    System.out.println("LED TV");
                   
                }
               
            };
        }
        return null;
    }
   
    public static void main(String[] args) {
        TVSimpleFactory.getTV(TVMODE.LED).createTV();
    }

}


Justification :

By Simple Factory, we abstract the creation of the product from our client. Only our client knows, by calling the Static method and passing the desired parameter it gets an Object of that TV type. But How TV is created client code does not know, Actually they are also least bother to know How you produce that product. I only care for my SONY LED not How they create the same.

So whenever you see there are chances to create many types of implementation of an Object use Simple factory there But hey don’t take this as a Silver bullet. Try to understand the business justification then apply the pattern on it may be it is provocative to use Simple factory for a Business requirements but it may happen you are thinking of a small scope but at a broader scope that will hurt your design , read the next to see how a simple change in business requirements can change the design.


Factory Method:


When To Use: If Business needs more than Object creation, to be precise If you want to control the creation process and control the use case where any parts of the use case can be customized we use the Factory method. To put it simple way, If you want to control an Algorithm/Strategy on a family of products. you can think factory method pattern and it plays very well with Template pattern where Template method control the Strategy/Algorithm and it steps are abstract which can be created in an actual implementation of Factory.

Use Factory method when you want to make a Framework where you want to take a control from creation of the Object to management of that Object, unlike Simple factory where you only bother about the creation of product not How to create and manage it.

Recall The Headfirst Pizza Example where orderPizza() method,  create Pizza then bake cut and Box it. So it is nothing but an Algorithm which stays same for all Pizza and orderPizza is a template Method.

But you can also add an abstract method called applyTax() method in orderPizza(), in the actual implementations of the factory you can apply tax decision on Region basis,  So I can tell I can have fine control over Pizza  Lifecycle,  Not only the creation also the management part.


Back to our Example. Now If Our Business requirements want we not only Create the TV also take orders and Ship the TV and based on the city shipping charge is applicable.

So, It is clear now we need to create an algorithm which will create Different Tv and shipped them and calculate Shipping charge so factory method is ideal here we can't do it by Simple Factory so change is needed in design


Coding : We create an Interface for Product. Actual implementation create concrete product along with this also we create an abstract class called factory where
We maintain the algorithm in a template method and abstract the product creation and necessary part of the strategy  so in the subclass of the factory we can implement them according to business requirement.



Coding Template :

Interface of Product

/**
*
*/
package com.example.factory;

/**
* @author Shamik Mitra
*
*/
public interface ITV {
   
    public void createTV();

}


AbstractFactory Class

/**
*
*/
package com.example.factory;

import com.example.factory.TVSimpleFactory.TVMODE;

/**
* @author Shamik Mitra
*
*/
public abstract class AbstractFactory {

    public final void orderTV() {
        createTV();
        int charge= shippingCharge();
        System.out.println("Shipping charge :: " + charge + " INR");

    }

    protected abstract int shippingCharge();

    protected abstract void createTV();

}



Concrete Factory

/**
*
*/
package com.example.factory;


/**
* @author Shamik Mitra
*
*/
public class LEDTVFactory extends AbstractFactory {
    @Override
    public int shippingCharge() {
        // TODO Auto-generated method stub
        return 1000;
    }

    @Override
    public void createTV() {

        new ITV() {
            @Override
            public void createTV() {
                System.out.println("LED TV");

            }

        }.createTV();

    }

    public static void main(String[] args) {
        AbstractFactory factory = new LEDTVFactory();
        factory.orderTV();
    }
}

Justification : By Factory method, we not only abstract the Product creation but take one step further here we also abstract the factory which creates the product. So the benefits are that we can control the creation of Product and management of the product. If you see the above code you can see We abstract the factory with the ITV interface and in the Abstract factory, we create a template method which controls the TV lifecycle -- create TV and Shipping cost calculation and make them abstract so Children of Abstract factory can change them accordingly.

We can say Factory method Abstract the Creator from the caller. One level more abstract than Simple factory.

Benefits:

Create a Framework.
Control Product lifecycle.


TIP: If you only deal with the family of products go for Simple Factory but If you need to control the product creation and management go for Factory method.


































Hello, Hexagonal Architecture

Hello Hexagonal Architecture


While developing a software we always craving for Architecture because we want our software adopts future changes easily.

So, Architecture stepped in for maintainability. Here maintainability mean how easily we can incorporate changes without disturbing old.

Every feature addition in a software comes with a Risk, Risk of breaking old,maintainability,rigidity,dependencies etc, There are many shades of risks
we called it Technical debt.


Technical debt has an inverse relationship of maintainability, using Architectural style we want to decrease the risk or I can say make it constant while adding new features.

We experienced that when we start writing code at that time it is easy to add features and gradually it becomes hard unless we do not use proper architecture for that software.


Hexagonal Architecture:

We will discuss Hexagonal Architecture here, in one word Hexagonal Architecture says.

Core business logic talks to other through a contract.

The core business logic means your software development logic should talk to others means Database or any JMS Queues or any Flat files or HTTP request or FTP , NOSQL etc through a contract or in Java language we can say interface.

The benefits of above type of design is whatever the input or output channels that boil down to the contract so every channel has to implement that contract/interface to talking with our software, So for our software perspective all are same as all implement the same contract so our software can deal with any types of input and output channel .

Benefits:

1, Easily incorporates any channel like Flat file,RDBMS, NoSQL, Http,Ftp,JMS etc.
2. Our software can be easily tested because it is easy to create a mock as just need to implement the contracts.

3. Adding new requirements means plugging it, or implementing the contracts.
4. Proper separation of concern.
5. Maintains IOC as Higher level and lower level talking through contract.


Sometimes we called Hexagonal architecture as Port and Adapter or Onion architecture.

As in this architecture, we have a port for each channel say for Database

The tasks we have to perform

To implement the contract to talk with our software.
As database API say JDBC is itself a contract or Hibernate is itself a framework so we need to create an adaptor GOF adapter pattern where we have to implement a strategy which converts JDBC related operation to our contract related operation.
Then plug this adaptor into our port to talk with this channel.



Outline of the design

Software Contract

package com.example.architecture.hexagonal;

public interface IPersists<T,TCOMMAND> {
   
   public void save(T t,TCOMMAND commandObject);    
   public void delete(T t,TCOMMAND commandObject);
   

}

This is the general contract for talking with our software, any output channel like File channel, RDBMS,NoSQL should implement that contract.


Here I take an example How it can talk to JPA entity which saves that data in Database.

DataBaseChannelAdapter.java
package com.example.architecture.hexagonal;

public class DataBaseChannelAdapter implements IPersists<EmployeeDomainObject,EmployeeCommand>{

   public void save(EmployeeDomainObject t, EmployeeCommand commandObject) {
     
       String underLyingJPAEntity = commandObject.getEntityClass();
       System.out.println("call save on " + underLyingJPAEntity);
     
   }

   public void delete(EmployeeDomainObject t, EmployeeCommand commandObject) {
       String underLyingJPAEntity = commandObject.getEntityClass();
       System.out.println("call delete on " + underLyingJPAEntity);
     
   }

}


As JPA Entity use some JPA related annotation so I did not include this JPA entity as part of our Domain, I use JPA framework as an Outside Channel of our software domain and DataBaseChannelAdapter takes our core domain Employee Object and takes a Command Object which tells Adapter to Which JPA entity to call and call the same.


EmployeeDomainObject

package com.example.architecture.hexagonal;

public class EmployeeDomainObject {
   
   public String name;
   public String address;
   public String getName() {
      return name;
   }
   public void setName(String name) {
      this.name = name;
   }
   public String getAddress() {
      return address;
   }
   public void setAddress(String address) {
      this.address = address;
   }
   @Override
   public String toString() {
      return "EmployeeDomainObject [name=" + name + ", address=" + address
              + "]";
   }
   
   

}


Our core Domain Employee Object it does not dependent on any Framework so I can plug any framework with it through Adapter like I can easily change DatabaseAdapter to FileAdepter to save our core domain object in File.




EmployeeCommand.java

package com.example.architecture.hexagonal;

public class EmployeeCommand{
   
   public String entityClass;

   
   
   public String getEntityClass() {
      return entityClass;
   }

   public void setEntityClass(String entityClass) {
      this.entityClass = entityClass;
   }

   @Override
   public String toString() {
      return "EmployeeCommand [entityClass=" + entityClass + "]";
   }

   
   

}





This Command object is nothing but help Adapter to convert Core Domain Object to Underlying Output channel (Database or File)

EmployeeDomainDao.java

package com.example.architecture.hexagonal;

public class EmployeeDomainDao<T,TCommand>{
   
   IPersists<T,TCommand> adapter;
   
   
   public void save(T t,TCommand commandObject)
   {
      adapter.save(t, commandObject);
   }
   
   public void delete(T t,TCommand commandObject)
   {
      adapter.delete(t, commandObject);
   }

   public IPersists<T, TCommand> getAdapter() {
      return adapter;
   }

   public void setAdapter(IPersists<T, TCommand> adapter) {
      this.adapter = adapter;
   }
   
   
   

}
This is our Core Domain Persist layer here I use the adapter as Strategy based on the Adapter it will call exact output channel and persist our Domain Object.





Now Time to Test our Software design


Main.java

package com.example.architecture.hexagonal;

public class Main {
   
   public static void main(String[] args) {
      EmployeeDomainDao<EmployeeDomainObject,EmployeeCommand> dao = new EmployeeDomainDao<EmployeeDomainObject,EmployeeCommand>();
      IPersists<EmployeeDomainObject,EmployeeCommand> adapter= new DataBaseChannelAdapter();
      dao.setAdapter(adapter);
      EmployeeDomainObject emp = new EmployeeDomainObject();
      emp.setName("Shamik Mitra");
      emp.setAddress("India,Kolkata");
     
      EmployeeCommand command = new EmployeeCommand();
      command.setEntityClass("com.employeemanagement.entity.EmployeeJpaEntity");
     
      dao.save(emp, command);
      dao.delete(emp, command);
   }

}








Output:

Object StateEmployeeDomainObject [name=Shamik Mitra, address=India,Kolkata]
call save on com.employeemanagement.entity.EmployeeJpaEntity
Object StateEmployeeDomainObject [name=Shamik Mitra, address=India,Kolkata]
call delete on com.employeemanagement.entity.EmployeeJpaEntity





Hexagonal Layers :






Hexagonal architecture,port & adapter architecture,onion Arhitechture

Picture courtesy Google



Application Domain: As I said earlier it is the software where all software related business logic, validation goes on, this is the inside module every outside module talks with it through contract.

Application/Mediation Layer:  Kind of services layer it adopts the Framework layer or ut’s outside layer and make necessary changes according to domain layer contract to talks with Domain layer or in the same way return back the result from Domain to Framework layer.
It sits between Framework and Domain layer.


Framework Layer: This layer as to input/output channel or we can say the outside world and use an adaptor to adapt the data and transform it according to our  software contract.