A public method shall be declared by an interface

I said a while ago “Even a class that does not implement an interface has an interface!” When you want to expose an interface you consequently should declare it as an interface. And perhaps not only a single interface. As an non-english speaker I have the advantage to use “Schnittstelle or the french pronounciation of “interface” when talking about the de facto interface where I use the english word interface for the declared interface (the interface in the Java syntax)
When designing a class one goal is to have the class to be complete. A complete class might be aggregated from different interfaces whose implementations work closely together. Only exposing one big interface creates problems down the road as you’ll have more uses of the combined interface than of any partial interface. The extreme would be to declare an interface for each single method but this is only doable if you use mechanism to regroup them to larger unit (dynamic proxies) and perhaps reserved for special projects.

Why programming against interfaces is a good idea - I don’t know. I simply do it and I have an aversion against code that doesn’t. OK, one thing I encounter very often is that I have two classes and need a composite of it. If the classes declared an interface and these interface were used in the code, then factoring a class that delegates to the implementations does the trick easy and clean. If you only have classes, it gets ugly (define the interfaces yourself and refactor before you go - or use reflection). So methods of your interface are less useful if they don’t appear in an interface declaration.
The major point is that Java forces you to make methods public you don’t want to be public. The default visibility is underused as many people think:

  • It is lazy, the developer was just to lazy to type a proper modifier
  • Packages are good, more packages are better. By this you cut the limb off your desinging your API with

The last resort is to publish only interfaces and leave the public methods of your classes in the dark. Unfortunately this requires some downcast as your implementation has to get access to the hidden publics which is unsafe (What do you do if you get an instance of another class as expected).

Here you need sometimes just the opposite: An abstract class

Sometimes an abstract class is enough

Perhaps it should be rephrased to “… or an interface is not enough”. Abstract classes can simplify the design by a lot:

  • You save at perhaps one file
  • You can define protected methods
  • You can limit the instanciation to one package (default visibilty of ctor)

Saving a file is not a reason, creating a file costs virtually nothing, but untangling code later is costly, so if none of the other features is needed, abstract classes should not be used as an interface declaration.

Complexity of an interface 

two common point raised on programming against interfaces is that this caused additional work and makes code analysis more difficult. The additional work, yes this is correct: When adding a method you have to write the declaration into the interface, too. And you might get compiler errors as there are 200 implementations of this interface. This deterres people before they realize that they have to implement this method 200 times anyway, so that the one declaration is peanuts and overcompensated by the compiler listing you all the classes that need the new method.

Code-analysis is a valid one. If you have a variable of type Vegetable you know nothing about the concrete type and were to look for the code of getJoulePerUnit(). Why should want to look at the code? Because you have no idea if the value returned is for a kilo, pound, ounze or a ton. Better API-design (nobody reads documentation) would eliminate this: What about getJoulePerKilo() or getJoule(Unit unit). And of course your user have to have a good reason to trust you: Your method should do what it says, otherwise they have still to debug into it to learn how to use it.