Interview Question - FYI

[Travis Gibson]

Fellow Ranchers,
I had this question in an interview so I thought I would share it just in case you encounter it.
"Under what situation would it be better to use an Interface as opposed to a abstract Class"?
I had never really thought about it. I described the differences in my answer but for the life of me I couldn't describe why?
I did some research and got a few reasons after the interview I just wanted to see how many of you had a good reason off the top of your head.
Regards,
Travis M. Gibson,SCJP www.travismgibson.com

[Joshua Liu]

How about you can't extend more than one superclass, but you can implement as many interfaces as you need? So if you use an abstract class, you can only extend that one, instead of Thread or some other superclasses.

[Mark Herschberg]

I ask this, and typically get the answer given by Joshua--to support multiple inheritence. I'm ok with ths from a junior engineer, but not from people with more than 1-2 years experience--mostly because interfaces only support inheritence of interface, which is not the same as "inheritence" which generally implies inheritence of implementation.
In this case, my next question is, "Given a class which needs to inherit from multiple classes and interfaces, how do you decide which one to inherit from, and which ones to extend?" (Note: this assumes you are at the design stage, and classes and interfaces aren't yet set.)
--Mark
[e-mail]

[Huasong Yin]

This is a great interview question. Here is my trial of an answer.
1. I would prefer interface over abstract class if all the data fields are static constants and I do not expect any subtypes to have default behaviours.
2. More importantly if I expect subtypes can inherit from any other classes. This is the reason given by previous posting. For example, I can implement my Frame to be an ActionListener. But if ActionListener were declared as an abstract class, I would have to extend ActionListener instead of Frame. **So Interface must be used in order to support multiple inheritence**.

[Huasong Yin]

Here again is my trial for Mark's question:
1. If my Class M needs to inherit from class A, I would first decide whether M needs to have the full or partial functionality of A. Use inheritence if M behaves fully like A. Use composition if M only inherits partial behaviors from A and delegate bahaviors to the corresponding member field. For example:
class ButtonWindow extends Frame {
Button b;
public void setButtonText(String s){
b.setText(s);
}
public void addActionListener(ActionListner a){
b.addActionListener(a);
}
//other members
}
The key is to maintaion a balance between inheritence and delegation.
2. In Java there is only one class to inherit from, choosing the appropriate superclass will be the major task.

[Travis Gibson]

Mark,
My answer in the interview was "to support multiple inheritance". But as soon as I said it, I thought to myself "There has to be other reasons besides Multiple inheritance..".
As soon as I left the interview I wished I would have also stated that in abstract classes you can inherit unwanted behaviors from implemented methods but with interfaces you don't have to worry about this.
Mark, Would that have been acceptable?

Originally posted by Mark Herschberg:

In this case, my next question is, "Given a class which needs to inherit from multiple classes and interfaces, how do you decide which one to inherit from, and which ones to extend?" (Note: this assumes you are at the design stage, and classes and interfaces aren't yet set.)

What would be an acceptable answer to your question?
Bottomline, they gave the job to another candidate and I'm sure my answer to this question had something to do with it.
Regards,
Travis M. Gibson, SCJP

www.travismgibson.com

[Mark Herschberg]

Travis,
That does go a step further, although I would still want something deeper than that--again for non-junior programmers. The multiple inheritence answer, along with your comment about unwanted behaviors are both "book" type answers--what you would learn reading a basic Java or SCJP book. I want to see deeper design knowledge.
I guess the answer I would want would be somehting like:
What is the purpose of the class? It should have some primary funcationality, and a fixed, consistent means of implementing that functionality. I would pick the parent class that is closest to this. If there is more than one potential parent class, I've got two cases. Case 1, the parent classes are similar. In this case, I'd ask myself if I can combine the parents into a single class. More likely, the parent classes are disimmilar, case 2. Then why am I trying to combine two disimilar functions/implementations into one class? I would examine the propsed child class to see if I can and should break it into two classes.
Well, I really wouldn't expect such a complex answer in an interview. I guess I would summarize that as: a class should extend a class based on how it's implemented; it should implement interfaces based on how it's used by other classes.
This, of course, is a very general answer, and there may be cases where it doesn't hold true.
This, btw, is a example of what I mean when, in other postings to this forum, I comment that SCJP is not enough. SCJP focuses on the mechanics of how Java works, but not on when or why to do something.
--Mark
[e-mail]

[Joshua Liu]

Guilty as charged, Mark My company actually doesn't use Java, but is undergoing a major software system overhaul to make it more object-oriented. When this initiative was anncounced late last year, I volunteered to study Java as a possible alternative to VB/ASP (our current system), .Net (vaporware), and Python.
So I hit the books on Java, J2EE, OOAD, and do a bit of OO design here, a bit of prototyping in Java there, but I don't have the benefit of working with more experienced Java developers. This is why I enjoy coming to sites like JavaRanch, where Java experts share real-life solutions.