Code to interfaces, not to implementations

      In object oriented programming, interfaces are commonly used to implement more flexible software. Interfaces are very useful to extend and improve  a software application. While designing a software its a good practice to use interfaces where applicable.

           Lets think about a simple CricketPlayer class (Figure 1) with a method play(). There can be several classes and methods using CricketPlayer class. Think we need to give the support for Football player as well within this software. Then we need to repeat the wheel for new purpose(Figure 2).

Figure 1 : Initial cricket class

Figure 2 :Modification for support football player

        But just think if we use common interface (Figure 3) for any type of player, we can easily get rid of the problem. Player interface will have play() method which may be different behaviour for different players and getSport() method which represent the type of the player (sport). CricketPlayer and FootballPlayer subclasses can implement their own behaviours according to related declarations in the Player interface. Coding to this interface will save us with very limited changes, while any kind of player class is going to use in our software. Using an interface software can be extend easily and will be more generic.

Figure 3 : Player interface

        Recently I saw practically very useful place where interfaces are using. Most of the industry applications are using the MVC architecture to better maintainability of the code. There may have requirements to use the same applications with different DBMS for different clients. Using an interface with n-tier architecture, this support can be easily implemented.

          Following diagram (Figure 4) shows the way of using this stratergy in n-tier architectural application. From the Controller classes which deals with request and responses while dealing with the business logic of the application, calls to the service classes to do specific data manipulation, transaction etc. Service classes calls to Dao classes which deals with data transactions. Service class doesn't directly use either MySqlUserDoa which has MySQL support or XQueryUserDoa which has XQuery support. It only care about BaseUserDao interface, and doesn't care about real object underling the BaseUserDao interface.

Figure 4 : Dao interface

      Implementaion under this process is quite simple. Control class read configuration file (or from any other way) and get the Query Language supposed to use according to the requierments. Then create an object of supported Dao class and assigned to a variable of BaseUserDao (interface) type. After this initializing process of BaseUserDao type variable, it can be used by the service classes inside their functions.

BaseUserDao userDao;
if (queryLanguage == 'MySQL') {
    userDao = new MySqlUserDao();
} else if (queryLanguage == 'XQuery') {
    userDao = new XQueryUserDao();
}

        Since application is not creating concrete classes (objects are dynamically created in run time and will not directly creating objects for any case), it will not be limited. And since it uses an interface, switching for a new DBMS can be achieved by only adding new file which inherit the interface and modify the object creating process(modify above code) and giving the new DBMS as parameter, using a configuration file or any other way.

      Coding to interfaces, not to implementations principle is a good practice for a good software and it make our work more easy. If you are thinkng of creating extendable software application, this practice will very helpful. So, its time to play with interfaces. :)