Java의 @Override 주석을 사용하는 시기와 이유는 무엇입니까?

Java의 @Override 주석을 사용하는 시기와 이유는 무엇입니까?

잠겼습니다. 이 질문과 답변은이 질문은 부적절하지만 역사적 의미가 있기 때문에 잠겨 있습니다.현재 새로운 답변이나 상호작용을 받아들이지 않고 있습니다.

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주석은 일반적인 프로그래밍 오류에 대한 컴파일 시간 보호 역할을 합니다.실제로 슈퍼클래스 메서드를 재정의하지 않는 메서드에 주석이 있는 경우 컴파일 오류가 발생합니다.

이 방법이 유용한 가장 일반적인 경우는 기본 클래스의 메서드를 다른 파라미터 리스트로 변경하는 경우입니다.superclass 메서드를 덮어쓰기 위해 사용된 서브클래스의 메서드는 메서드 시그니처가 변경되었기 때문에 더 이상 덮어쓰지 않습니다.이로 인해 특히 복잡한 상속 구조를 다룰 때 이상하고 예상치 못한 동작이 발생할 수 있습니다.그@Override주석은 이 문제를 방지합니다.

컴파일러 체크를 이용하려면 항상 주석 덮어쓰기를 사용해야 합니다.그러나 Java 컴파일러 1.5는 인터페이스 메서드를 재정의할 때 이 주석을 허용하지 않는다는 것을 잊지 마십시오.클래스 메서드(추상 여부)를 재정의하는 데 사용할 수 있습니다.

일부 IDE(Eclipse)는 Java 1.6 런타임 이상으로 구성하더라도 Java 1.5와의 컴플라이언스를 유지하고 위에서 설명한 대로 @override 사용을 허용하지 않습니다.이러한 동작을 방지하려면 [Project Properties]-> [ Java Compiler ]-> [ Enable Project Specific Settings ]-> [ Enable Project Specific Settings ]체크박스를 켜겠습니다[ Compiler Compliance Level ]= 6.0 이후를 선택합니다.

기본이 인터페이스 또는 클래스인 경우 메서드를 독립적으로 재정의할 때마다 이 주석을 사용합니다.

이렇게 하면 이벤트핸들러를 덮어쓰고 있다고 생각했을 때 아무 일도 일어나지 않는 등 일반적인 오류를 회피할 수 있습니다.이벤트 수신기를 일부 UI 구성 요소에 추가한다고 가정합니다.

someUIComponent.addMouseListener(new MouseAdapter(){
  public void mouseEntered() {
     ...do something...
  }
});

위의 코드가 컴파일되어 실행되지만, 만약 당신이 마우스를 내부로 이동한다면UIC 구성 요소 "do something" 코드가 실행되는 것을 기록합니다.실제로 기본 메서드를 덮어쓰지 않기 때문입니다.mouseEntered(MouseEvent ev)파라미터가 필요없는 새로운 메서드를 작성하기만 하면 됩니다.mouseEntered()이 코드 대신,@Override주석은 컴파일 오류가 발생했으며 이벤트 핸들러가 실행되지 않은 이유에 대해 생각하는 데 시간을 낭비하지 않았습니다.

@java에서는 "인터페이스 오버라이드"라는 것이 없기 때문에 인터페이스 구현에서의 오버라이드는 일관성이 없습니다.

@인터페이스 실장에서의 오버라이드는 실제로는 컴파일로 검출할 수 없는 버그를 검출하지 않기 때문에 쓸모가 없습니다.실장자에 대한 덮어쓰기가 실제로 이루어지는 경우는 단 한 가지입니다.인터페이스를 실장하고 있고, 그 인터페이스가 REMOBES 메서드를 삭제했을 경우는, 미사용의 실장을 삭제할 필요가 있는 것을 컴파일시에 통지합니다.새로운 버전의 인터페이스에 NEW 메서드 또는 CHANGED 메서드가 있는 경우, 새로운 것을 실장하고 있지 않기 때문에 컴파일 에러가 발생합니다.

@인터페이스 실장자에 대한 덮어쓰기는 1.6에서는 허용되지 않았습니다.기본 동작으로 주석 자동 삽입을 선택한 이클립스로 인해 많은 소스 파일이 어수선하게 되었습니다.1.6 코드를 읽을 때 메서드가 실제로 슈퍼클래스의 메서드를 오버라이드하는지 또는 인터페이스만 구현하는지 @Override 주석에서 확인할 수 없습니다.

슈퍼클래스에서 실제로 메서드를 덮어쓸 때 @Override를 사용해도 됩니다.

