Why extends is evil

Improve your code by replacing concrete base classes with interfaces

By Allen Holub, JavaWorld.com, 08/01/03

The extends keyword is evil; maybe not at the Charles Manson level, but bad enough that it should be shunned whenever possible. The Gang of Four Design Patterns book discusses at length replacing implementation inheritance (extends) with interface inheritance (implements).

Good designers write most of their code in terms of interfaces, not concrete base classes. This article describes why designers have such odd habits, and also introduces a few interface-based programming basics.

Interfaces versus classes

I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

Losing flexibility

Why should you avoid implementation inheritance? The first problem is that explicit use of concrete class names locks you into specific implementations, making down-the-line changes unnecessarily difficult.

At the core of the contemporary Agile development methodologies is the concept of parallel design and development. You start programming before you fully specify the program. This technique flies in the face of traditional wisdom—that a design should be complete before programming starts—but many successful projects have proven that you can develop high-quality code more rapidly (and cost effectively) this way than with the traditional pipelined approach. At the core of parallel development, however, is the notion of flexibility. You have to write your code in such a way that you can incorporate newly discovered requirements into the existing code as painlessly as possible.

Rather than implement features you might need, you implement only the features you definitely need, but in a way that accommodates change. If you don't have this flexibility, parallel development simply isn't possible.

Programming to interfaces is at the core of flexible structure. To see why, let's look at what happens when you don't use them. Consider the following code:

f()
{   LinkedList list = new LinkedList();
    //...
    g( list );
}
g( LinkedList list )
{
    list.add( ... );
    g2( list )
}

Now suppose a new requirement for fast lookup has emerged, so the LinkedList isn't working out. You need to replace it with a HashSet. In the existing code, that change is not localized since you must modify not only f() but also g() (which takes a LinkedList argument), and anything g() passes the list to.

Rewriting the code like this:

f()
{   Collection list = new LinkedList();
    //...
    g( list );
}
g( Collection list )
{
    list.add( ... );
    g2( list )
}

makes it possible to change the linked list to a hash table simply by replacing the new LinkedList() with a new HashSet(). That's it. No other changes are necessary.

Archived Discussions (Read only)

Subject

Forum migration complete By Athen

Forum migration update By Athen

Skinning a cat By Alex B

Why do you ignore Java naming conventions ? By albert ( 1 2 all )

You are throwing away Object Orientation By Jack B.

A General Comment on all your "solutions" By Allen Holub

Call to synchronized native method unlocks monitor By Jeral

extends should be exist By ray ye

In case of Java, doesn't make sense By Anonymous

What about GUI's By Rob

Patterns emerge when you look at well-written code By Anonymous

How to avoid get/set in this situation? By Ralph Cook

Funny By Anonymous

OO is Implementation, NOT Interface, Inheritance!! By Anonymous

Am I missing something? By Anonymous

What about using reflection on yourself? By FL JavaMan

Pragmatism By Jonathan

Modularity failure? By Sixtieslibber

This kills OOP and that's probably a good thing By

Extends is not evil, it never has been By Tony Morris

Hi, just some question By HopingToLearn

Abstract class By Anonymous