Java @Override
어노테이션 사용에 대한 모범 사례는 무엇 이며 그 이유는 무엇입니까?
재정의 된 모든 단일 메소드를 @Override
주석 으로 표시하는 것은 과잉 것 같습니다 . @Override
를 사용해야 하는 특정 프로그래밍 상황이 @Override
있습니까?
답변
두 가지 이점을 위해 방법을 재정의 할 때마다 사용하십시오. 컴파일러 검사를 이용하여 실제로 생각할 때 메소드를 대체하는지 확인하십시오. 이 방법으로, 메소드 이름의 철자가 틀리거나 매개 변수가 올바르게 일치하지 않는 일반적인 실수를하면, 메소드가 실제로 생각하는대로 대체되지 않는다는 경고가 표시됩니다. 둘째, 메소드를 덮어 쓸 때 더 명확하기 때문에 코드를 이해하기 쉽게 만듭니다.
또한 Java 1.6에서는 메소드가 동일한 이점을 위해 인터페이스를 구현할 때 표시하는 데 사용할 수 있습니다. 별도의 주석 ( @Implements
) 을 갖는 것이 더 좋을 것이라고 생각 하지만 아무것도 아닌 것보다 낫습니다.
답변
필자는 메서드의 의도가 부모 메서드를 재정의하는 것임을 컴파일 타임 알림으로 가장 유용하다고 생각합니다. 예로서:
protected boolean displaySensitiveInformation() {
return false;
}
기본 클래스의 메소드를 대체하는 위의 메소드와 같은 것을 종종 볼 수 있습니다. 이것은이 클래스의 중요한 구현 세부 사항입니다. 민감한 정보가 표시되는 것을 원하지 않습니다.
이 메소드가 부모 클래스에서 다음과 같이 변경되었다고 가정하십시오.
protected boolean displaySensitiveInformation(Context context) {
return true;
}
이 변경으로 인해 컴파일 시간 오류나 경고가 발생하지 않지만 서브 클래스의 의도 된 동작이 완전히 변경됩니다.
질문에 대답하려면 : 수퍼 클래스에서 동일한 서명을 가진 메소드가 부족하여 버그를 나타내는 경우 @Override 주석을 사용해야합니다.
답변
여기에는 좋은 답변이 많이 있으므로 다른 방법으로 살펴 보겠습니다.
코딩 할 때 과도한 작업이 없습니다. @override를 입력하는 데 비용이 들지 않지만 메소드 이름의 철자가 틀리거나 서명이 약간 잘못되어 있으면 비용이 크게 절감 될 수 있습니다.
다음과 같이 생각하십시오. 여기를 탐색하고이 게시물을 입력 할 때 남은 생애 동안 @override를 입력하는 것보다 훨씬 더 많은 시간을 사용했습니다. 그러나 하나의 오류로 인해 시간을 절약 할 수 있습니다.
Java는 편집 / 컴파일 타임에 실수를하지 않도록하기 위해 할 수있는 모든 것을 수행합니다. 이것은 포괄적 인 테스트 이외의 다른 방법으로는 막을 수없는 모든 종류의 실수를 해결할 수있는 사실상 무료입니다.
사용자가 메소드를 대체하려고 할 때 실제로 수행했는지 확인하기 위해 Java에서 더 나은 메커니즘을 생각해 낼 수 있습니까?
또 다른 깔끔한 효과는 주석을 제공하지 않으면 컴파일 할 때 실수로 부모 메서드를 오버로딩했음을 경고합니다. 의도하지 않은 경우 중요 할 수 있습니다.
답변
나는 항상 태그를 사용합니다. 내가 할 수있는 작은 실수를 포착하는 간단한 컴파일 타임 플래그입니다.
tostring()
대신 같은 것을 잡을 것 입니다toString()
작은 것들이 큰 프로젝트에서 도움이됩니다.
답변
사용하여 @Override
주석을 일반적인 프로그래밍 실수에 대한 컴파일 타임 보호 역할을합니다. 실제로 수퍼 클래스 메소드를 대체하지 않는 메소드에 주석이 있으면 컴파일 오류가 발생합니다.
이것이 가장 유용한 경우는 기본 클래스에서 다른 매개 변수 목록을 갖도록 메소드를 변경하는 경우입니다. 수퍼 클래스 메소드를 대체하는 데 사용 된 서브 클래스의 메소드는 변경된 메소드 서명으로 인해 더 이상 그렇게하지 않습니다. 복잡한 상속 구조를 다룰 때 때때로 이상하고 예기치 않은 동작이 발생할 수 있습니다. @Override
이에 대한 주석 보호.
답변
컴파일러 검사를 이용하려면 항상 재정의 주석을 사용해야합니다. 그러나 Java 컴파일러 1.5는 인터페이스 메소드를 대체 할 때이 주석을 허용하지 않습니다. 클래스 메서드를 재정의하는 데 사용할 수 있습니다 (추상 여부).
Eclipse와 같은 일부 IDE는 Java 1.6 런타임 이상으로 구성되어 있어도 Java 1.5를 준수하고 위에서 설명한대로 @override를 사용할 수 없습니다. 이러한 동작을 피하려면 프로젝트 속성-> Java 컴파일러-> “프로젝트 특정 설정 사용”확인-> “컴파일러 준수 수준”= 6.0 이상을 선택하십시오.
기본이 인터페이스 또는 클래스 인 경우 메소드를 독립적으로 재정의 할 때 마다이 주석을 사용하고 싶습니다.
이벤트 처리기를 재정의하고 아무 일도 일어나지 않는다고 생각할 때 일반적인 오류를 피하는 데 도움이됩니다. 일부 UI 구성 요소에 이벤트 리스너를 추가한다고 가정하십시오.
someUIComponent.addMouseListener(new MouseAdapter(){
public void mouseEntered() {
...do something...
}
});
위의 코드는 컴파일되고 실행되지만 someUIComponent 내에서 마우스를 이동하면 실제로는 기본 메소드를 재정의하지 않기 때문에 “일부 실행”코드가 실행됩니다 mouseEntered(MouseEvent ev)
. 새로운 매개 변수없는 메소드를 작성하기 만하면 mouseEntered()
됩니다. 해당 코드 대신 @Override
주석을 사용한 경우 컴파일 오류가 발생하고 이벤트 핸들러가 실행되지 않는 이유를 생각하는 데 시간을 낭비하지 않았습니다.
답변
자바에서 “인터페이스 재정의”와 같은 것이 없기 때문에 인터페이스 구현 에 대한 @Override 가 일치하지 않습니다.
인터페이스 구현 에 대한 @Override 는 실제로 컴파일이 어쨌든 잡을 수없는 버그를 잡지 않기 때문에 쓸모가 없습니다. 구현 자에 대한 재정의가 실제로 무언가를 수행하는 극도로 페치 된 시나리오는 하나뿐입니다. 인터페이스를 구현하고 인터페이스 REMOVES 메서드를 사용하면 컴파일 타임에 사용되지 않은 구현을 제거해야한다는 알림이 표시됩니다. 인터페이스의 새 버전에 NEW 또는 CHANGED 메소드가있는 경우 새 항목을 구현하지 않을 때 어쨌든 컴파일 오류가 발생합니다.
인터페이스 구현 자에 대한 @Override는 1.6에서 허용되어서는 안되며, Eclipse가 기본 동작으로 주석을 자동 삽입하도록 슬프게 선택하면 많은 혼란스러운 소스 파일이 생성됩니다. 1.6 코드를 읽을 때 메소드가 실제로 슈퍼 클래스의 메소드를 대체하거나 인터페이스를 구현하는 경우 @Override 어노테이션에서 볼 수 없습니다.
실제로 수퍼 클래스에서 메소드를 대체 할 때 @Override를 사용하는 것이 좋습니다.