일부 인터페이스에서 코드를 더 읽기 쉽게 만들기 위해 하나 이상의 문자로 일반 유형 매개 변수의 이름을 지정하고 싶습니다.
뭔가 ….
Map<Key,Value>
대신에 …
Map<K,V>
그러나 메소드에 관해서는 유형 매개 변수가 자바 클래스처럼 보이며 혼란 스럽습니다.
public void put(Key key, Value value)
이것은 Key와 Value가 클래스 인 것처럼 보입니다. 나는 몇 가지 표기법을 발견하거나 생각했지만 Sun의 관습이나 일반적인 모범 사례와 같은 것은 없습니다.
내가 추측하거나 찾은 대안 …
Map<KEY,VALUE>
Map<TKey,TValue>
답변
Oracle은 Java Tutorials> Generics> Generic Types 에서 다음을 권장합니다 .
유형 매개 변수 명명 규칙
규칙에 따라 유형 매개 변수 이름은 단일 대문자입니다. 이것은 이미 알고 있는 변수 명명 규칙 과는 뚜렷한 대조를 이루며 그럴만 한 이유가 있습니다.이 규칙이 없으면 형식 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기 어려울 것입니다.
가장 일반적으로 사용되는 유형 매개 변수 이름은 다음과 같습니다.
- E-요소 (Java Collections Framework에서 광범위하게 사용됨)
- K-키
- N-숫자
- T-유형
- V-가치
- S, U, V 등-2, 3, 4 종
Java SE API 및이 단원의 나머지 부분에서 이러한 이름이 사용되는 것을 볼 수 있습니다.
나는 개발자와 가능한 유지 보수 자들 사이의 혼란을 피하기 위해 그것을 고수 할 것입니다.
답변
추가 Type
좋은 토론은 DZone 페이지의 매개 변수화 된 유형에 대한 명명 규칙 의 주석에서 찾을 수 있습니다 .
Erwin Mueller의 의견을 참조하십시오. 그의 제안은 나에게 완벽하게 분명하게 이해가됩니다. Append the wordType
.
사과를 사과, 차를 차라고 부릅니다. 문제의 이름은 데이터 유형의 이름입니다. ( OPP 에서 클래스는 기본적으로 새로운 데이터 유형을 정의합니다.) 따라서 “유형”이라고 부릅니다.
원래 게시물의 기사에서 가져온 Mueller의 예 :
public interface ResourceAccessor < ResourceType , ArgumentType , ResultType > {
public ResultType run ( ResourceType resource , ArgumentType argument );
}
추가 T
중복 질문은 Andy Thomas 가이 답변 을 제공합니다 . 여러 문자 유형 이름이 단일 대문자로 끝나야한다고 제안하는 Google 스타일 가이드에서 발췌 한 내용을 참고하세요 T
.
답변
공식 명명 규칙에서 단일 문자 사용을 권장하는 이유 는 다음과 같습니다.
이 규칙이 없으면 유형 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기 어려울 것입니다.
현대 IDE에서는 이유가 더 이상 유효하지 않다고 생각합니다. IntelliJ Idea는 일반 클래스와 다른 색상으로 일반 유형 매개 변수를 표시합니다.
IntelliJ Idea 2016.1에 표시된 일반 유형의 코드
이러한 구별 때문에 일반 유형과 동일한 규칙으로 일반 유형에 대해 더 긴 설명 이름 을 사용 합니다. T 또는 Type과 같은 접두사 및 접미사를 불필요한 노이즈로 간주하고 더 이상 제네릭 유형을 시각적으로 구분할 필요가 없기 때문에 추가하지 않습니다.
참고 : Eclipse 또는 Netbeans 사용자가 아니기 때문에 유사한 기능을 제공하는지 여부를 알 수 없습니다.
답변
예, 클래스 이름과 명확하게 구별되는 한 유형 변수에 대해 다중 문자 이름을 사용할 수 있습니다.
이것은 2004 년에 제네릭을 도입하면서 Sun이 제안한 규칙과 다릅니다. 그러나 :
- 둘 이상의 규칙이 있습니다.
- 다중 문자 이름은 Google의 Java 스타일과 같은 다른 Java 스타일과 일치 합니다.
- 읽을 수있는 이름이 (놀랍습니다!) 더 읽기 쉽습니다.
가독성
일부 인터페이스에서 코드를 더 읽기 쉽게 만들기 위해 하나 이상의 문자로 일반 유형 매개 변수의 이름을 지정하고 싶습니다.
가독성이 좋습니다.
비교:
public final class EventProducer<L extends IEventListener<E>,E>
implements IEventProducer<L,E> {
에:
public final class EventProducer<LISTENER extends IEventListener<EVENT>,EVENT>
implements IEventProducer<LISTENER, EVENT> {
또는 Google의 다중 문자 규칙 :
public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT>
implements IEventProducer<ListenerT, EventT> {
public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT>
implements IEventProducer<ListenerT, EventT> {
Google 스타일
구글 자바 스타일 가이드가 있습니다 단일 문자 이름과 멀티 문자 클래스와 같은 T.로 끝나는 이름을 모두
각 유형 변수는 다음 두 가지 스타일 중 하나로 이름이 지정됩니다.
임의로 하나의 번호 뒤에 단일 대문자 (예컨대
E
,T
,X
,T2
)클래스에 사용되는 형식의 이름 (섹션 5.2.2, 클래스 이름 참조) 뒤에 대문자 T가옵니다 (예 :
RequestT
,FooBarT
).
이슈
“이 규칙이 없으면 유형 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기 어려울 것입니다.” – Oracle 자습서에서 “일반 유형”
위에서 살펴본 것처럼 단일 문자 이름이 유형 매개 변수를 클래스 이름과 구별하는 유일한 방법은 아닙니다.
JavaDoc에서 의미하는 유형 매개 변수를 문서화하지 않는 이유는 무엇입니까?
@param
JavaDoc 요소가 더 긴 설명을 제공 할 수 있다는 것은 사실입니다 . 그러나 JavaDocs가 반드시 표시되지 않는 것도 사실입니다. (예를 들어, 유형 매개 변수 이름을 표시하는 컨텐츠 지원이 Eclipse에 있습니다.)
다중 문자 유형 매개 변수 이름은 Oracle 규칙을 따르지 않습니다!
Sun의 많은 원래 규칙은 Java 프로그래밍에서 거의 보편적으로 따릅니다.
그러나이 특별한 관습은 그렇지 않습니다.
경쟁 관례 중 최선의 선택은 의견의 문제입니다. 이 경우 Oracle이 아닌 다른 규칙을 선택하는 결과는 미미합니다. 귀하와 귀하의 팀은 귀하의 필요에 가장 적합한 대회를 선택할 수 있습니다.
답변
javadoc을 사용하여 최소한 일반 클래스의 사용자에게 단서를 제공 할 수 있습니다. 나는 여전히 그것을 좋아하지 않지만 (@ chaper29에 동의합니다) 문서가 도움이됩니다.
예 :
/**
*
* @param <R> - row
* @param <C> - column
* @param <E> - cell element
*/
public class GenericTable<R, C, E> {
}
내가 알려진 다른 일은 내 IDE를 사용하여 규칙을 위반하는 클래스를 리팩토링하는 것입니다. 그런 다음 코드를 작업하고 단일 문자로 다시 리팩터링합니다. 어쨌든 많은 유형 매개 변수가 사용되는 경우 더 쉽게 만듭니다.