Interface abuse

Just a quick word on interfaces, and what they stand for. Probably this is obvious to many people, but I see a recurring problem which I guess is related to some misconception of interfaces.

Program to interface, not to implementation” – old words of wisdom, we’ve all heard a thousand times. However, interface in this context is not necessarily a Java interface – or at least not always. You can find yourself in situations when you are using interfaces and still programming to implementation. Let’s see what exactly is the difference between the two approaches.

Programming to implementation means the complete missing of unification; it means a bunch of if-else if statements, switches, instanceof operations. The following code fragment is clearly programming to implementation, even though it makes use of interfaces.

public interface Clock {

public class NewYorkClock implements Clock{

public class BudapestClock implements Clock {

public class WorldClock {

 public String getTime(Clock clock) {
 if (clock instanceof NewYorkClock) {
 NewYorkClock newYorkClock = (NewYorkClock)clock;
 Timezone nyTimezone = clock.getNewYorkTimeZone();
 } else {
 BudapestClock newYorkClock = (BudapestClock)clock;
 Timezone budTimezone = clock.getBudapestTimeZone();

Well, usually it does not come in such obvious forms, but you can be suspicious when you see lots of if-then statements for controlling behavior.

 Programming to an interface means to handle similarly behaving objects in a uniform manner (and that is what interfaces guarantee us: uniformity. No matter who the implementer of that particular interface is, it is always guaranteed that it will conform to the interface it implements).

However, what’s really not programming to an interface (and basically this is why I’m writing this post) is associating an interface with every single class – e.g. having one and only one class implement an interface. This overuse of interfaces does more harm than good. As mentioned above, we use interfaces in order to group together objects with similar behavior. However, when an object does not share similar behavior with any other objects, there is no need for this grouping; that object is already uniform by default.

Extracting an interface from a class just so it has one, has this annoying feature that whenever you ctrl+click a method name in your IDE, you end up in the interface rather than the implementation itself. I see no practical use case in jumping to the signature declaration instead of the implementation itself. It’s annoying, a waste of time, a huge overkill and completely useless, in general.

People usually make excuses like “well, there might be new implementations for this interface in the future, so that’s why”. Which is a pretty bad one; there might not be new stuff to add as well. And even if such a new feature comes along, it’s enough to add the interfaces then – when you actually need them. Don’t fix what’s not broken; don’t add useless code trying to predict the future. Whenever you see such interfaces with only a single implementer, in my opinion, you should just go ahead and delete them. Well, if you delete old unused private methods, why would you keep a type that can be replaced with another one in no time?

After all, the version control will keep track of it anyway, if you need them ever again.

OCMJEA (former SCEA) exam – experiences. Part 2

In a previous post I’ve shared my experiences on the first part of OCMJEA certification (multiple choice test) alongside some tricks and helpful links. Well, as several weeks have passed since then and I’m now through the remaining two parts (successfully, by the way – yaaay), it’s time for me to talk about parts two and three.

Continue reading “OCMJEA (former SCEA) exam – experiences. Part 2”