The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Program to interfaces

I'm pretty new to Java, but have a lot of C experience. Java's interfaces look to me a great deal like C's header files. The function signatures seem redundant. Afterall the function signatures can be found in the implementation.

So why program to interfaces, not to implementation?
Tuesday, September 27, 2005
Because interfaces allow you to know only a little bit about a class instead of everything about a class. They allow you to use the same code to work with any class that implements the interface.
Tuesday, September 27, 2005
You can have multiple implementations of interfaces.

Java only allows you one implementation base class, but you can implement multiple interfaces.

If you have multiple orthogonal concepts in your program, you can represent each one as an interface, then implement them in whatever combination makes sense for your particular class.
Chris Tavares Send private email
Tuesday, September 27, 2005
Interfaces are polymorhic.
son of parnas
Tuesday, September 27, 2005
Sloop, if the class has everything but the interface methods private how does it hurt to program to program to the class?

I get the idea of working with any class that implements the interface, but in practice how often do you change out the underlying class?
Tuesday, September 27, 2005
In practice, you don't switch out the underlying class very often. So, if your currently using a class that doesn't implement any interfaces, I wouldn't worry too much about it.

But, when you're using classes that already have interfaces, it's better to write your code in such a way that it uses the interface name rather than the class name. So, writing something like this...

public List myMethodThatReturnsAList() {
} much better than this...

public ArrayList myMethodThatReturnsAList() {

...because it allows all the code that calls the method to just work with the List interface rather than the ArrayList implementation. Because, occasionally, you really *do* need to switch out the implementation, and if you've already written your code to work with interfaces, it's much more simple to change.

Having said all that, I have been in companies before where *EVERY* implementation class had to implement some interface. So we had all these interfaces for which there was exactly one implementation class. And, from that point on, whenever we updated the implementation class, we had to remember to update the interface as well. Otherwise we'd end up with class methods that weren't in the interface. After that, if we ever wanted to define another implementation class, the interface wouldn't enforce the new class containing those methods.

Anyhow, it was a nightmare.

My opinion is: any time there is a class that already implements an interface, any code that uses that class should reference the interface. But new classes should only implement interfaces if (and when) there are plans for writing more than one implementation. Once the interface (and the multiple implementations) exists, all code should reference the interface rather than the classes.
BenjiSmith Send private email
Tuesday, September 27, 2005
Newbie: unlike C++, Java doesn't allow multiple inheritance. Interfaces are a way to define a common public API for a "type" of classes which might otherwise be completely unrelated.

For example, imagine classes Airplane and Horse. It's quite difficult to imagine that they would belong to a same inheritance tree, but it's also quite logical that they would both have a method Move.

Now imagine we are writing a game where another class, Hero, can travel using either an Airplane or a Horse. We need to pass an object which can Move, but we won't know until runtime which it is.

So we make interface Movable, defining all the necessary public methods related to moving, and make both Airplane and Horse Implement it. Then we can have something like this inside the Hero class:

void protected Go (Movable ride)
Berislav Lopac Send private email
Wednesday, September 28, 2005
> Now imagine we are writing a game where another class, Hero, can travel using either an Airplane or a Horse.

Yes, interfaces are polymorhic.
son of parnas
Wednesday, September 28, 2005
The best explaination I've hever read regarding Java interfaces was from Bruce Tate's book, "Better, Faster, Lighter Java".

Interfaces are great at describing the services your objects are implementing. I highly recommend grabbing that book, it's a very short and very good read if you're going to be working with Java.
Michael Sica Send private email
Wednesday, September 28, 2005
Let's the GoF book answer this:

Programming to an Interface, not an Implementation

Class inheritance is basically just a mechanism for extending an application's functionality by reusing functionality in parent classes. It lets you define a new kind of object rapidly in terms of an old one. It lets you get new implementations almost for free, inheriting most of what you need from existing classes.

However, implementation reuse is only half the story. Inheritance's ability to define families of objects with identical interfaces (usually by inheriting from an abstract class) is also important. Why? Because polymorphism depends on it.

When inheritance is used carefully (some will say properly), all classes derived from an abstract class will share its interface. This implies that a subclass merely adds or overrides operations and does not hide operations of the parent class. All subclasses can then respond to the requests in the interface of this abstract class, making them all subtypes of the abstract class.

There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes:

Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.

Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface.
This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design:

Program to an interface, not an implementation.
Don't declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. You will find this to be a common theme of the design patterns in this book.

You have to instantiate concrete classes (that is, specify a particular implementation) somewhere in your system, of course, and the creational patterns (Abstract Factory (87), Builder (97), Factory Method (107), Prototype (117), and Singleton (127) let you do just that. By abstracting the process of object creation, these patterns give you different ways to associate an interface with its implementation transparently at instantiation. Creational patterns ensure that your system is written in terms of interfaces, not implementations.
Gustavo Munoz Send private email
Sunday, October 02, 2005
I think you really start to understand the value of interfaces when you start to learn about design patterns. Personally, I have found that understanding design patterns has greatly improved my object-oriented skills. For this, I recommend reading "Design Patterns Explained" by Alan Shalloway, although I hear "Head First Design Patterns" is also very good. I also recommend "The Pragmatic Programmer", just for good measure.

Also, as Benji mentioned, you don't use them for every class. You mainly use them for public-facing methods of your components. If you have a layered architecture, this would be the methods you're exposing to the layer above it (for instance, what the data tier exposes to the business logic tier). This way you can swap out these components if something better comes along, like a new open source package. You can view this as an abstraction layer to decouple your components.
Philip Yurchuk Send private email
Monday, October 03, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz