Interfaces: why, oh why?

I've always wanted to make a post about interfaces, and never really took the time to do it. Well, here we go.

Interfaces seem to be one of the most misunderstood element of OOP. You can find plenty of posts on the same subject everywhere on the web, but I find that most posts don't come close to clearly explaining the real usefulness of interfaces. Most people I know tell me "Yeah yeah, I use interfaces, the other day I had to implement such or such interface" but in reality they don't have a clue on what's the real usefulness of interfaces. To most people, interfaces are simply a bunch of methods that need to be implemented, and the interface can't contain any code. But why? What are they good for? Why not simply use an abstract class? Well, I'll use a "concrete" example.

Let's say there's an abstract class called SpaceshipAbstract, another called AlienSpaceship, which extends SpaceshipAbstract, and a third one called KlingonWarship which extends the precedent class.

You, being a nice space trader, create a ShipRepairBay class, which will repair any ship that derives from SpaceshipAbstract. Your ShipRepairBay class will require a spaceship instance on its creation, and will call methods such as getHullSurface() and getWingList() on the spaceship instance to do its repair work.

This will work for some time. But one day, some space pirate will show up with some strange "ship", which will run on a new type of energy resource and with a totally different molecular substance than other known spaceships. SpaceshipAbstract *won't* apply to this spaceship. You won't be able to repair this ship! That's too bad, because this pirate was rich, very rich. You just lost a very lucrative contract. Read further to see how interfaces would have saved the day!

Let's start again with our example. Let's use the same spaceship classes, the three of them. We will now add a new interface called SpaceshipInterface. The interface has a getHullSurface() and getWingList() method. Our SpaceshipAbstract class will also implement this new interface. Now, the biggest difference is that our ShipRepairBay class won't require a SpaceshipAbstract anymore, it will require *any* class that implements the SpaceshipInterface interface.

Your pirate, being a good programmer too, will of course show up with a MyWeirdSpaceshipFromFifthDimension class which will implement SpaceshipInterface. It won't even matter *what* the pirate did in his class, you don't care, because you simply know that the required methods your repair bay needs to call will be there.

In other words, interfaces will allow your classes to be loosely coupled with each other. Abstract classes will work for a while, but then you might hit a wall. You will then start patching your abstract classes to handle exceptions, and your code will become very complex. An interface will allow you to create a special class that will do things its own specific way, and you will still be able to use it with your utility classes.

Allright, Captain Kirk is calling me, got to go back to work!