Programming to an Interface

In this article, we will  discuss design principles and tools based on which design patterns are created. 

The very first principle is “Programming to an Interface”. What does that mean? Let's try to understand this principle in detail.

In general, if you look at any business solution for a problem statement, you can find two parts:

• Fixed
• Variable

The fixed part is some kind of boilerplate or constant declaration code, but when we use this design pattern we actually take care of the variable part.

All design patterns are discovered to maintain variable parts in an efficient way, so that the application welcomes changes without breaking. If your code is not flexible with future enhancements or changes, then your code is not up to the mark.

The question is, in Java, how judiciously can you maintain your variable parts?

To answer that, we can say variable parts are different ways that an outcome can be achieved, and the system must be ready to accept them all. More specifically, we know the type of the operation (say, "display functionality", but it can have many implementations (maybe it is a projector or monitor). Most importantly, requirements in software development are to meet clients' ever-changing needs. So I can say functionality is constant, but its implementation can change anytime based on the client, so always design based on a contract rather than an implementation. 

Let’s take an example. A computer monitor is  designed for display purposes. So I can say the computer is a product and the computer monitor is a part or module of the computer which is responsible for display operation.

Now, later on, client needs change and now they want to display on a projector.

So if our solution is not capable of welcoming this need, it will be nothing but a waste of a product.

According to new needs, what we can analyze is it will perform the same operation, display, but the module should change from computer monitor to projector.

The display module of a computer should be flexible, so we can change it easily, or we can change it dynamically (at runtime). We can say the display module is like a strategy, and a client can change the strategy at any time. Technically, the display is a function or contract, but it can have multiple implementations, so it's better to create this contract as an interface, and every implementation will provide its own display mechanism so at runtime, the Computer can call it.

So our Java solution looks like the following:

interface displayModule
{
public void display();
}


public class Monitor implements displayModule
{
  public void display()
  {
 	 System.out.println(“Display through Monitor”);
  }
}

public class Projector implements displayModule
{
  public void display()
  {
 	 System.out.println(“Display through projector”);
  }
}



public class Computer
{
 displayModule dm;// programming through interface as variable part

public void setDisplayModule(displayModule dm)
{
this.dm=dm;
}

public void display()
{
dm.display();
}

public static void main(String args[])
{
Computer cm =new Computer();
displayModule dm = new Monitor();
displayModule dm1 = new Projector();
cm. setDisplayModule(dm);
cm. display();
cm. setDisplayModule(dm1);
cm. display();

}

}

Output:
  Display through Monitor
  Display through projector.  

Look the implemented solution: we know Display Module should be flexible and we know the problem statement is display Operation, but in the future, the client may change the display operation style. One thing is for sure: computer should have a display module, but we don’t know what that piece of equipment will be.

So we create an interface called displayModule, and all display equipment must implement that interface and provide its own implementation of the display operation.

In the computer class here I create a has-A relation (composition) called displayModule so that the display module can change frequently as per the client's needs, so we always make this strategy as abstract or high-level as possible so we can change it on the fly with actual implementation.

Remember to always code through an interface so you can change your strategy at runtime with actual implementation. Figure out the variable parts of your problem statement and make it abstract so we can change strategy further.  The interface in "programming through the interface" means the java interface or abstract class.