monkey island

I gave my talk at devoxx and hopefully those who attended were not offended by my weird sense of humor Guys, we need to have more fun in IT…

Shortly after I gave the talk I had an interesting discussion about the coding style some folks call “coding to interfaces”. It started when I was asked if Mockito is able to mock concrete classes? The answer is yes, Mockito doesn’t care if you mock an interface or a class. Mockito can do it thanks to primordial voodoo magic only ancient shamans understand these days (you guessed right – it’s the cglib library).

Here starts the controversy. Should Mockito allow to mock only interfaces and hence promote “coding to interfaces”? Dan North, a respected IT guru and Mockito friend, said between the lines of one of his articles:

it allows me to mock concrete classes which I think is a retrograde step – remember kids, mock roles, not objects

What about the guy who approached me after the Mockito session told me a story about the codebase deeply proliferated with interfaces? Interfaces were introduced by developers not because they wanted to mock roles, not objects but because the mocking framework they used “promoted” coding to interfaces. This codebase was not very friendly.

To me, interface frenzy makes the codebase hard to browse, for example due to extra effort required to find implementation. Also, too many interfaces dilute the actual meaning of those interfaces that are really important. Therefore sometimes I mock classes, sometimes I mock interfaces and Mockito deals with it transparently. There are situations where I always use interfaces but let’s not bring it here.

I remember some old-school java book I read years ago. It read: “every java class should have an interface“. Don’t believe everything you read and the best example would be this blog, wouldn’t it?.

Use the coding style that works best for you. Drink mockitos only with interfaces if you like it this way.