0

I've got the following situation:

interface MyInterface { void commonMethodA(); void commonMethodB(); void specificMethod(); } abstract class Base { void commonMethodA() {...} void commonMethodB() {...} } class Derived1 extends Base implements MyInterface { void specificMethod() {...} } class Derived2 extends Base implements MyInterface { void specificMethod() {...} } 

i.e. I have an interface most of whose methods will be common to all implementators. Thus, IMHO the above architecture makes sense and indeed it works.

The only problem is with Javadoc. When it parses the Derived{1,2} classes, it concludes that there are two 'commonMethodAs' (and Bs)- one in the class Base that's extended from, another in the Interface that's implemented.

Would anyone have any recommendation? How to make Javadoc realize there's only one 'commonMethodA' ?

EDIT:

Forgot to add, there's also another

class Derived3withNoSpecifics extends Base { (...) } 

which is NOT supposed to include specificMethod(). So making Base implement MyInterface is, sadly, not an option...

EDIT2:

Another of proposed solutions, namely splitting MyInterface into MyInterfaceCommon (as I understand, implemented by Base) and MyInterfaceSpecific (implemented by Derived{1,2}) is not going to work either, and that's because of another yet-unmentioned constraint :) : elsewhere in the program I need to be able to accept instances of both Derived1 and Derived2 as parameters to a method, and I currently do it with

void theMethod(MyInterface parameter) { (...) } 

This method is the whole point of the existance of the MyInterface interface actually..

Here's how the produced Javadoc page looks like:

http://distorted.org/javadoc-library/org/distorted/library/DistortedTexture.html

Notice the 'getHeight()' , 'getWidth()' and 'getID()' are repeated. You do not see the class DistortedTexture is derived from and the interface it implements because both are package-local.

5
  • 2
    I don't understand why dont you use abstract class Base implements MyInterface? that's more logical Commented Feb 17, 2017 at 12:06
  • Good point, I have edited the question.... Commented Feb 17, 2017 at 12:11
  • 2
    @Leszek how about a second Interface for the specificMethod? Commented Feb 17, 2017 at 12:13
  • @Marius Yes, of course! Commented Feb 17, 2017 at 12:16
  • Wait, splitting MyInterface into MyInterfaceCommon and MyInterfaceSpecific is not going to work, and that's because elsewhere in the program I need to accept as parameters instances of both Derived1 and Derived2, and I currently do it but referring to them as 'MyInterface' - that's the hwole point of MyInterface actually.... Commented Feb 17, 2017 at 12:51

1 Answer 1

1

Your inheritance scheme is essentially the same as that of ArrayList. It implements List and extends AbstractList. It inherits equals() from both the interface and the abstract class, just as you do with commonMethodA. The javadoc for ArrayList shows exactly what you are complaining about: the mention equals is repeated because it's inherited from two places. That's just how Javadoc works. People are already used to that. I don't think there's any need to worry.

Sign up to request clarification or add additional context in comments.

2 Comments

Excellent point! I have taken a look at ArrayList's Javadoc page you have linked to. Mine looks worse: distorted.org/javadoc-library/org/distorted/library/… ( the 'getHeight()', 'getWidth()' and 'getID()' are repeated). You do not see the class it is extended from and the interface it implements because both are package-local.
Ah, I think yours is a different case because your base class and interface are not public, so are not documented and therefore Javadoc puts the documentation (twice!) in your derived class. I'm not sure what the solution to that is.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.