gpt4 book ai didi

java - 在抽象方法中编写javadoc的正确方法是什么

转载 作者:行者123 更新时间:2023-11-30 08:11:36 25 4
gpt4 key购买 nike

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 final something() - 然后是 abstract - doSomething() 模式,这样扩展类就必须调用 super(),例如 Andrzej answer's

然后,我最终会有几个扩展 AbstractSomething 的实现。此代码的客户端随后将实例化这些实现并使用 ISomething 方法。

像这样:

public class Main
{
public static void main(String[] args)
{
ConcreteSomething concrete = new ConcreteSomething();
concrete.something();
}
}

所以问题是,使用这种设计习惯是否有正确的方法来为层次结构编写良好的 javadoc?

正确的意思是:当客户调用 concrete.something() 时,我希望他们看到 ConcreteSomething#something() javadoc。但是,由于该方法是 final方法,我不能简单地覆盖它并编写一个具体的 javadoc。此外,我的客户不会看到 doSomething() 方法,因为它是 protected ,所以我不能将具体的 javadoc 也放在那里。

所以换句话说,我可能需要 {@InheritDoc} 的对立面 :)

有什么建议吗?

最佳答案

问题类似于接口(interface)的文档。客户将使用抽象并且主要看到该抽象的通用文档。在您的情况下,您能做的最好的事情就是将文档添加到每个具体类的构造函数中。至少这样,客户将看到实现的细节,如果需要,您可以包括相关的 @link@see

关于java - 在抽象方法中编写javadoc的正确方法是什么,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30890665/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com