IOP vs OOP? -- No contest.

In the ring today we have Interface Oriented Programming (IOP) vs Object Oriented Programming (OOP).

What’s the difference?

TL;DR: In my opinion there is no difference. IOP is merely clarifies OOP, a reminder to program to interfaces, not implementations.

Object oriented programming has always been about interfaces. That’s the whole idea. You take a cluster of data, encapsulate it, infuse it with behavior, and it’s ready to interact with other objects as long as they respect the interface’s contract. But a problem arises when developers pierce the veil of the object’s interface and start coding to its implementation. This is Bad. It leads to tight coupling between objects and increases complexity. It doesn’t allow you to refactor with confidence. Now you have to hunt for all of the code you’ll have to change every time you change some facet of an object’s implementation. And it’s not a treasure hunt; it feels more like a manhunt - in Afghanistan. It’s what Martin Fowler refers to as “inappropriate intimacy.” That’s a good name for it. So keep your objects out of the tabloids. Respect the interface.

Programming strictly to interfaces leads to a number of benefits. Besides avoiding the horrible consequences just mentioned, there are a number of others as well:

• Coding to interfaces allows one team to specify to the required interface and another to code it. (The group which specifies the interface should also be responsible for providing the acceptance tests so that the developers know when they’re finished.)
• Testing is easier, because you simply create black box tests to verify that the interface upholds its contract.
• Mental juggling is reduced by creating a “separation of perspectives.” Most of the time you’ll just take the object at face value - via its interface. Only occasionally will you have to view the implementation perspective.

Does this mean that you should only ever call an object through an interface? Of course not. Sometimes an object or a project is so simple that a literal interface as a programming construct would just add undue complexity to the project. We don’t always program to literal interfaces, but we should always program to the concept of an interface. So don’t peek under the class covers. Keep private what’s private.

The Three Laws

Ken Pugh created the Three Laws of Interfaces^{(affiliate link)} , akin to Asimov’s Three Laws. (I feel a better name would be the Three Laws of Interface Implementation.)

Basically, an interface should:

• Do what it says.
• Do no harm.
• Let the caller know when it’s in breach of contract.