20

javadocがでinheritedDocをサポートしない正当な理由があるかどうか疑問に思いましたconstructors。私が持っているとしましょう

class A
{
/**
 * Constructor of A
 */
A(){}   

/**
 * Does something
 */
public void method(){}
}

class B extends A
{
/**
 * {@inheritDoc}
 */
B(){ super();}

/**
 * {@inheritDoc}
 */
public void method(){}
}

メソッドについてはmethod、javadocを継承できますが、なぜ同じことが適用できないのconstructorsですか？私がinheritDocタグを使用しない限り、javadocは継承されません。つまり、ドキュメントを再利用したいということを十分に認識しています。私がそうすることを妨げるものは何constructorsですか？

4

4 に答える 4

16

コンストラクターに対してそうすることを妨げるものは何ですか？

おそらくコンストラクターが継承されていないという事実。多くの場合、スーパークラスのコンストラクターと同じパラメーター（同じ意味）を持つことになりますが、メソッドの場合ほど明確な関係ではありません。

実用的な価値はわかりますが、実際には継承されていないものが@inheritDoc利用できない理由も同様にわかります。ドキュメントの一部を具体的に継承できると便利です。たとえば、パラメータ値をスーパークラスコンストラクタに直接渡す場合は、そのドキュメントに効果的にリンクできると便利です...

于 2013-02-13T08:11:48.680 に答える
11

この問題に対処するために、次の表記法を使用するのが好きです。

public class TestReflectionHelper extends TestReflectionHelperCommon {

    /**
     * @see TestReflectionHelperCommon#TestReflectionHelperCommon()
     */
    public TestReflectionHelper() {
        super();
    }

    /**
     * @see TestReflectionHelperCommon#TestReflectionHelperCommon(Class, String,
     *      Class...)
     */
    public TestReflectionHelper(final Class<?> targetClass,
            final String targetMethod, final Class<?>... parameterTypes) {
        super(targetClass, targetMethod, parameterTypes);
    }

    ...
}
于 2014-03-10T15:44:31.023 に答える
7

まあ、それは大きな理由ではありませんが、これは私の理解です：

インターフェイスを実装するか、メソッドをオーバーライドすると、他の場所（インターフェイスまたはスーパークラス）で説明されたものを効果的に実装し、前の説明に追加するものがない可能性が高いため、次のような@inheritDocツールを入手できます。そのテキストを再利用しましょう（必要に応じて追加します）。

一方、コンストラクターは別の動物です。インターフェースの実装を作成している場合、その実装が別の実装とは異なる理由があるはずです。継承クラスを作成する場合は、親クラスに追加するものが必要です。

ちなみに、これについては2003年からの機能リクエストがあります;）

于 2013-02-13T08:11:26.810 に答える
5

これはJavaDocの制限にすぎません。Miquelが指摘したように、機能のリクエストがありますが、10年間、誰もそれを実装することを気にしませんでした。純粋な怠惰、私は言います。

コンストラクターはJavaで継承されないため、サブクラスでコンストラクターを複製する必要があります。これはすでに十分な複製ですが、JavaDocのために、ドキュメントも複製する必要があります。

優れたドキュメンテーションツールは、優れたプログラミング言語と同じように、重複を排除するのに役立ちます。

于 2013-02-13T12:49:34.850 に答える