Should an interface that is inherited from base-cl

Question

My question is, if an interface that is implemented implicitly by extending a class that already implements it, should be explicitly implemented by the class, if the class wants to advertise the fact, that it fulfills the contract of that interface.

For instance, if you want to write a class, that fulfills the contract of the interface java.util.List. You implement this, extending the class java.util.AbstractList, that already implements the interface List. Do you explicitly declare, that you implement List?

public class MyList extends AbstractList implements List

Or do you save typing by using the implicit way?

public class MyList extends AbstractList

Which way is considered better style? What reasons do you have to prefer one way or another? In which situations you would prefer way 1 or way 2?

Answer 1

As a general rule, use option 2, not option 1.

Option 1 does not provide any value addition to the developer or someone who is going to maintain the code, in the vast majority of the cases..

If someone really wants to know all the roots of a particular class, any IDE should be able to do it for you, straightforward. (Eclipse: ctrl+shift+G)

What if AbstractList decides not to implement List any longer? This is not going to happen for the vast majority of general classes. What about the other less obvious (less trustworthy) ones? Of course there can be exceptions, but very few (<1% ?)

Answer 2

Though it is redundancy to implements the interface in the subclass but it is a good practice to implement it. Because somebody might remove the implemented interface from the super class.

Answer 3

I would say the more verbatim way. Why make others that read your code has to look up what a class implements? It makes it clear of the inherit functionality of your class. But I would try to maintain consistency across all code in the project. It will be confusing if you only do it in one place but if you do it consistently they will be aware of the redundancy.

A Side Note: There are so many classes in Java and who knows them all? Even more so, who knows which classes each class implements from? You typing for an extra couple seconds saves a fellow developer a minute or two looking classes.

Answer 4

I have seen this before and it doesn't feel technically correct, as many of you had already pointed out. I would think it should be obvious, however if for some reason it were not I think it would make more sense to indicate the inheritance through a class comment, rather than explicitly implementing the interface again.

What if the base class implements multiple interfaces? Do you then explicitly implement all of those interfaces, and all the way back up the inheritance chain? Obviously not, so I think the inconsistency of this approach proves itself to be wrong. Intent can be communicated in many ways, and this is not the best approach IMHO.

Answer 5

I asked this same question long ago on my blog. There is a long discussion there as well if you're interested in seeing some other people's thoughts. It's interesting to note that both strategies are taken within the JDK.

I ultimately decided that a hard rule on this didn't make sense - it's better to use best judgement as to what I wanted to communicate.

Answer 6

While I generally stick with option 2, I will go on a limb and argue that option 1 is actually appropriate in more cases when it is apply.

Code usability and understandability is important. The question that we have to ask ourselves is whether or not a developer using or seeing a reference to this class would intuitively understand that the class implements that interface (and is thus essentially a subtype).

In a well written class in the typical case, the name of the class should make it obvious that it implements the interface. Adding the interface would be just a redundnacy.

However, in cases where the class name does not make it obvious what interfaces it implements, and despite the smell this is the way things are and this is the name that will stuck, then it makes sense to add the implements to indicate the interface explicitly. This is also good in case someone in the future changes the hierarchy, which is possible in unintuitive inheritances like this.