By definition, a design pattern is a set of proven de facto industry standards and best practices for resolving recurring problems. Design patterns are not ready-made solutions. Rather, they're a way or template to implement and apply the best possible solution for your problem.

It's equally true that if a design pattern is not implemented in the right way, it creates a lot of problems rather than solving the one you expected to solve. So it's very important to know which design pattern, if any, is right for a specific scenario.

Design patterns are a common paradigm to describe the problem and how to solve it. It's usually not language specific. Design patterns can protect you from the design problems that generally occur in the later stages of development.

There are numerous advantages to using design patterns, as follows:

• Improves software reusability
• Development cycle becomes faster
• Makes the code more readable and maintainable
• Increases the efficiency and enhances the overall software development
• Provides common vocabulary to describe problems and best possible solutions in a more abstract way

And you can count many more. In the following sections, we will gain a deep understanding of how to make your code modular, loosely coupled, independent, testable, and maintainable, by following certain principles and patterns.

This chapter will cover in-depth ideas about the Dependency Inversion Principle (DIP), the Inversion of Control paradigm, and DI design pattern.

Design principle: Generically, this is a guideline about what is the right way and what is the wrong way to design your application. Design principles always talk about what to do instead of how to do it.

Design patterns: A generic and reusable solution for commonly occurring problems. Design patterns talk about how to solve the problems in a given software design context by providing clear methodologies.

The first step towards making your code cleaner, readable, decoupled, maintainable, and modular is to learn the design principle called DIP.

DIP provides high-level guidance to make your code loosely coupled. It says the following:

• High-level modules should not depend on low-level modules for their responsibilities. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

Changes are always risky when they're made in dependent code. DIP talks about keeping a chunk of code (dependency) away from the main program to which it is not directly related. 

To reduce the coupling, DIP suggests eliminating the direct dependency of low-level modules on high-level modules to perform their responsibilities. Instead, make the high-level module rely on abstraction (a contract) that forms the generic low-level behavior. 

This way, the actual implementation of low-level modules can be changed without making any changes in high-level modules. This produces great flexibility and molecularity in the system. As far as any low-level implementation is bound to abstraction, high-level modules can invoke it.

Let's have a look at a sample suboptimal design where we can apply DIP to improve the structure of the application.

Consider a scenario where you are designing a module that simply generates balance sheets for a local store. You are fetching data from a database, processing it with complex business logic, and exporting it into HTML format. If you design this in a procedural way, then the flow of the system would be something like the following diagram:

A single module takes care of fetching data, applying business logic to generate balance sheet data, and exporting it into HTML format. This is not the best design. Let's separate the whole functionality into three different modules, as shown in the following diagram:

• Fetch Database Module : This will fetch data from a database
• Export HTML Module:  This will export the data in HTML
• Balance Sheet Module: This will take data from a database module, process it, and give it to the export module to export it in HTML

In this case, the balance sheet module is a high-level module, and fetch database and export HTML are low-level modules.

The code of the FetchDatabase module should look something like the following snippet:

public class FetchDatabase {
    public List<Object[]> fetchDataFromDatabase(){
         List<Object[]> dataFromDB = new ArrayList<Object[]>();
         //Logic to call database, execute a query and fetch the data
         return dataFromDB;
     }
}

The ExportHTML module will take the list of data and export it into HTML file format. The code should look as follows:

public class ExportHTML {
    public File exportToHTML(List<Object[]> dataLst){
        File outputHTML = null;
        //Logic to iterate the dataLst and generate HTML file.
        return outputHTML;
     }
}

The code for our parent module—the BalanceSheet module that takes the data from the fetch database module and sends to the export HTML module—should look as follows:

public class BalanceSheet {
    private ExportHTML exportHTML = new ExportHTML();
    private FetchDatabase fetchDatabase = new FetchDatabase();
    
    public void generateBalanceSheet(){
      List<Object[]> dataFromDB =
      fetchDatabase.fetchDataFromDatabase();
        exportHTML.exportToHTML(dataFromDB);
     }
}

At first glance, this design looks good, as we separated the responsibilities of fetching and exporting the data into individual child modules. Good design can accommodate any future changes without breaking the system. Will this design make our system fragile in case of any future changes? Let us have a look at that.

