It happen to all of us. You happily write code, coupling your current class to an interface cuz it’s good practice and it help your tests and it create a rainbow with sunshine somewhere on the planet. Then you move along like the merry man you are, and you create a concrete implementation of your interface. And then it hit you like a ton of bricks:

How do you name that concrete class?

Tentatively, you name it InterfaceImpl or if you are in .NET you rename your IInterface to Interface with no I. But deep down, you know it’s wrong. That somewhere a bunny is dying because of your actions. And then you cry.

Or you don’t, in which case you should stop reading because this blog is not for heartless soul such as yours.

But worry not young apprentice, there are ways to get back to that sunshine world of yours where good design prevail. In this ongoing series of blog post, I’m gonna share with you a few tips to avoid those weirdly named classes.

Back to the basic: why are we defining those interfaces again?

I dread your answer: “Because I am doing TDD and I need to isolate my components for my tests.”

Err… Ok. While technically valid, this is not really the answer I was looking for. No, that is not why you should create interfaces. You introduce an interface because you have read Design Patterns and you know that your classes should depend on an abstraction, not a concrete class. And of course it’s one of the five commandment of the S.O.L.I.D. principle, and you know that if you don’t respect those, your programmer soul will burn in that very special place of Hell where they make you write VB6 code for all eternity.

The keyword here is abstraction. Interfaces are a way to create an abstraction, but they are not the only way. The Facade pattern is an abstraction, and last time I checked it didn’t needed any interface. Generic programming where you have those T type everywhere is another way to do abstraction. Non-geriatric language let you treat function as first class citizen, those are abstraction too. Oh, hey Java, didn’t notice you in the corner here! Err… As I was saying, most language, allow you to send a callback as a parameter to a method. Those are abstraction too. And yes, I know that Java 8 will have closure, it was a joke OK? Geez, why do people have to be so sensitive all the time.

Abstraction are a bit hard to get. So let me give you a real world example.

Today I went to the post office to get a package. In order to get my package, I talked to an abstraction called a post clerk. For the purpose of our demonstration, I am gonna assume that her name was Natasha. So I talked to that PostClerk abstraction, calling the iHaveAPackagePlease() method and sending the DeliveryNotice object as parameter, which I got earlier when my gotHome() event was triggered. Natasha, upon receiving my request, fetched my package, and then called the pleaseSignHereSir() method on my Customer abstraction. Once that was done, she called the haveAGreatDaySir() method on the Customer abstraction which prompted me to call the youToo() method on the PostClerk abstraction. At which point the transaction was concluded. (Later, I regretted not calling the canIAskYouOnADate() method on the PrettyGirl abstraction that Natasha implemented. Even though those often end up with a YoureNotMyTypeException at runtime. But I digress).

Notice the name of the abstraction and the concrete in the previous example. The abstraction have role name, like Customer and PostClerk. And the concrete elements have very specific name, like Laurent and Natasha. I could have talked to a concrete FatSweatyJoe and as long as he was one of those PostClerk abstraction, I would have received my package anyway. (But I wouldn’t have regretted not calling canIAskYouOnADate(), no matter how great a guy FatSweatyJoe is. ) It didn’t matter who the PostClerk in front of me was, as long as he or she was one.

By the way, me and Natasha were human being, not classes, and we didn’t implement any interface because it doesn’t make any sense in the real world to think that way. But the concept of abstraction is there.

The first rule of naming your interfaces

All that guide us to the most important part of avoiding the Impl suffix: Name your abstraction correctly by giving them a role name. Once you got that, the rest come much more easily.

Yep just do that. Aren’t you glad that I am here to tell all this amazing stuff?

OK, I know, I sound just like those weird guys in OOP programming books that create a Dog class that implement Mammal and put a bark() method on it. They never show any code that you will ever write and stay in “annoyingly vague example land”. So lets see some real example with real code that you may see in real life if you are a real programmer. We are gonna look at real abstractions, and give them real name that you may find in your code someday.

In part 2. Because it’s a bit late right now.

Stay tuned!