Когда вы используете аннотацию @Override Java и почему?

каковы наилучшие методы использования Java @Override аннотация и почему?

кажется, что было бы излишним отмечать каждый переопределенный метод с помощью @Override Примечание. Существуют ли определенные ситуации программирования, которые требуют использования @Override и другие, которые никогда не нужно использовать @Override?

27 ответов


используйте его каждый раз, когда вы переопределяете метод для двух преимуществ. Сделайте это, чтобы вы могли воспользоваться проверкой компилятора, чтобы убедиться, что вы действительно переопределяете метод, когда вы думаете, что это так. Таким образом, если вы допустили распространенную ошибку, неправильно написав имя метода или неправильно сопоставив параметры, вы будете предупреждены, что ваш метод на самом деле не переопределяет, как вы думаете. Во-вторых, это упрощает понимание вашего кода, потому что это более очевидно, когда методы перезаписанный.

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


Я думаю, что это наиболее полезно в качестве напоминания времени компиляции, что целью метода является переопределение родительского метода. В качестве примера:

protected boolean displaySensitiveInformation() {
  return false;
}

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

предположим, что этот метод изменен в родительском классе на

protected boolean displaySensitiveInformation(Context context) {
  return true;
}

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

чтобы ответить на ваш вопрос: вы должны использовать аннотацию @Override, если отсутствие метода с той же сигнатурой в суперклассе указывает на ошибку.


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

нет излишества, когда вы кодируете. Это не стоит вам ничего вводить @override, но экономия может быть огромной, если вы неправильно написали имя метода или получили подпись немного неправильно.

подумайте об этом так: за время, которое вы прошли здесь и набрали этот пост, вы в значительной степени использовали больше времени, чем вы потратите на ввод @override до конца своей жизни; но один ошибки он мешает может спасти вас часы.

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

не могли бы вы придумать лучший механизм на Java, чтобы гарантировать, что когда пользователь намеревался переопределить метод, он действительно это сделал?

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


Я всегда использую тег. Это простой флаг времени компиляции, чтобы поймать небольшие ошибки, которые я мог бы сделать.

Он будет ловить такие вещи, как tostring() вместо toString()

мелочи помогают в крупных проектах.


С помощью @Override аннотация действует как гарантия времени компиляции от общей ошибки программирования. Это вызовет ошибку компиляции, если у вас есть аннотация метода, который вы фактически не переопределяете метод суперкласса.

наиболее распространенным случаем, когда это полезно, является изменение метода в базовом классе, чтобы иметь другой список параметров. Метод в подклассе, который использовался для переопределения метода суперкласса, больше не будет этого делать из-за измененного метода подпись. Это иногда может вызвать странное и неожиданное поведение, особенно при работе со сложными структурами наследования. The @Override гарантии аннотации против этого.


чтобы воспользоваться проверкой компилятора, вы всегда должны использовать переопределение аннотации. Но не забывайте, что Java Compiler 1.5 не позволит эту аннотацию при переопределении методов интерфейса. Вы просто можете использовать его для переопределения методов класса (абстрактных или нет).

некоторые IDEs, как Eclipse, даже настроенные с Java 1.6 runtime или выше, они поддерживают соответствие Java 1.5 и не позволяют использовать @override, как описано выше. Чтобы избежать такого поведения, вы должны перейти на: проект Свойства - > компилятор Java - > проверка "включить параметры конкретного проекта "- > выберите" уровень соответствия компилятора " = 6.0 или выше.

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

это помогает избежать некоторых типичных ошибок, например, когда вы думаете, что переопределяете обработчик событий,а затем ничего не видите. Представьте, что вы хотите добавить прослушиватель событий в некоторый пользовательский интерфейс компонент:

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

приведенный выше код компилируется и запускается, но если вы переместите мышь внутри someUIComponent, код "сделать что-то" заметит запуск, потому что на самом деле вы не переопределяете базовый метод mouseEntered(MouseEvent ev). Вы просто создаете новый метод без параметров mouseEntered(). Вместо этого кода, если вы использовали @Override аннотация вы видели ошибку компиляции, и вы не теряли времени, думая, почему ваш обработчик событий не работал.


@Override on реализация интерфейса непоследовательно, так как нет такой вещи, как "переопределение интерфейса" в java.

@Override on реализация интерфейса бесполезно, так как на практике он не ловит ошибок, которые компиляция все равно не поймает. Существует только один надуманный сценарий, в котором override on implementers действительно что-то делает: если вы реализуете интерфейс, и интерфейс удаляет методы, вы будете уведомлены о время компиляции, которое вы должны удалить неиспользуемые реализации. Обратите внимание, что если новая версия интерфейса имеет новые или измененные методы, вы, очевидно, получите ошибку компиляции в любом случае, поскольку вы не реализуете новый материал.

@Override на интерфейсных реализаторах никогда не должно было быть разрешено в 1.6, и с eclipse, к сожалению, выбирая автоматическую вставку аннотаций в качестве поведения по умолчанию, мы получаем много загроможденных исходных файлов. При чтении кода 1.6, вы не можете видеть из @Override аннотация, если метод фактически переопределяет метод суперкласса или просто реализует интерфейс.

использование @Override при фактическом переопределении метода в суперклассе нормально.