오버라이드로 의도된 모든 메서드 및 인터페이스의 구현으로 의도된 모든 메서드 Java 6+에 사용하는 것이 가장 좋습니다.

우선, 다음과 같은 오타를 발견합니다.hashcode()"가 아니라 ".hashCode()컴파일 시.코드가 호출되지 않는 것이 진짜 원인인데 메서드의 결과가 코드와 일치하지 않는 이유를 디버깅하는 것은 곤란할 수 있습니다.

또한 슈퍼클래스가 메서드시그니처를변경했을경우오래된시그니처의오버라이드는혼란스러운데드코드로남길수있습니다.그@Override주석을 사용하면 고아들을 식별하여 새 시그니처에 맞게 수정할 수 있습니다.

비추상적(비추상적) 방법을 자주 사용하는 경우 설계를 살펴보는 것이 좋습니다.컴파일러가 에러를 검출할 수 없는 경우에 매우 편리합니다.예를 들어 ThreadLocal에서 initValue()를 덮어쓰려고 합니다.

인터페이스 메서드(1.6+기능)를 실장할 때 @Override를 사용하는 것은 저에게 좀 지나친 것 같습니다.일부 메서드는 덮어쓰고 일부는 그렇지 않은 메서드가 많이 있는 경우 설계가 다시 잘못되었을 수 있습니다(그리고 에디터는 어떤 메서드가 어떤 것인지 알 수 없는 경우 어떤 것인지 표시할 수 있습니다).

@인터페이스의 덮어쓰기는 실제로 도움이 됩니다.인터페이스를 변경하면 경고가 표시되기 때문입니다.

또 다른 기능은 코드를 읽을 때 부모 클래스의 동작을 변화시키고 있음을 더 명확하게 하는 것입니다.디버깅에 도움이 됩니다.

또한 Joshua Block의 저서 Effective Java (2판)에서 항목 36은 주석의 이점에 대해 더 자세히 설명합니다.

인터페이스 메서드를 구현할 때 @Override를 사용하는 것은 전혀 의미가 없습니다.이 경우 컴파일러가 이미 당신의 실수를 알아채기 때문에 불필요한 혼란일 뿐입니다.

메서드가 다른 메서드를 덮어쓰거나 인터페이스에 시그니처를 실장하는 경우.

그@Override주석을 사용하면 실제로 무언가를 덮어썼다는 것을 확인할 수 있습니다.주석이 없으면 맞춤법이 잘못되거나 매개 변수 유형과 번호가 다를 수 있습니다.

매번 쓰고 있어요.1년 후에 코드를 재방문했을 때, 처음에 무슨 생각을 하고 있었는지 잊어버렸을 때, 무슨 일이 일어나고 있는지를 재빠르게 파악하기 위해서 사용할 수 있는 정보입니다.

베스트 프랙티스는, 항상 사용하는 것(또는 IDE로 기입하는 것)입니다.

@Override의 유용성은 계층 아래로 보고되지 않은 부모 클래스의 변경을 검출하는 것입니다.이것이 없으면 메서드 시그니처를 변경할 수 있지만 오버라이드를 변경하는 것을 잊어버릴 수 있습니다.@Override를 사용하면 컴파일러가 대신 그것을 검출합니다.

그런 안전망은 항상 갖추면 좋아요.

어디서든 사용해요.마킹 방법에 대해서는, Eclipse에 맡기고 있기 때문에, 추가 작업은 없습니다.

저는 지속적인 리팩터링에 신념을 가지고 있습니다. 그래서 모든 사소한 것들로 더 원활하게 진행되도록 할 것입니다.

• 메서드 선언에만 사용됩니다.
• 주석이 달린 메서드 선언이 슈퍼타입의 선언보다 우선함을 나타냅니다.

꾸준히 사용하면 많은 종류의 유해한 벌레로부터 보호할 수 있습니다.

이러한 버그를 회피하려면 @Override 주석을 사용합니다(다음 코드에서 버그를 찾아냅니다).

public class Bigram {
    private final char first;
    private final char second;
    public Bigram(char first, char second) {
        this.first  = first;
        this.second = second;
    }
    public boolean equals(Bigram b) {
        return b.first == first && b.second == second;
    }
    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram> s = new HashSet<Bigram>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram(ch, ch));
        System.out.println(s.size());
    }
}

출처: 유효한 Java

Override를 사용할 때는 Star에서는 Reverse Engineer를 수행할 수 없으므로 주의하십시오.그 후에 UML; UML을 먼저 만들어라.

