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

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

Я использую его везде. По теме усилия для методов выделения я позволяю Eclipse сделать это для меня так, это не дополнительное усилие.

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

Лучший practive должен всегда использовать его (или иметь IDE, заполняют их для Вас)

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

Такая система поддержки всегда хороша для имения.

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

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

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

кроме того, в книге Joshua Block Эффективный Java (2-й выпуск), объект 36 предоставляет больше подробную информацию на преимуществах аннотации.

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

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

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

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

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

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

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

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

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

Это поймает вещи как tostring() вместо toString()

небольшие вещи справка в крупных проектах.

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

protected boolean displaySensitiveInformation() {
  return false;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

@Override в реализации интерфейса бесполезен, так как на практике он не обнаруживает ошибок, которые компиляция все равно не обнаружила бы. Есть только один надуманный сценарий, в котором переопределение средств реализации действительно что-то делает: если вы реализуете интерфейс, а методы интерфейса REMOVES, вы будете уведомлены во время компиляции, что вам следует удалить неиспользуемые реализации. Обратите внимание, что если новая версия интерфейса имеет методы NEW или CHANGED, вы, очевидно, все равно получите ошибку компиляции, поскольку вы не реализуете новый материал.

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

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

Некоторые IDE, такие как Eclipse, даже настроенные со средой выполнения Java 1.6 или выше, поддерживают соответствие Java 1.5 и не позволяют использовать @override как описано выше. Чтобы избежать такого поведения, вы должны перейти к: Свойства проекта -> Компилятор Java -> Установите флажок «Включить параметры для конкретного проекта» -> выберите «Уровень соответствия компилятора» = 6.0 или выше.

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

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

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

Приведенный выше код компилируется и запускается, но если вы переместите указатель мыши внутри некоторого компонента UIComponent, код «что-то сделать» отметит запуск, потому что на самом деле вы не переопределяете базовый метод mouseEntered (MouseEvent ev) . Вы просто создаете новый метод без параметров mouseEntered () . Вместо этого кода

• Используется только в объявлениях методов.
• Указывает, что аннотированный метод декларация отменяет декларацию in supertype.

If used consistently, it protects you from a large class of nefarious bugs.

Use @Override annotation to avoid these bugs: (Spot the bug in the following code:)

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());
    }
}

source: Effective Java

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

. Конечно, этот сценарий по большей части преувеличен;

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

Обеденные философы - у вас 4 человека, сидя за столом, и 4 палочками. Вам нужно 2 палочка для еды. Представьте, что каждый философ пытается есть следующим образом:

1. Подберите левую палочку.
2. Забрать правую палочку.
3. Ешьте.
4. Установите правый палочкой назад.
5. Установите левую палочку назад.

Каждый делает шаг 1. Теперь шаг 2 невозможен, поскольку каждый человек ждет, о том, что он справа от его права, чтобы бросить левый, который они не будут делать. Это тупик. Если они просто по очереди, то они все могли поесть, но вместо этого они все голодают.

Другой хороший способ продемонстрировать тупик с SQL Server.

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

Тлюс здесь, вы можете продемонстрировать его с помощью SQL Management Studio. Я использовал это в прошлом, чтобы объяснить тупики людям, в то время как преподавание «введение в курсы обучения на уровне SQL Server».

Большинство участников имеют проблемы с теорией, но все (обычно) становится ясно, когда они видят это в действии.

Короче говоря: транзакция A (которая не завершена) принимает явную замок таблицы. Вторая транзакция B пытается прочитать из таблицы, заблокированной транзакцией A. Транзакция B не заблокирована до тех пор, пока транзакция не откажется или не откатывается назад.

Вы можете легко объяснить это в коде достаточно легко, создавая два отдельных потока, которые, в свою очередь, создают транзакции. Надеюсь, это поможет.

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

Будьте осторожны при использовании Override, потому что после этого вы не сможете выполнить обратный инжиниринг в starUML; сначала сделайте uml.

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