Java Interfaces – Programming for Future Use

interfacesjavaobject-oriented-design

I have a colleague sitting next to me who designed an interface like this:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

The problem is, right now, we are not using this "end" parameter anywhere in our code, it's just there because we might have to use it some time in the future.

We are trying to convince him it's a bad idea to put parameters into interfaces that are of no use right now, but he keeps on insisting that a lot of work will have to be done if we implement the use of "end" date some time later and have to adapt all the code then.

Now, my question is, are there any sources that are handling a topic like this of "respected" coding gurus that we can link him to?

Best Answer

Invite him to learn about YAGNI. The Rationale part of Wikipedia page may be particularly interesting here:

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

The time spent is taken from adding, testing or improving the necessary functionality.

The new features must be debugged, documented, and supported.

Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.

Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.

It leads to code bloat; the software becomes larger and more complicated.

Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.

Adding the new feature may suggest other new features. If these new features are implemented as well, this could result in a snowball effect towards feature creep.

Other possible arguments:

“80% of the lifetime cost of a piece of software goes to maintenance”. Writing code just in time reduces the cost of the maintenance: one has to maintain less code, and can focus on the code actually needed.
Source code is written once, but read dozens of times. An additional argument, not used anywhere, would lead to time wasted understanding why is there an argument which is not needed. Given that this is an interface with several possible implementations makes things only more difficult.
Source code is expected to be self-documenting. The actual signature is misleading, since a reader would think that end affects either the result or the execution of the method.
Persons writing concrete implementations of this interface may not understand that the last argument shouldn't be used, which would lead to different approaches:
1. I don't need end, so I'll simply ignore its value,
2. I don't need end, so I'll throw an exception if it is not null,
3. I don't need end, but will try to somehow use it,
4. I'll write lots of code which might be used later when end will be needed.

But be aware that your colleague may be right.

All previous points are based on the fact that refactoring is easy, so adding an argument later won't require much effort. But this is an interface, and as an interface, it may be used by several teams contributing to other parts of your product. This means that changing an interface could be particularly painful, in which case, YAGNI doesn't really apply here.

The answer by h.j.k. gives a good solution: adding a method to an already used interface is not particularly hard, but in some cases, it has a substantial cost too:

Some frameworks don't support overloads. For example and if I remember well (correct me if I'm wrong), .NET's WCF doesn't support overloads.
If the interface has many concrete implementations, adding a method to the interface would require going through all the implementations and adding the method there too.

Related Solutions

Abstract Classes vs Interfaces – Key Differences and Usage

In layman's terms:

Interfaces are for "can do/can be treated as" type of relationships.

Abstract ( as well as concrete ) classes are for "is a" kind of relationship.

Look at these examples:

class Bird extends Animal implements Flight;
class Plane extends Vehicle implements Flight, AccountableAsset;
class Mosquito extends Animal implements Flight;
class Horse extends Animal;
class RaceHorse extends Horse implements AccountableAsset;
class Pegasus extends Horse implements Flight;

Bird, Mosquito and Horse are Animals. They are related. They inherit common methods from Animal like eat(), metabolize() and reproduce(). Maybe they override these methods, adding a little extra to them, but they take advantage of the default behavior implemented in Animal like metabolizeGlucose().

Plane is not related to Bird, Mosquito or Horse.

Flight is implemented by dissimilar, unrelated classes, like Bird and Plane.

AccountableAsset is also implemented by dissimilar, unrelated classes, like Plane and RaceHorse.

Horse doesn't implement Flight.

As you can see classes (abstract or concrete) helps you build a hierarchies, letting you inhering code from the upper levels to the lower levels of the hierarchy. In theory the lower you are in the hierarchy, the more specialized your behavior is, but you don't have to worry about a lot of things that are already taken care of.

Interfaces, in the other hand, create no hierarchy, but they can help homogenize certain behaviors across hierarchies so you can abstract them from the hierarchy in certain contexts.

For example you can have a program sum the value of a group of AccountableAssets regardless of their being RaceHorses or Planes.

Using Protected Inheritance to Hide Implemented Interface in C++

We can establish that it is legal (i.e. valid) C++ because it compiles. You've used it on GCC and clang and I've done exactly same thing with MSVC++ so that covers the majority of the compiler market.
This is why protected/private (btw, I would use private) modifier was introduced. It allows your class to implement callback interfaces which are needed for other classes it is using internally, but a) the rest of the world doesn't need to know that you are using those other classes and b) the rest of the world should not be able to even call on any of those functions because they are meant to be hidden and used only by internals.

When I transitioned from C++ to C#, I actually felt weird that I couldn't have private interface inheritance. If something is an implementation detail and not intended to be seen/used by the public, it should be kept hidden and I think the method you described is a great and simple way of doing that.
Using pImpl just generates more overhead. When you allocate your objects (obviously assuming dynamic allocation), you end up going to the heap twice as many times. You also reduce the locality of your code because now View and ViewImpl might be in different pages in memory and will cause more cache misses. And you've increased the amount of boiler plate code you have to write because now you are forwarding all public interface calls from the View to ViewImpl.

This is all just my opinion but in the end, I cannot think of any reason not to have private interface inheritance. I've written code like this for 6+ years and never had any readability/maintainability problems because of it.

Best Answer

Related Solutions

Abstract Classes vs Interfaces – Key Differences and Usage

Using Protected Inheritance to Hide Implemented Interface in C++

Related Topic