After some time, you need to fetch the data from external web services along with the database. Also, you need to export the data in PDF format rather than HTML format. To incorporate this change, you will create new classes/modules to fetch data from web services and to export the PDF as per the following snippet:

// Separate child module for fetch the data from web service.
public class FetchWebService {
    public List<Object[]> fetchDataFromWebService(){
         List<Object[]> dataFromWebService = new ArrayList<Object[]>();
        //Logic to call Web Service and fetch the data and return it. 
        return dataFromWebService;
     }
}
// Separate child module for export in PDF
public class ExportPDF {
    public File exportToPDF(List<Object[]> dataLst){
        File pdfFile = null;
        //Logic to iterate the dataLst and generate PDF file
        return pdfFile;
    }
}

To accommodate the new ways of fetching and exporting data, the balance sheet module needs some sort of flag. Based on the value of this flag, the respective child module will be instantiated in the balance sheet module. The updated code of the BalanceSheet module would be as follows:

public class BalanceSheet {

  private ExportHTML exportHTML = null;
  private FetchDatabase fetchDatabase = null;
  private ExportPDF exportPDF = null;
  private FetchWebService fetchWebService = null;

  public void generateBalanceSheet(int inputMethod, int outputMethod){
    
    //1. Instantiate the low level module object.
    if(inputMethod == 1){
      fetchDatabase = new FetchDatabase();
    }else if(inputMethod == 2){
      fetchWebService = new FetchWebService(); 
    }
    
    //2. fetch and export the data for specific format based on flags. 
    if(outputMethod == 1){
        List<Object[]> dataLst = null;
        if(inputMethod == 1){
          dataLst = fetchDatabase.fetchDataFromDatabase();
        }else{
          dataLst = fetchWebService.fetchDataFromWebService();
        }
      exportHTML.exportToHTML(dataLst);
    }else if(outputMethod ==2){
        List<Object[]> dataLst = null;
        if(inputMethod == 1){
          dataLst = fetchDatabase.fetchDataFromDatabase();
        }else{
          dataLst = fetchWebService.fetchDataFromWebService();
        }
      exportPDF.exportToPDF(dataLst);
    }
    
  }
}

Great work! Our application is able to handle two different input and output methods to generate balance sheets. But wait a minute; what happens when you need to add more  methods (fetch and export data) in the future? For example, you might need to fetch the data from google drive and export the balance sheet in Excel format.

For every new method of input and output, you need to update your main module, the balance sheet module. When a module is dependent on another concrete implementation, it's said to be tightly coupled on that. This breaks the fundamental principle: open for extension but closed for modification.

Let's recall what DIP talks about: high-level modules should not depend on low-level modules for their responsibilities. Both should depend on abstractions.

This is the fundamental problem in our design. In our case, the balance sheet (high-level) module tightly depends on fetch database and export HTML data (low-level) modules.

As we have seen, principles always show the solution to design problems. It doesn't talk about how to implement it. In our case, DIP talks about removing the tight dependency of low-level modules on high-level modules.

But how do we do that? This is where IoC comes into the picture. IoC shows a way of defining abstraction between modules. In short, IoC is the way to implement DIP.

IoC is a design methodology used to build a loosely coupled system in software engineering by inverting the control of flow from your main program to some other entity or framework.

Here, the control refers to any additional activities a program is handling other than its main activities, such as creating and maintaining the dependency objects, managing the application flow, and so on.

Unlike procedural programming style, where a program handles multiple unrelated things all together, IoC defines a guideline where you need to break the main program in multiple independent programs (modules) based on responsibility and arrange them in such a way that they are loosely coupled.

In our example, we break the functionality into separate modules. The missing part was how to arrange them to make them decoupled, and we will learn how IoC makes that arrangement. By inverting (changing) the control, your application becomes decoupled, testable, extensible, and maintainable.

DIP suggests that high-level modules should not depend on low-level modules. Both should depend on abstraction. IoC provides a way to achieve the abstraction between high-level and low-level modules.

Let's see how we can apply DIP through IoC on our Balance Sheet example. The fundamental design problem is that high-level modules (balance sheet) tightly depend on low-level (fetch and export data) modules.

