Was ist die richtige Art, Javadoc in abstrakten Methoden zu schreiben ⇐ Java

[Anonymous]

public interface ISomething
/**
* This method does something!
*/
public void something();
}

public abstract class AbstractSomething implements ISomething
{
/**
* See {@link #doSomething()}
*/
public final void something()
{
doSomething();
// Do something else...
...
}

protected abstract void doSomething();
}

public class ConcreteSomething extends AbstractSomething
{
/**
* Concrete implementation of doSomething(). It does... something!
*/
@Override
protected void doSomething()
{
// Actually do something...
...
}
}
< /code>
Ich habe also eine Klassenhierarchie, die so aussieht. Die Idee ist, das öffentliche endgültige () - dann abstrakte - dosomething () -Muster zu verwenden, so dass sich erweiterte Klassen verpflichtet wären, Super () aufzurufen, z. B.
Andrzej Antworks < /p>
Dann werde ich irgendwann mehrere Implementierungen haben, die Abstractsomething erweitern. Die Clients dieses Codes werden diese Implementierungen dann instanziiert und die Isomething -Methoden verwenden.public class Main
{
public static void main(String[] args)
{
ConcreteSomething concrete = new ConcreteSomething();
concrete.something();
}
}
< /code>
Die Frage ist also, dass die Verwendung dieses Design -Idioms eine korrekte Möglichkeit gibt, einen guten Javadoc für die Hierarchie zu schreiben? Da die Methode jedoch endgültig ist, kann ich sie nicht einfach überschreiben und einen konkreten Javadoc schreiben. Vorschläge?