Почему inheritedDoc не определен в конструкторах?

Мне было интересно, существует ли какая-то действительная причина, почему 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? Javadoc не наследуется, если я не использую тег inheritDoc, что означает, что я хорошо знаю, что хочу повторно использовать документацию. Что должно помешать мне сделать это для constructors?

Ответ 1

Что должно помешать мне сделать это для конструкторов?

Предположительно тот факт, что конструкторы не наследуются. Хотя они часто заканчивают тем же параметром (с тем же значением), что и конструкторы в суперклассе, это не почти такая четкая связь, как с методами.

Я вижу практическое значение, но в равной степени я могу понять, почему что-то, что на самом деле не унаследовано, не должно иметь @inheritDoc. Было бы неплохо, если бы вы могли наследовать биты документации, например, если вы собираетесь передать значение параметра непосредственно конструктору суперкласса, было бы неплохо иметь возможность эффективно связываться с этой документацией...

Ответ 2

Мне нравится использовать следующие обозначения для решения этой проблемы:

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);
    }

    ...
}

Ответ 3

Ну, это не очень хорошая причина, но это мое понимание:

Если вы реализуете интерфейс или переопределяете метод, вы эффективно реализуете то, что было описано в другом месте (в интерфейсе или суперклассе), и есть хорошие шансы, что вам нечего добавить к предыдущему описанию, так что вы получаете инструмент @inheritDoc, который позволяет вам просто повторно использовать этот текст (и при необходимости добавлять к нему).

Конструктор, с другой стороны, является другим животным: если он создает реализацию интерфейса, должна быть причина, что эта реализация отличается от другой. Если вы создаете наследующий класс, должно быть что-то, что вы добавляете к родительскому классу.

О, кстати, там запрос функции от 2003 года на этом;)

Ответ 4

Это просто ограничение JavaDoc. Как Микель отметил, есть запрос функции для него, но через 10 лет никто не потрудился его реализовать. Чистая ленивость, говорю я.

Поскольку конструкторы не наследуются в Java, вы принудительно дублируете конструктор в подклассе. Это уже достаточно дублирование, но теперь из-за JavaDoc вы также вынуждены дублировать документацию.

Хороший инструмент документации поможет вам устранить дублирование, как хороший язык программирования.