이곳의 지혜가 바뀌고 있는 것 같다.오늘 IntelliJ IDEA 9를 설치했는데, "Missing @Override inspection"이 구현된 추상 메서드뿐만 아니라 구현된 인터페이스 메서드도 포착되었습니다.제 고용주의 코드 베이스나 제 자신의 프로젝트에서는 오랫동안 @Override를 전자의 추상적인 방법에만 사용해 왔습니다.그러나 습관을 다시 생각해 보면 두 경우 모두 주석을 사용하는 장점이 분명해집니다.보다 상세하지만 인터페이스 메서드 이름이 변경되어 파생 클래스에서 구현하려는 메서드를 발생시키는 취약한 기본 클래스 문제(C++ 관련 예만큼 심각하지 않음)로부터 보호합니다.

물론 이 시나리오는 대부분 하이퍼볼입니다.파생 클래스는 컴파일을 하지 않고 이름이 변경된 인터페이스 메서드가 구현되지 않습니다.오늘날 코드 베이스 전체에 대처하기 위해 이름 변경 메서드 리팩터링 조작을 사용할 수 있습니다.

IDEA의 검사는 구현된 인터페이스 방식을 무시하도록 구성할 수 없기 때문에 오늘은 습관 및 팀의 코드 검토 기준을 모두 변경합니다.

주석 @Override는 개발자가 부모 클래스 또는 인터페이스에서 올바른 메서드를 덮어쓸지 여부를 확인하는 데 사용됩니다.슈퍼의 메서드 이름이 변경되면 컴파일러는 그 케이스를 통지할 수 있습니다.이것은 슈퍼클래스 및 서브클래스와의 일관성을 유지하기 위한 것입니다.

참고로 서브클래스에서 주석 @Override를 발표하지 않았지만 슈퍼 메서드 중 몇 가지를 덮어쓰면 함수는 @Override와 같이 동작할 수 있습니다.그러나 이 메서드는 슈퍼의 메서드가 변경되었을 때 개발자에게 알릴 수 없습니다.개발자의 목적을 몰랐기 때문에 슈퍼의 메서드를 덮어쓰거나 새로운 메서드를 정의합니까?

따라서 폴리모피즘을 사용하기 위해 이 메서드를 덮어쓰려면 메서드 위에 @Override를 추가하는 것이 좋습니다.

나는 그것을 가능한 한 사용하여 메서드가 오버라이드 되는 시기를 식별합니다.Scala 프로그래밍 언어를 보면 override 키워드도 있습니다.유용하다고 생각합니다.

이것에 의해, 우선하는 메서드명의 철자가 잘못되어 있는 경우를, (컴파일러가) 검출할 수 있습니다.

오버라이드 주석은 컴파일러를 이용하여 실제로 부모 클래스에서 메서드를 오버라이드하고 있는지 여부를 확인하기 위해 사용됩니다.메서드 이름의 철자가 틀리거나 파라미터가 올바르게 일치하지 않는 등의 실수가 있을 경우 이를 통지하기 위해 사용됩니다.

허가될 때마다 @code를 코드화하는 것이 가장 좋다고 생각합니다.코딩에 도움이 됩니다.단, ecipse Helios, sdk 5 또는 6의 경우 구현된 인터페이스 방법에 대해 @override 주석이 허용됩니다. Galileo, 5 또는 6의 경우 @override 주석이 허용되지 않습니다.

주석에서는 코드에 관한 메타데이터를 컴파일러에 제공하고 @Override는 기본 클래스의 메서드를 덮어쓸 때 상속 시 사용됩니다.컴파일러에 당신이 메서드를 덮어쓰고 있다는 것만 알립니다.이는 우리가 흔히 저지르는 실수를 회피할 수 있습니다.예를 들어, 메서드의 올바른 서명을 따르지 않거나 메서드의 이름으로 철자를 잘못 입력하는 등의 실수를 방지할 수 있습니다.따라서 @Override 주석을 사용하는 것이 좋습니다.

@Override를 사용하면 메서드의 서명이 정확해집니다.주석을 달았을 때 메서드의 철자가 틀리면 컴파일러가 뭔가 잘못되었다는 것을 알립니다.

심플 – 슈퍼클래스에 있는 메서드를 덮어쓰려면@Override주석을 사용하여 올바른 재지정 작업을 수행합니다.올바르게 덮어쓰지 않으면 컴파일러에 의해 경고가 표시됩니다.

언급URL : https://stackoverflow.com/questions/94361/when-do-you-use-javas-override-annotation-and-why