Javadoc 주석을 구현에 추가해야합니까?


109

인터페이스에 Javadoc 주석을 추가하고 구현에 Javadoc이 아닌 주석을 추가하는 것이 올바른 방법입니까?

대부분의 IDE는 주석을 자동 생성 할 때 구현을 위해 비 JavaDoc 주석을 생성합니다. 구체적인 방법에 설명이 있어야하지 않습니까?

답변:


67

구현 전용 (재정의가 아님) 인 메서드의 경우, 특히 공용 인 경우에는 그렇지 않습니다.

재정의 상황이 있고 텍스트를 복제하려는 경우에는 절대 그렇지 않습니다. 복제는 불일치를 일으키는 확실한 방법입니다. 결과적으로 사용자는 상위 유형 또는 하위 유형에서 메소드를 검사하는지 여부에 따라 메소드에 대해 다른 이해를 갖게됩니다. @inheritDoc문서 사용 또는 제공 안 함-IDE는 Javadoc보기에서 사용할 수있는 가장 낮은 텍스트를 사용합니다.

제쳐두고, 재정의하는 버전이 상위 유형의 문서에 내용을 추가하면 문제가 발생할 수 있습니다. 박사 과정에서이 문제를 연구 한 결과 일반적으로 수퍼 타입을 통해 호출하는 경우 대체 버전의 추가 정보를 알지 못합니다.

이 문제를 해결하는 것은 내가 구축 한 프로토 타입 도구의 주요 기능 중 하나였습니다. 메소드를 호출 할 때마다 해당 대상 또는 잠재적 인 재정의 대상에 중요한 정보 (예 : 충돌 동작)가 포함되어 있는지 여부가 표시됩니다. 예를 들어,지도에 put을 호출 할 때 구현이 TreeMap 인 경우 요소를 비교할 수 있어야한다는 사실을 상기했습니다.


1
TreeMap을 사용할 때 요소를 비교할 수 있어야한다는 사실을 이미 알고 계십니까? 구현은 또한 충돌하는 동작을 구현해서는 안됩니다.
Jimmy T.

1
나는 이것이 정답해야한다고 생각 stackoverflow.com/a/39981265/419516
user219882

26

구현과 인터페이스 모두에 javadoc이 있어야합니다. 일부 도구를 사용하면 @inheritDoc 키워드를 사용하여 인터페이스 문서를 상속 할 수 있습니다.

/**
 * @inheritDoc
 *
 * This implementation is very slow when b equals 3.
 */
public foo(int b)
{ ... }

5
'일부 도구'란 정확히 무엇입니까? 즉시 작동합니까 아니면 특정 플러그인에 바인딩되어 있습니까?
jediz 2014.12.05

나는 이클립스 용도를 알고 {@inheritDoc}당신이 경우에만 작동 하지 않는 주석이 @Override첫 번째
ksnortum

24

약간의 좋은 습관은

/**
 * {@inheritDoc}
 */

구현의 javadoc (구현 세부 사항에 대해 설명 할 추가 사항이없는 경우).


2
인터페이스를 갖는 요점은 메소드가 여러 방법으로 구현 될 수 있다는 것입니다. 주석을 상속하려는 경우 구현에서 주석을 갖는 이유는 무엇입니까?
Vaishak Suresh

16
위의 태그를 사용한 다음 태그 아래에 필요한 추가 문서를 넣습니다.
Ben Page

17

일반적으로 메서드를 재정의 할 때 기본 클래스 / 인터페이스에 정의 된 계약을 준수하므로 원래 javadoc을 어떻게 든 변경하고 싶지 않습니다. 따라서 다른 답변에서 언급 된 @inheritDoc또는 @see태그 의 사용은 필요하지 않으며 실제로 코드에서 노이즈로만 사용됩니다. 모든 현명한 도구는 여기에 지정된대로 수퍼 클래스 또는 인터페이스에서 javadoc 메소드를 상속합니다 .

Inherit from classes and interfaces - Inheriting of comments occurs in all
three possible cases of inheritance from classes and interfaces:

- When a method in a class overrides a method in a superclass
- When a method in an interface overrides a method in a superinterface
- When a method in a class implements a method in an interface

일부 도구 (내가보고있는 이클립스!)는 메서드를 재정의 할 때 기본적으로 이러한 도구를 생성한다는 사실은 슬픈 상태 일 뿐이며 쓸모없는 노이즈로 코드를 복잡하게 만드는 것을 정당화하지 않습니다.


물론 재정의 메서드에 실제로 주석을 추가하려는 경우 (일반적으로 일부 추가 구현 세부 정보 또는 계약을 좀 더 엄격하게 만드는) 반대의 경우가있을 수 있습니다. 그러나이 경우 다음과 같은 작업을 거의 원하지 않습니다.

/**
 * {@inheritDoc}
 *
 * This implementation is very, very slow when b equals 3.
 */

왜? 상속 된 주석이 매우 길 수 있기 때문입니다. 이 경우 3 개의 긴 문단 끝에 추가 문장이있는 것을 누가 알아 차리게 될까요 ?? 대신 자신의 의견을 적어두면됩니다. 모든 javadoc의 도구는 항상 어떤 종류의 표시 정의 는 기본 클래스의 코멘트를 읽을하기 위해 클릭 할 수있는 링크를. 그것들을 섞는 것은 의미가 없습니다.


6

@see 인터페이스의 설명에 대한 링크를 생성합니다. 그러나 구현에 대한 세부 사항도 추가하는 것이 좋습니다.


6
@see인터페이스 방법에 연결을 사용 하는 IMO 는 좋은 방법이며 대부분의 경우 충분합니다. 인터페이스 메소드에서 구체적인 구현으로 javadoc을 복사하면 정보가 중복되고 빠르게 일관성이 없게 될 수 있습니다. 그러나 구현에 대한 추가 정보는 javadoc에 추가해야합니다.
Piotr

1
추가 문서는 인터페이스에서 문서를 복사하는 것이 아니라 메소드와 같은 것들을 구현하는 방법을 설명하기위한 것입니다. 인터페이스 문서를 사용하여 결과 / 목표 (애플리케이션 상태 또는 메서드 반환)가 무엇인지 설명하는 반면 구현에서는이 목표를 달성하는 방법을 설명하는 것이 좋습니다.
redben 2010-06-19

4

Sjoerd는 인터페이스와 구현 모두에 JavaDoc이 있어야한다고 올바르게 말합니다. 인터페이스 JavaDoc은 메소드의 계약을 정의해야합니다.-메소드가 수행해야하는 작업, 필요한 입력, 리턴해야하는 값 및 오류 발생시 수행해야하는 작업.

구현 문서에는 계약에 대한 확장 또는 제한 사항과 구현, 특히 성능에 대한 적절한 세부 정보가 나와 있어야합니다.


0

생성 된 javadoc을 위해 예, 중요합니다. 인터페이스 만 사용하여 구체적인 구현에 대한 참조를 선언하면 IDE에서 인터페이스의 메서드를 검색하므로 그렇지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.