Our goal is to break this dependency. To achieve this, IoC suggests inverting the control. In IoC, inverting the control can be achieved in the following ways:

• Inverting the interface: Make sure the high-level module defines the interface, and low-level modules follow it
• Inverting object creation: Change the creation of dependency from your main modules to some other program or framework
• Inverting flow: Change the flow of application

Inverting the interface means inverting the interaction control from low-level modules to high-level modules. Your high-level module should decide which low-level modules can interact with it, rather than keep changing itself to integrate each new low-level module.

After inverting the interface, our design would be as per the following diagram:

In this design, the balance sheet module (high-level) is interacting with fetch data and export data (low-level) modules with common interface. The very clear benefits of this design are that you can add new fetch data and export data (low-level) modules without changing anything on the balance sheet module (high-level).

As far as low-level modules are compatible with the interface, the high-level modules will be happy to work with it. With this new design, high-level modules are not dependent on low-level modules, and both are interacting through an abstraction (interface). Separating the interface from the implementation is a prerequisite to achieve DIP.

Let's change our code as per this new design. First, we need to create two interfaces: to fetch the data and export the data as follows:

public interface IFetchData {
    //Common interface method to fetch data. 
    List<Object[]> fetchData();
}
public interface IExportData { 
    //Common interface method to export data. 
    File exportData(List<Object[]> listData);
}

Next, all low-level modules must implement these interfaces as per the following snippet:

public class FetchDatabase implements IFetchData {
    public List<Object[]> fetchData(){
         List<Object[]> dataFromDB = new ArrayList<Object[]>();
         //Logic to call database, execute a query and fetch the data
         return dataFromDB;
     }
}

public class FetchWebService implements IFetchData {
    public List<Object[]> fetchData(){
         List<Object[]> dataFromWebService = new ArrayList<Object[]>();
        //Logic to call Web Service and fetch the data and return it. 
        return dataFromWebService;
     }
}

public class ExportHTML implements IExportData{
    public File exportData(List<Object[]> listData){
        File outputHTML = null;
        //Logic to iterate the listData and generate HTML File
        return outputHTML;
    }
}
public class ExportPDF implements IExportData{
     public File exportData(List<Object[]> dataLst){
        File pdfFile = null;
        //Logic to iterate the listData and generate PDF file
        return pdfFile;
     }

}

Finally, the balance sheet  module needs to rely on interfaces to interact with low-level modules. So the updated BalanceSheet module should look like the following snippet:

public class BalanceSheet {
  private IExportData exportDataObj= null;
  private IFetchData fetchDataObj= null;
 
  public Object generateBalanceSheet(){
    List<Object[]> dataLst = fetchDataObj.fetchData();
    return exportDataObj.exportData(dataLst);
  }
}

You may have observed that, the generateBalanceSheet() method became more straightforward. It allows us to work with additional fetch and export modules without any change. It is thanks to the mechanism of inverting the interface that makes this possible.

This design looks perfect; but still, there is one problem. If you noticed, the balance sheet module is still keeping the responsibility of creating low-level module objects (exportDataObj and fetchDataObj). In other words, object creation dependency is still with the high-level modules.

Because of this, the Balance Sheet module is not 100 percent decoupled from the low-level modules, even after implementing interface inversion. You will end up instantiating low-level modules with if/else blocks based on some flag, and the high-level module keeps changing for adding additional low-level modules integration.

To overcome this, you need to invert the object creation from your higher-level module to some other entity or framework. This is the second way of implementing IoC.

Once the abstraction between modules is set, there is no need to keep the logic of creating dependency objects in higher-level modules. Let us understand the importance of inversion of object creation design with one more example.

Suppose you are designing a war game. Your player can shoot the enemy with various weapons. You created separate classes (low-level module) for each of the weapons. While playing the game, your player can add the weapon based on points earned.

Also, the player can change the weapon. To implement inversion of interface, we created an interface called Weapon, which will be implemented by all weapon modules, as per the following diagram:

Assume that there are three weapons initially that you kept in the game. If you keep weapon creation code in your player module, the logic of choosing a weapon would be as per the following snippet:

