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...
...
}
}
所以我有一个类似于这个的类层次结构。这个想法是使用公共(public)最终的something() - 然后抽象 - doSomething() 模式,以便扩展类必须调用 super(),例如 Andrzej answer's
然后,我最终将拥有几个扩展 AbstractSomething 的实现。然后,此代码的客户端将实例化这些实现并使用 ISomething 方法。
类似这样的事情:
public class Main
{
public static void main(String[] args)
{
ConcreteSomething concrete = new ConcreteSomething();
concrete.something();
}
}
所以问题是,使用这种设计习惯是否有正确的方法来为层次结构编写一个好的javadoc?
我所说的正确是指: 当客户调用crete.something()时,我希望他们看到ConcreteSomething#something() javadoc。然而,由于该方法是 final方法,因此我不能简单地重写它并编写具体的 javadoc。 此外,我的客户不会看到 doSomething() 方法,因为它是 protected ,所以我也无法将具体的 javadoc 放在那里。
换句话说,我可能需要与{@InheritDoc}相反的内容:)
有什么建议吗?
最佳答案
该问题类似于接口(interface)的文档。客户将使用抽象,并且主要查看该抽象的通用文档。就您而言,您能做的最好的事情就是将文档添加到每个具体类的构造函数中。至少这样,客户端将看到实现的详细信息,并且您可以根据需要添加相关的 @link
和 @see
。
关于java - 在抽象方法中编写javadoc的正确方法是什么,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30890665/