Why do most system architects insist on first programming to an interface?

Question

Almost every Java book I read talks about using the interface as a way to share state and behaviour between objects that when first \"constructed\" did not seem to share a r

Answer 1

Programming to an interface means respecting the "contract" created by using that interface

This is the single most misunderstood thing about interfaces.

There is no way to enforce any such contract with interfaces. Interfaces, by definition, cannot specify any behaviour at all. Classes are where behaviour happens.

This mistaken belief is so widespread as to be considered the conventional wisdom by many people. It is, however, wrong.

So this statement in the OP

Almost every Java book I read talks about using the interface as a way to share state and behavior between objects

is just not possible. Interfaces have neither state nor behaviour. They can define properties, that implementing classes must provide, but that's as close as they can get. You cannot share behaviour using interfaces.

You can make an assumption that people will implement an interface to provide the sort of behaviour implied by the name of its methods, but that's not anything like the same thing. And it places no restrictions at all on when such methods are called (eg that Start should be called before Stop).

This statement

Required for GoF type patterns, such as the visitor pattern

is also incorrect. The GoF book uses exactly zero interfaces, as they were not a feature of the languages used at the time. None of the patterns require interfaces, although some can use them. IMO, the Observer pattern is one in which interfaces can play a more elegant role (although the pattern is normally implemented using events nowadays). In the Visitor pattern it is almost always the case that a base Visitor class implementing default behaviour for each type of visited node is required, IME.

Personally, I think the answer to the question is threefold:

1. Interfaces are seen by many as a silver bullet (these people usually labour under the "contract" misapprehension, or think that interfaces magically decouple their code)

2. Java people are very focussed on using frameworks, many of which (rightly) require classes to implement their interfaces

3. Interfaces were the best way to do some things before generics and annotations (attributes in C#) were introduced.

Interfaces are a very useful language feature, but are much abused. Symptoms include:

1. An interface is only implemented by one class

2. A class implements multiple interfaces. Often touted as an advantage of interfaces, usually it means that the class in question is violating the principle of separation of concerns.

3. There is an inheritance hierarchy of interfaces (often mirrored by a hierarchy of classes). This is the situation you're trying to avoid by using interfaces in the first place. Too much inheritance is a bad thing, both for classes and interfaces.

All these things are code smells, IMO.

Answer 2

Why extends is evil. This article is pretty much a direct answer to the question asked. I can think of almost no case where you would actually need an abstract class, and plenty of situations where it is a bad idea. This does not mean that implementations using abstract classes are bad, but you will have to take care so you do not make the interface contract dependent on artifacts of some specific implementation (case in point: the Stack class in Java).

One more thing: it is not necessary, or good practice, to have interfaces everywhere. Typically, you should identify when you need an interface and when you do not. In an ideal world, the second case should be implemented as a final class most of the time.

Answer 3

You could see this from a perl/python/ruby perspective :

• when you pass an object as a parameter to a method you don't pass it's type , you just know that it must respond to some methods

I think considering java interfaces as an analogy to that would best explain this . You don't really pass a type , you just pass something that responds to a method ( a trait , if you will ).

Answer 4

How come?

Because that's what all the books say. Like the GoF patterns, many people see it as universally good and don't ever think about whether or not it is really the right design.

How do you know all the relationships between objects that will occur within that interface?

You don't, and that's a problem.

If you already know those relationships, then why not just extend an abstract class?

Reasons to not extend an abstract class:

1. You have radically different implementations and making a decent base class is too hard.
2. You need to burn your one and only base class for something else.

If neither apply, go ahead and use an abstract class. It will save you a lot of time.

Questions you didn't ask:

What are the down-sides of using an interface?

You cannot change them. Unlike an abstract class, an interface is set in stone. Once you have one in use, extending it will break code, period.

Do I really need either?

Most of the time, no. Think really hard before you build any object hierarchy. A big problem in languages like Java is that it makes it way too easy to create massive, complicated object hierarchies.

Consider the classic example LameDuck inherits from Duck. Sounds easy, doesn't it?

Well, that is until you need to indicate that the duck has been injured and is now lame. Or indicate that the lame duck has been healed and can walk again. Java does not allow you to change an objects type, so using sub-types to indicate lameness doesn't actually work.