About Interface

I read simple & correct definition about the Interface here

The basic problem an interface is trying to solve is to separate how we use something from how it is implemented.

Why do we want to separate the use from the implementation?

So that we can write code that can work with a variety of different implementations of some set of responsibilities without having to specifically handle each implementation.

To put this simpler, this means that if we have a Driver class it should be able to have a method Drive that can be used to drive any car, boat or other kind of class that implements the IDriveable interface.

The Driver class should not have to have a DriveBoat, DriveCar or DriveX methods for each kind of class that supports the same basic operations that are needed for it to be driven.

Interfaces are trying to solve a very specific problem by allowing us to interact with objects based on what they do, not how they do it.

Interfaces are contracts

=======================

Interfaces allow us to specify that a particular class meets certain expectations that other classes can rely on.

If we have a class that implements an interface, we can be sure that it will support all the methods that are defined in that interface.

At first glance interfaces seem to be similar to concrete inheritance, but there is a key difference.

Concrete inheritance says Car is an Automobile, while an interface says Car implements the Drivable interface.

When a class implements an interface, it does not mean that class IS that interface. For this reason interfaces that completely describe the functionality of a class are usually wrong.

A class can implement multiple interfaces, because each interface only talks about a particular contract that class is able to fulfill.

Interfaces are always implemented by more than one class

===========================================================

You might be saying “no they’re not, I have a class here that has an interface that no other class implements.”

To that I say, “you are doing it wrong.”

But, don’t worry, you are not alone. I am doing it wrong also. Many of us are not using interfaces correctly anymore, but are using them instead because we are under the impression that we should never use a concrete class directly.

We are afraid of tightly coupling our application, so instead we are creating interfaces for every class whether or not we need an interface.

There are some really good reasons why I say that interfaces are always implemented by more than one class.

Remember how we talked about how interfaces are designed to solve a particular problem?

In my example, I talked about how the Driver class shouldn’t have to have a method of each kind of class it can drive, instead it should depend on an IDriveable interface and can have one generic Drive method that can drive anything that implements IDrivable.

Most of us accept the YAGNI principle which says “You Ain’t Gonna Need It.” If we only have a Car class, and we don’t have any other classes that need to be driven by the Driver class, we don’t need an interface. YAGNI!

At some point we may later add a Boat class. Only at that point in time do we actually have a problem that the interface will solve. Up until that point adding the interface is anticipating a future problem to solve.

If you think you are good at anticipating when you will need an interface, I want you to do a little exercise. Go into your codebase and count all the interfaces you have. Then count all the classes that implement those interfaces. I bet the ratio is pretty close to 1 to 1.

Interface Example:

As said Interface defines well defined contracts. These contracts are implemented by the classes which are ready to implement this interface. That's it's like A company called X outsource some job to its contracting company Y.  Company X can later give that job to any other company if they wish. This flexibility can be achieved thorough interface programming.