Implementation Independence

“Design to interfaces, not implementations.” This is the advice that the Gang of Four gave us in their book, Design Patterns: Elements of Reusable Object Oriented Software. This means to hide implementation details and only present what is to be accomplished by crafting method signatures around testable behaviors. It means using APIs to create clear contracts for services while hiding as much as possible about how those services do their work. Much of the job of a good programmer is to find ways of encapsulating as much as possible while still creating the desired behavior.

I like to think of myself as an enlightened human being. I believe in equality not just for all humans but for all living things. But I don’t share that same attitude in my software. With people, I want to share as much as I can, but with my objects I want to hide as much of the world as possible from them. All of my software is on a nee-to-know basis. While that may sound a bit harsh at first, it stops my code from being pinned down by many implementation details and allows me to easily refactor and extend it with little friction.

I don’t want to give you the impression that I am cruel to my objects, nothing is further from the truth. I’m actually quite kind to them. I never overburden them with more than one responsibility, and I always keep them testable, so I’m constantly checking in with them and making sure they still work as expected. This reassures my code, and me, as well as my customers.

Implementation details can sometimes leak into our designs without us even being aware of it.

For example, I follow a practice called encapsulation of construction when I build my objects. I give each object the ability to create itself by adding a public static method that “news” itself up. I usually call this method getInstance(). I once worked with a client who was looking my code and asked me why I create so many Singletons in my code. I told him I try to avoid creating Singletons in my code and he pointed out all the “getInstance()” methods.

Why did he think I was creating Singletons in my code?

It turns out in the Gang of Four’s example of a Singleton in their book, they use the method name getInstance() but that doesn’t mean when you see the name getInstance() you should think of a Singleton. That’s an implementation detail. From the caller’s perspective, they’re simply asking for an instance. It shouldn’t matter whether you get a unique instance or you get access to some global resource through a Singleton. Perhaps a single resource becomes a bottleneck in the system and it needs to be refactored to a doubleton or a tripleton—or even an object pool. Would you ask all of your clients to rename the method they used from getInstance() to something else?

Hiding implementation details makes code more straightforward to test and understand.

The fewer assumptions we make in code, the less implementation details we expose and the more freedom we have to change our code in the future without impacting our callers. This dramatically drops the cost of ownership for the software we write. Given that over 80% of the cost of software happens after the initial release, writing code that is less expensive to maintain and extend is critically important.