Revision as of 04:31, 19 November 2009

Interface Segregation Principle vs. Principle of Small Interfaces

Introduction

OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.Modular Decomposability – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.Modular Composability – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.Modular Understandability – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.Modular Continuity – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.Modular Protection – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

Interface Segregation Principle

The principle states that:

"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

“Many client specific interfaces are better than one general purpose interface“
“The dependency of one class to another one should depend on the smallest possible interface“
“Make fine grained interfaces that are client specific.“
“Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

Clients Should not be forced to use Interface they don't use

To explain this consider the following Java Code

Consider an Interface shown below

interface Iworker{
       public void work();
       public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
	public void work();
}

interface IFeedable{
	public void eat();
}

class Worker implements IWorkable, IFeedable{
	public void work() {
		// ....working
	}

	public void eat() {
		//.... eating in launch break
	}
}

class Robot implements IWorkable{
	public void work() {
		// ....working
	}
}

class SuperWorker implements IWorkable, IFeedable{
	public void work() {
		//.... working much more
	}

	public void eat() {
		//.... eating in launch break
	}
 }

class Manager {
	Workable worker;

	public void setWorker(Workable w) {
		worker=w;
	}

	public void manage() {
		worker.work();
	}
}

Principle of Small Interfaces

The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of Modular Protection and Modular Continuity. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
    public List getEmployeesForNameDOB(String lastName, Date birthDate)
        // implementation …
    }
    public Employee getEmployeeForID(int employeeId) {
        // implementation…
    }
    public void saveEmployee(Employee emp) {
        // implementation… 
    }
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

Violation of Modular Continuity

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
    private Connection dbConnection;

   public Connection getDbConnection() {
       return dbConnection;
   }
   public void setDbConnection(Connection newDBConnection) {
       dbConnection = newDBConnection;
   }
    public List getEmployeesForNameDOB(String lastName, Date birthDate) {
        // implementation …
    }
    public Employee getEmployeeForID(int employeeId) {
        // implementation…
    }
    public void saveEmployee(Employee emp) {
        // implementation…
    }
}

In this above code the dbConnection of the type java.sql.connection is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using JDBC, then the connection object makes sense, but if a business decided to use Mainframes or any other non SQL databases (like Hadoop), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

Violation of Modular Protection

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
   private HashMap employeeMap;

   public HashMap getEmployeeMap() {
       return employeeMap;
   }
   public List getEmployeesForNameDOB(String lastName, Date birthDate) {
       // implementation …
   }

   public Employee getEmployeeForID(int employeeId) {
       // implementation…
   }

   public void saveEmployee(Employee emp) {
       // implementation…
   }
}

In this case the method getEmployeeMap will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of mutable objects.

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the getEmployeeMap, based on the Principle of Small Interfaces.

Compare and Conclude

At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the getEmployeeMap cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the getEmployeeMap method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.