Why would both a parent and child class implement the same interface?

Question

I inherited some legacy Java (1.4) code and this design decision appears regularly. I can't understand if there's any purpose or reason to it.

public interface SoapFacade extends iConfigurable{ }

public class SoapFacadeBase implements SoapFacade{
...
}

public class SoapFacadeImpl extends SoapFacadeBase implements SoapFacade{
...
}

As I understand interfaces (and my experimentation has reinforced), there is no purpose to having both the parent and the child implement the same interface. In this scenario, everything from SoapFacade is implemented in SoapFacadeBase, but the method in iConfigurable is implemented in SoapFacadeImpl. However, that doesn't create a need to have SoapFacadeImpl implement SoapFacade.

Is there something I don't know about interfaces that would give this pattern some purpose or benefit? Are there underlying costs beyond lack of clarity that should drive refactoring it? Or should it simply be refactored for clarity/simplicity?

score 48 · Accepted Answer · answered Apr 14 '11 at 19:16

48

As I understand interfaces (and my experimentation has reinforced), there is no purpose to having both the parent and the child implement the same interface.

No. Technically, it is completely redundant.

It does however document the fact that you intend SoapFacadeImpl to be a SoapFacade and it ensures that you get a compile error, if you (or someone else) decides to remove implements SoapFacade from the base class.

You see this pattern everywhere in the standard Java Collections API. ArrayList implements List even though its base class (AbstractList) already, does. Same holds for HashSet / AbstractSet and the Set interface.

answered Apr 14 '11 at 19:16

aioobe

413,195
112
811
826

2

It has some side effects. If you want to replace SoapFacade with SomethingElse (not renaming SoapFacade, replacing with a totally different interface) you'll have to replace it everywhere, and also the "Refactor" features of some IDEs (as Eclipse) won't help you. More, if you pass the code to other people, they may spend minutes in finding why they're getting compile errors on children classes (like: wtf... who the hell wrote this) – gd1 Apr 14 '11 at 19:18
+1 That does give me something else to think about with that. From the posted sample, everything from `SoapFacade` is implemented in the base class; thus I am more inclined to remove the `implements SoapFacade` from the derived class so as to obscure the details of `SoapFacade` from the child. – Riggy Apr 14 '11 at 19:21
@Giacormo, What do you mean by "getting compile errors on children classes"?? – aioobe Apr 14 '11 at 19:22

score 13 · Answer 2 · answered Apr 14 '11 at 19:16

13

If you use the interface also as a marker. Class.getInterfaces(); will only return directly instanced interfaces.

answered Apr 14 '11 at 19:16

Howard

38,639
9
64
83

score 0 · Answer 3 · answered Apr 14 '11 at 19:16

0

I actually find that design pointless. Implemented interfaces, as you stated, are just inherited, so there's no need to copy and paste "implements SomeInterface" on the children classes. It's not clearer, smarter, or whatsoever...

answered Apr 14 '11 at 19:16

gd1

11,300
7
49
88

4

It does guarantee that the subclass implements the interface, even if the base class gets refactored and no longer implements the interface. It also serves a documentation purpose. It should also be noted that it is used just about everywhere in the standard collections API. See my answer. – aioobe Apr 14 '11 at 19:21

score -2 · Answer 4 · answered Apr 14 '11 at 20:03

-2

It is nonsense, don't do it.

Especially in a public API like java collections. It's absolutely nonsense.

answered Apr 14 '11 at 20:03

irreputable

44,725
9
65
93

Why would both a parent and child class implement the same interface?

4 Answers4

Linked

Related