лучше всего использовать его для каждого метода, предназначенного для переопределения, и Java 6+, каждый метод, предназначенный для реализации интерфейса.

во-первых, он ловит орфографические ошибки, такие как"hashcode()" вместо "hashCode()" во время компиляции. Может быть непонятно, почему результат вашего метода не соответствует вашему коду, когда реальная причина заключается в том, что ваш код никогда не вызывается.

кроме того, если суперкласс изменяет подпись метода, переопределения старой подписи могут быть "сиротой", оставленным позади, как запутанный мертвый код. The @Override аннотация поможет вам идентифицировать этих сирот, чтобы их можно было изменить в соответствии с новой подписью.


Если вы часто обнаруживаете, что переопределяете (не абстрактные) методы, вы, вероятно, захотите взглянуть на свой дизайн. Это очень полезно, когда компилятор не поймать ошибку. Например, попытка переопределить initValue () в ThreadLocal, что я и сделал.

использование @Override при реализации методов интерфейса (1.6 + feature) кажется мне немного излишним. Если у вас есть множество методов, некоторые из которых переопределяют, а некоторые нет, это, вероятно, плохой дизайн снова (и ваш редактор, вероятно, покажет, что есть что, если вы не знаете).


@Override на интерфейсах на самом деле полезны, потому что вы получите предупреждения, если измените интерфейс.


другое дело, что это делает его более очевидным при чтении кода, что он изменяет поведение родительского класса. Чем может помочь в отладке.

кроме того, в книге Джошуа блока "эффективная Java" (2-е издание) пункт 36 дает более подробную информацию о преимуществах аннотации.


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


всякий раз, когда метод переопределяет другой метод, или метод реализует подписи в интерфейсе.

на @Override аннотация уверяет вас, что вы действительно переопределили что-то. Без аннотации вы рискуете ошибками или разницей в типах параметров и количестве.


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


лучшая практика-всегда использовать его (или иметь 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, потому что вы не можете сделать обратный инженер в starUML впоследствии; сначала сделайте uml.


кажется, что мудрость здесь меняется. Сегодня я установил IntelliJ IDEA 9 и заметил, что его" отсутствует @ Override inspection " теперь ловит не только реализованные абстрактные методы, но и реализованные методы интерфейса. В кодовой базе моего работодателя и в моих собственных проектах я давно привык использовать @Override только для первых-реализованных абстрактных методов. Однако, переосмыслив привычку, достоинством использования аннотаций в обоих случаях становится четкий. Несмотря на то, что он более многословен, он защищает от хрупкий базовый класс проблема (не такая серьезная, как примеры, связанные с C++), где изменяется имя метода интерфейса, сирота метода потенциальной реализации в производном классе.

конечно, этот сценарий в основном гипербола; производный класс больше не будет компилироваться, теперь не хватает реализации переименованного метода интерфейса, и сегодня, вероятно, будет использовать Переименовать Способ рефакторинг операция для массового обращения ко всей базе кода.

учитывая, что проверка идеи не настраивается, чтобы игнорировать реализованные методы интерфейса, сегодня я изменю как свою привычку, так и критерии обзора кода моей команды.


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

кстати, если мы не объявили аннотацию @Override в подклассе, но мы переопределяем некоторые методы super, то функция может работать как эта с @Override. Но этот метод не может уведомить разработчика, когда метод super был изменен. Потому что он не знал цели разработчика-переопределить метод super или определить новый метод?

поэтому, когда мы хотим переопределить этот метод, чтобы использовать полиморфизм, нам лучше добавить @Override над методом.


Я использую его как можно больше, чтобы определить, когда метод переопределяется. Если вы посмотрите на язык программирования Scala, у них также есть ключевое слово override. Я нахожу это полезным.


Это позволяет вам (ну, компилятор) поймать, когда вы использовали неправильное написание имени метода, которое вы переопределяете.


переопределить аннотацию используется для использования компилятора для проверки того, действительно ли вы переопределяете метод из родительского класса. Он используется для уведомления, если вы делаете какую-либо ошибку, как ошибка неправильного написания имени метода, ошибка не правильно соответствующие параметры


Я думаю, что лучше всего кодировать @ override, когда это разрешено. это помогает для кодирования. однако следует отметить, что для ecipse Helios, sdk 5 или 6, аннотация @override для реализованных методов интерфейса разрешена. что касается Galileo, либо 5, либо 6, @override аннотация не допускается.


аннотации предоставляют компилятору метаданные о коде, и аннотация @Override используется в случае наследования, когда мы переопределяем любой метод базового класса. Он просто сообщает компилятору, что вы переопределяете метод. Это может избежать некоторых распространенных ошибок, которые мы можем сделать, например, не следовать правильной подписи метода или неправильно указывать имя метода и т. д. Поэтому рекомендуется использовать аннотацию @Override.


для меня @ Override гарантирует, что у меня есть подпись метода правильно. Если я помещаю аннотацию и метод неправильно написан, компилятор жалуется, давая мне знать, что что-то не так.


Simple - если вы хотите переопределить метод, присутствующий в вашем суперклассе, используйте @Override аннотация, чтобы сделать правильное переопределение. Компилятор предупредит вас, если вы не переопределите его правильно.