public class Player {
  private Weapon weaponInHand;
  public void chooseWeapon(int weaponFlag){
    if(weaponFlag == 1){
      weaponInHand = new SmallGun();
    }else if(weaponFlag ==2){
      weaponInHand = new Rifle();
    }else{
      weaponInHand = new MachineGun();
    }
  }
  
  public void fireWeapon(){
    if(this.weaponInHand !=null){
      this.weaponInHand.fire();
    }
  }
}

Since the player module is taking care of creating the object of weapons, we are passing a flag in the chooseWeapon() method. Let us assume that, over a period of time, you add a few more weapons to the game. You end up changing the code of the Player module every time you add a new weapon.

The solution to this problem is to invert the object creation process from your main module to another entity or framework.

Let's first apply this solution to our Player module. The updated code would be as follows:

public class Player {
  private Weapon weaponInHand; 
  public void chooseWeapon(Weapon setWeapon){
    this.weaponInHand = setWeapon;
  }
  
  public void fireWeapon(){
    if(this.weaponInHand !=null){
      this.weaponInHand.fire();
    }
  }
}

You can observe the following things:

• In the chooseWeapon() method, we are passing the object of weapons through the interface. The Player module is no longer handling the creation of weapon objects.
• This way, the Player (higher-level) module is completely decoupled from Weapon (low-level) modules.
• Both modules interact through the interface, defined by higher-level modules.
• For any new weapon added into the system, you do not need to change anything in the player module.

Let's apply this solution (invert creating object) to our balance sheet module. The updated code for the BalanceSheet module would be as per the following snippet:

public class BalanceSheet {

  private IExportData exportDataObj= null;
  private IFetchData fetchDataObj= null;
  
  //Set the fetch data object from outside of this class.
  public void configureFetchData(IFetchData actualFetchDataObj){
    this.fetchDataObj = actualFetchDataObj;
  }
  //Set the export data object from outside of this class.
  public void configureExportData(IExportData actualExportDataObj){
    this.exportDataObj = actualExportDataObj;
  }
  
  public Object generateBalanceSheet(){
    List<Object[]> dataLst = fetchDataObj.fetchData();
    return exportDataObj.exportData(dataLst);
  }
}

Here are some quick observations:

• Objects of fetch data and export data modules are created outside the balance sheet module, and passed through configureFetchData() and configureExportData() methods
• The balance sheet module is now  100 percent decoupled from fetch data and export data modules
• For any new type of fetch and export data, no change is required in balance sheet modules

At this moment, the relation between DIP and IoC can be described as per the following diagram:

Finally, we implemented DIP through IoC and solved one of the most fundamental problems of interdependency between modules.

But hold on, something is not complete yet. We have seen that keeping the object creation away from your main module will eliminate the risk of accommodating changes and make your code decoupled. But we haven't explored how to create and pass the dependency object from outside code into your module. There are various ways of inverting object creation.

We have seen how inversion of object creation helps us to decouple the modules. You can achieve the inversion of object creation with multiple design patterns as follows:

• Factory pattern
• Service locator
• Dependency injection

The factory pattern takes the responsibility of creating an object from a client who uses it. It generates the object of classes that are following a common interface. A client has to pass only type of the implementation it wants and the factory will create that object.

If we apply the factory pattern to our balance sheet example, the process of inverting of object creation is depicted as per the following diagram:

