aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes another design question on 'program to interfaces' or not Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "another design question on Watch "another design question on New topic

another design question on 'program to interfaces' or not

Bob Peterson
Ranch Hand

Joined: Jul 30, 2004
Posts: 47
We're trying to design an API that will go out to external customers. I've jumped into a new API product that has been 80-90% designed and written, and I'm trying to decide whether or not to keep the few interfaces that have been written. I'm wrestling with the 'program to an interface, not an implementation' issue.

FYI, my perspective is keep it simple, concrete, program to what you know now, don't have interfaces where there is only one implementation, etc. In the last couple years I have repeatedly inherited projects that seem to me to be very overly complicated in their design. We refer to these as 'atomic baloney slicers' when all you need is a simple knife. So I am leaning towards eliminating the interfaces and keeping the single concrete implementations we have.

On the other side, there is the difficulty of trying to plan for an unknown future (version 2?) and unknown usage by the customers. For instance, our concrete implementation is MyProduct. They may want to create a FooCompanyProduct class, and then handle FooCompanyProduct and MyProduct objects together. But the problem is, we don't know how to define the contract of the Product interface in that scenario. Right now, it seems like ALL the methods we think should be in the proposed Product interface, are already in the MyProduct class.

After our last design session, we decided to get rid of the interface, push a lot of the methods in the MyProduct class into an AbstractProduct class, which the customer can then extend. Another facet of the issue is that the custom classes the customer may want to make, must be composed of our components. Maybe that will help explain the decision on the AbstractProduct class. It's hard to explain it w/out getting into trouble divulging company secrets and all that.

I've been reading design articles on this issue and have just been going round and round on it. Honestly, a lot of those articles are hard for me to fully digest in an abstract sense, even with examples. I think I understand the benefits of interfaces with multiple implementations. Maybe I just need to learn the hard way by doing it wrong, but I'm trying to avoid that.

Hope that didn't ramble too much. Thoughts? I wish there was a preview option on these forums
Peer Reynders

Joined: Aug 19, 2005
Posts: 2906
Originally posted by Bob Peterson:
Honestly, a lot of those articles are hard for me to fully digest in an abstract sense, even with examples.

And yet you supply us with little concrete information to help you out - inviting more abstract answers.

Given that you currently only have a single implementation it is understandable that you have difficulties separating the commonality from the variability. (Commonality-variability analysis).

However you always have the The Principles of OOD to fall back on.

Right now, it seems like ALL the methods we think should be in the proposed Product interface, are already in the MyProduct class.[/QB]

Interface-Segregation Principle (ISP): Clients should not be forced to depend on methods that they do not use.

Look at your class and ask yourself: "Does every object that is a client of MyProduct need to know about all the methods on MyProduct?" If your class has multiple categories of client objects, then each client should manipulate MyProduct through an interface that is tailored to the client so that the client knows as much and as little as it needs to. MyProduct then needs to implement all those interfaces (i.e. there could be more than one).

Dependency-Inversion Principle (DIP): a. High-level modules should not depend on low level modules. Both should depend on abstractions. b. Abstractions should not depend on details. Details should depend on abstractions.

DIP depends on interfaces/abstract classes. It cannot work without them. Unfortunately they have to be the correct interfaces going in the correct direction.

Open-Closed Principle (OCP): Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification.

Without an interface your customers will have to inherit from MyProduct to create FooCompanyProduct. Using an interface (or more) also gives them the option of creating FooCompanyProduct from scratch, or (more likely) by containing a MyProduct instance and delegating to it (Refactoring: Replace Inheritance with Delegation).

A good resource about Java Library/API design is Joshua Bloch's Effective Java Programming Language Guide (amazon US)

"Don't succumb to the false authority of a tool or model. There is no substitute for thinking."
Andy Hunt, Pragmatic Thinking & Learning: Refactor Your Wetware p.41
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This presentation has some examples of DIP in action, comparing a design for reuse vs a design for plugins. Some of the trade-offs may be things you have to think about.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Peer Reynders

Joined: Aug 19, 2005
Posts: 2906
Originally posted by Stan James:
This presentation has some examples of DIP in action.

Code like this suggestsReplace Conditional with Polymorphism which is ultimately what happens.

Refactoring Catalog
Code Smells
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Having an interface is not all about code reuseability. I have only a single implementation but still I have interfaces. This allows me to work on my program one section at a time. So while I am working on the db side, I can compile and compile again the db part but I never have to compile the other side. If I did not use interface, then i would have to compile everything.

I don't have interfaces with methods designed for the future. The interfaces only contain methods that are being used.

This also helps me to keep track of which methods called externally and which are called internally since there are considerations sometimes.

There are really a lot of benefits to this. If you cant see a reason to use an interface as opposed to passing your objects around, then perhaps there is no reason. But maybe you should look harder too. This is not something that is done for the sake of doing the right thing. It makes your life easier. But it is also true that sometimes you have to learn to appreciate this the hard way.
I agree. Here's the link:
subject: another design question on 'program to interfaces' or not
Similar Threads
OO question: Interface or abstract class.
What is called abstractly coupled?
How do you feel about SoftSCJD?
Use of Interface
Program to an interface, not an implementation