Skip to main content

(Not So) Stupid Questions 5: Inheritance Versus Interfaces

October 13, 2005

(Not So) Stupid Questions

Inheritance vs. Interfaces

Editor's note: Sometimes, the most interesting discussions begin when someone says, "This may be a stupid question, but ...." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. Uncertainty points out an ambiguity in specs, holes in docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will publish one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

Remember that new people are joining the Java community all the time and may be looking for help from those with more experience. Also, those who began with Java as their first language can benefit from those coming to the community with experience in other languages. As always, answer the questions with kindness. You are also welcome to submit your questions to

This may be a stupid question, but ... "When should I implement an interface, over inheriting from a parent class? "

First thoughts:

I know this is done to avoid multiple inheritance, but I also know that you can write an interface and implement it instead of using inheritance. This arrangement allows you to implement behavior defined by many different interfaces, but stay out of the trouble that would ensue if, for example, you could inherit from two concrete classes and both had a method with the same name and same parameters.

An abstract class is kind of like an interface, in that it's meant to be extended, but your class can only inherit from one class, abstract or not. That seems different than implementing an interface anyway, since the abstract class can provide method implementations for subclasses to inherit, something interfaces can't do.

This brings me to two questions:

1. Should we completely avoid inheritance, and only use interfaces? and

2. If so, how will analysts know whether to continue to construct analysis class models using inheritance?

"(Not So) Stupid Questions" is where we feature the questions you want to ask, but aren't sure how.

Related Topics >> Programming   |   


Short answer is no, you

Short answer is no, you should not avoid inheritancy, it is the corner stone of the OO model. Interface's generally provide a "concept" or "contract" the implementations are guaranteed to follow. This allows developers to provide the "concept" of an object without the need to actually expose the implementation (thank you polymorphism) This would allow you to provide a "factory" that could produce your "interface" but protect other developers from been worried about the implementation details. Abstract classes provide a conceptual jumping off point for a possible implementation of the interface and if used correctly normally provide additional functionality to make it easier to develop a final concert implementation. Cell renders are good example of this. I generally find myself writing interfaces where I want to provide an idea (or suggest implementation) for an object to work with my application, so that other developers may have a chance to produce their own implementations or where I might need multiple different implementations. I generally then provide abstract classes (especially when dealing with listener style patterns) where I can produce a lot of the "boiler plate" code that will a lot of the "extra" work, but is not generally related to the actual implementation (again, take a look at the renderer model in swing). And finally, I would develop up either a default or internal implementation that could handle the initial concept. It's then up to the developer to decide at what level they want to jump in at.