Saturday, 2 August 2014

Simple Understanding of Interfaces. Why Interfaces ?

Assumptions:

1. Knowledge of OOPS C#/JAVA Note :
I am
assuming that you have already some basic knowledge of Object oriented design

What is Interface ?

An interface is a programming structure that allows to enforce
certain properties on an object. For example, say we have a 2 wheeler , 3 wheeler class and a 4 wheeler class. In all three cases you have to have some action like Initiate_Engine() action. Now question is how the engine is initiated for each type is left up to each particular class, but the fact is that they must have a Initiate_engine action .
So,we can say Interface states “WHAT TO DO", rather than “HOW TO DO?” .Important point here is that interface defines only the members that will be made available by an
implementing object. The definition of the interface states nothing about the
implementation of the members, only the parameters they take and the types of
values they will return. Implementation of an interface is left entirely to the
implementing class. It is possible, therefore, for
different
objects to provide different implementations of
the same member
An interface is a agreement between itself and any class that implements it. This agreement/contract states that any class that implements the interface will implement ALL the
interface's properties, methods and/or events.
An interface can contain signatures of methods, properties, indexers & events

When to Use Interface ?
Using interface is good practice but not in each and every case.Sometime using too much of interfaces can result in overhead for developers.I will justify this point in my next series
To make it understand when to use interface is my first consideration.
Let us assume that we have got requirement to design a service/method which will save reports in multiple format like WORD,EXCEL,PDF,CSV.So , we have services.methods like

public class AssetReportingService {
public void SavetoWord(Asset objasset) {
//save to word using service exposed by Repository layer/Database related layer
}
public void SavetoExcel(Asset objasset){
//save to db using service exposed by Repository layer
}
public void SavetoPdf(Asset objasset){
//save to db using service exposed by Repository layer
}
public void SavetoCsv(Asset objasset){
//save to db using service exposed by Repository layer
}
}

In above case, the AssetReportingController should be aware of the
concrete implementation of these four methods in AssetReportingService
to use them and Controller becomes complicated too when additional features are required like SavetoJson() , SavetoText()...

If an additional functionality to save the information as JSON,TEXT is required then
you will have to add a new function SavetoJson(),SavetoText() in the Service
class as well as make changes in the Controller. This adds lots of complication
to maintenance of our application with hundreds of controllers and services. simply it becomes tough .

Here INTERFACE can HELP :-

When using interface this becomes much simpler. We define our AssetReportingService like this:

public interface IAssetReportingService {
public void SaveReport();
}

The controller layer is only aware of this interface, which has a SaveReport
method.
Let us say we have three implementations like the following:

Here we can choose any of these three implementation(classes) on run time using dependency injection. One may use @Inject or @Resource annotation in JAVA and Unity or StuctMap in C# to mark an implementation is to be injected.

Now when we need to add the additional functionality of saving to Json, we just add another implementation and select that implementation to be injected.
(You may use an IOC{Inversion Of Control} container like Spring to achieve this seamlessly.)

This is what we call loosely coupled system. This highly reduces the software modification and extension cost. As changes in one layer does not effect other layer and new functionalities are made available to other layer immediately.
Thus using interface gives you more power over extending and maintaining your application, utilize abstraction and implement good software development practices.

Finally
Interfaces fulfill two goals:

They allow the programmer to be more abstract when referencing objects (for
example, var vehicle : Vehicle, can reference any car, truck, etc... anything
that is a vehicle (and not care what type it is.) This occurs at "program time".
When the vehicle.start_engine() function is invoked, the correct function associated
with the real object is actually used. This occurs at "run time".

They require the programmer to create specific functions that are expected in
an implementing class when it implements an Interface.
Again, this allows all objects in a "set" of like objects to be treated based
on the "high level" type of the set, rather than on the specific type of the
individual object.