Programmer's Diary: Interface Naming

This is a repost from my old blog. Original post date March 15, 2013


There was a twitter thread recently about interface naming. How should you name your interfaces? "IProduct" or "ProductInterface" or in another way? To my surprise the majority of the people who replied to that thread suggested "ProductInterface" and than "IProduct".

I suggested simply "Product".

In my view an interface should be named to reflect an abstraction. When you decided to make an interface you had a good reason to do so. If you didn't, your interface has no reason to exist.

In most cases interfaces abstract a higher, more general concept and they have several implementations. Of course, you can't write two implementationa at once, so at the beginning you will have only one implementation, then when you need another you will have another one.

Let me give you an example from our code at work. One of my colleagues, +Vadim Comanescu , wrote some logic in our application to handle sockets. At the moment of writing it, he defined an interface for the socket. He called it "Socket", no "I"s or "Interface" in it's name. Back then there was only one implementation to it "HttpSocket". It was great, it worked well. Today we needed to use our networking logic and communication modules over a UNIX socket. The solution was simple and done in just a few minutes. We created another implementation for "Socket" called "UnixSocket" and everything worked perfectly.

When we name interfaces we think about the clients, the other classes that are using our interfaces. In our networking module at some point we have something like "function writeToSocket(Socket $socket)". This is obvious. It looks great, it sounds logic and it is easy to understand. And one great thing there is that the client does not know that "Socket" is an interface.

Interfaces belong to the clients and not to their implementations; said Robert C. Martin and I totally agree. In the same way interfaces are like any other classes for the clients. What if you decide to change your interface into an abstract class. Very possible. After a few implementations you observe common code throught the implementations and extract it toward a Template Method design patter. Then... you have to change the name of your - now abstract class - interface into something else. An abstract class called "SocketInterface" has little sense.

And finally, a last thought, "Product" is a great name for an interface and it can be implemented by many many classes representing real-life products, for example "Keyboard" or "Mouse". However, there are some rare cases when you need an interface and you will have only one implementation. In those rare cases, I prefer to name well the interface and add "Impl" or "Implementation" to the the implementing class' name. This has more logic since the programmer writing the interface is most probably the one writing the implementation. However the programmer using the interface may be someone else from a totally different team or company or country. Why should that programmer of the client code know that "Product" is an interface or not. What if at the beginning it was a real object and the original programmer decided later that it should be an interface to better accommodate different implementations inside the "products" module? Why should the clients care? Why should they know?

If you are using a dynamically typed language, like PHP, there is almost no real reason for creating an interface that has only one implementation. Period. You have only one implementation and you are sure you need no other ones? Drop the interface.