• Client (in our case, it's a balance sheet module) talks to the factory—Hey factory, can you please give me the fetch data object? Here is the type.
• The factory takes the type, creates the object, and passes it to the client (the balance sheet module).
• The factory can create the object of the same type only.
• The factory class is a complete black box for its clients. They know it's a static method to get objects.

The Balance Sheet module can get FetchData objects from FetchDataFactory. The code of FetchDataFactory will be as follows:

public class FetchDataFactory {
  public static IFetchData getFetchData(String type){
    IFetchData fetchData = null;
    if("FROM_DB".equalsIgnoreCase(type)){
      fetchData = new FetchDatabase();
    }else if("FROM_WS".equalsIgnoreCase(type)){
      fetchData = new FetchWebService();
    }else {
      return null;
    }
    return fetchData;
  }
}

To use this factory, you need to update the configureFetchData() method of a balance sheet module as follows:

//Set the fetch data object from Factory.
  public void configureFetchData(String type){
    this.fetchDataObj = FetchDataFactory.getFetchData(type);
  }

For export data, you need to create a separate factory as per the following snippet:

public class ExportDataFactory {

  public static IExportData getExportData(String type){
    IExportData exportData = null;
    if("TO_HTML".equalsIgnoreCase(type)){
      exportData = new ExportHTML();
    }else if("TO_PDF".equalsIgnoreCase(type)){
      exportData = new ExportPDF();
    }else {
      return null;
    }
    return exportData;
  }
}

If a new fetch data or export data type is introduced, you need to change it in its respective factory class only.

The service locator pattern works more or less the same as to the factory pattern. The service locator can find the existing object and send it to the client rather than create a new one every time, as with the factory pattern. Instead of getting into detail, we will just look briefly at how the service locator works to create objects. The flow of the service locator can be described as per the following diagram:

• Client is relying on Service Locator to find services. Here, service means any kind of dependency
• Service Locator takes the name of the service, and returns the object of service back to the client

If our balance sheet module uses the service locator, the code of the configureFetchData() method would be like the following snippet:

//Set the fetch data object from ServiceLocator.
  public void configureFetchData(String type){
    this.fetchDataObj = FetchDataServiceLocator.Instance.getFetchData(type);
  }

Similar to fetch data, you need to design a separate service locator for export data. For any new fetch data or export data type, the changes need to be done in the service locator.

Another way of inverting the object creation is DI.

 DI is one of the ways to invert the object creation process from your module to other code or entity. The term injection refers to the process of passing the dependent object into a software component.

Since DI is one of the ways to implement IoC, it relies on abstraction to set the dependency. The client object doesn't know which class will be used to provide functionality at compile time. The dependency will be resolved at runtime.

A dependent object does not directly call to the client object; instead, the client object will call a dependent object whenever required. It's similar to the Hollywood principle: Don't call us, we'll call you when we need to.

In DI, you need to set the entry point in a client object from which the dependency can be injected. Based on these entry points, DI can be implemented with the following types:

• Constructor injection
• Setter injection
• Interface injection

This is the most common way to inject dependency. In this approach, you need to pass the dependent object through a public constructor of a client object. Please note that in case of construction injection, you need to pass all the dependency objects in the constructor of a client object.

Constructor injection can control the order of instantiation and consequently reduce the risk of circular dependency. All mandatory dependencies can be passed through constructor injection.

In our BalanceSheet example, we need to pass two objects in a constructor, because it has two dependencies: one is for fetch data, and the second is for export data types, as per the following snippet:

public class BalanceSheet {

  private IExportData exportDataObj= null;
  private IFetchData fetchDataObj= null;
  
  //All dependencies are injected from client's constructor 
  BalanceSheet(IFetchData fetchData, IExportData exportData){
    this.fetchDataObj = fetchData;
    this.exportDataObj = exportData;
  }
  
  public Object generateBalanceSheet(){
    List<Object[]> dataLst = fetchDataObj.fetchData();
    return exportDataObj.exportData(dataLst);
  }
}

All dependencies are injected from a constructor of a client object. Since constructors are called only once, it's clear that the dependency object will not be changed until the existence of a client object. If a client uses constructor injection, then extending and overriding it would be difficult sometimes.

As its name suggests, here dependency injection is done through setter methods exposed publicly. Any dependency not required at the time of client object instantiation is called optional dependency. They can be set at a later stage after a client object is created.

Setter injection is a perfect fit for optional or conditional dependency. Let's apply a setter injection to the BalanceSheet module.

The code would look as follows:

public class BalanceSheet {

  private IExportData exportDataObj= null;
  private IFetchData fetchDataObj= null;
  
  //Setter injection for Export Data 
  public void setExportDataObj(IExportData exportDataObj) {
    this.exportDataObj = exportDataObj;
  }

  //Setter injection for Fetch Data
  public void setFetchDataObj(IFetchData fetchDataObj) {
    this.fetchDataObj = fetchDataObj;
  }

  public Object generateBalanceSheet(){
    
    List<Object[]> dataLst = fetchDataObj.fetchData();
    return exportDataObj.exportData(dataLst);
  }
  
}

For each dependency, you need to put separate setter methods. Since the dependencies are set through the setter method, the object or a framework which supplies the dependencies need to call the setter methods at an appropriate time to make sure dependencies are available before a client object starts using it.

Interface injection defines a way by which the dependency provider should talk to a client. It abstracts the process of passing dependency. The dependency provider defines an interface that all clients need to implement. This method is not so frequently used.

Technically, interface injection and setter injection are the same. They both use some sort of method to inject dependency. However, for interface injection, the method is defined by objects which provide the dependency.

Let's apply interface injection to our balance sheet module:

public interface IFetchAndExport {
  void setFetchData(IFetchData fetchData);
  void setExportData(IExportData exportData);
}

//Client class implements interface
public class BalanceSheet implements IFetchAndExport {

  private IExportData exportDataObj= null;
  private IFetchData fetchDataObj= null;
  
  //Implements the method of interface injection to set dependency
  @Override
  public void setFetchData(IFetchData fetchData) {
    this.fetchDataObj = fetchData;
  }

  //Implements the method of interface injection to set dependency
  @Override
  public void setExportData(IExportData exportData) {
    this.exportDataObj = exportData;
    
  }

  public Object generateBalanceSheet(){
    List<Object[]> dataLst = fetchDataObj.fetchData();
    return exportDataObj.exportData(dataLst);
  }
}

We have created interface IFetchAndExport and defined methods to inject dependencies. The dependency provider class knows how to pass the dependency through this interface. Our client object (Balance Sheet module) implements this method to set dependencies.

So far, we have talked about the code or framework that plays the role of dependency provider. It can be any custom code or full-fledged IoC container. Some developers refer to it as a DI container, but we will simply call it a container.

If we write custom code to supply dependency, things get smoother until we have just a single level of dependency. Take the scenario where our client classes are also dependent of some other modules. This results in chained or nested dependencies.

In this situation, implementing dependency injection will become quite complicated through manual code. That is where we need to rely on containers. 

A container takes care of creating, configuring, and managing objects. You just need to do configuration, and the container will take care of object instantiation and dependency management with ease. You don't need to write any custom code such as that we wrote while implementing IoC with factory or service locator patterns.

So, as a developer, your life is cool. You just give a hint about your dependency, and the container will handle the rest and you can focus on implementing business logic.

If we choose containers to set dependencies for our Balance Sheet module, the container will create the objects of all dependencies first. Then, it will create an object of the Balance Sheet class and pass the dependencies in it. A container will do all these things silently and give you the object of the Balance Sheet module with all dependencies set in it. This process can be described with the following diagram:

In conclusion, the following are the advantages of using containers over manual code to manage dependency:

• Isolating the process of object creation from your code and making your code more clean and readable.
• Removing object wiring (setting dependency) code from your client module. The container will take care of object wiring.
• Making your modules 100 percent loose coupling.
• Managing the entire lifecycle of the modules. This is very helpful when you want to configure the objects for various scopes, such as request, session, and so on in application execution.
• Swapping out the dependency is just a matter of configuration—no change is required in the code.
• It is a more centralized way to handle object life span and dependency management. This is useful when you want to apply some common logic across the dependencies, for example, AOP in Spring. We will see details about AOP in Chapter 6, Aspect-Oriented Programming and Interceptors.
• Your module can benefit from advanced features that ship with containers.

Spring, Google Guice, and Dagger are some of the IoC containers available today for Java. Starting from Enterprise Edition version 6, Java introduced Context Dependency Injection (CDI), a dependency injection framework in Enterprise Edition. It's more or less similar to Spring's annotation-based DI implementation. Out of all the preceding containers, Spring is the most popular and widely used IoC container today.

In the software paradigm, it's always recommended to break the whole system down into small modules that can work independently for specific tasks. DIP is one of the important principles to build a modular system. In this chapter, we saw how high-level modules should not depend on low-level modules, and both should depend on abstraction (the concept of DIP).

We learned in detail how we can achieve DIP through IoC. Setting inversion of control makes a system loosely coupled. We also learned various design patterns such as factory, service locator, and dependency injection to implement IoC.

After that, we learned about the various types of the dependency injection pattern. Finally, we discussed IoC containers and how they're useful when building modular systems.

In the next chapter, we will talk about modularity concepts and dependency injection in Java 9.