Quando você usa anotação @Override de Java e por quê?

https://stackoverflow.com/questions/94361

01-07-2019
|

Pergunta

Quais são as melhores práticas para usar anotação @Override de Java e por quê?

Parece que ele seria um exagero para marcar cada método substituído única com a anotação @Override. Há certas situações de programação que chamada para usar o @Override e outros que nunca deve usar o @Override?

Solução

Use-o cada vez que você substituir um método para dois benefícios. Fazê-lo para que você possa aproveitar a verificação do compilador para se certificar de que você realmente está substituindo um método quando você pensa que é. Dessa forma, se você cometer um erro comum de erro ortográfico um nome de método ou não correspondendo corretamente os parâmetros, você será avisado que você método não realmente substituir como você acha que ele faz. Em segundo lugar, faz seu código mais fácil de entender porque é mais evidente quando os métodos são substituídos.

Além disso, em Java 1.6 você pode usá-lo para marca quando um método implementa uma interface para os mesmos benefícios. Eu acho que seria melhor ter uma anotação separado (como @Implements), mas é melhor que nada.

Outras dicas

Eu acho que é mais útil como um lembrete de tempo de compilação que a intenção do método é substituir um método pai. Como um exemplo:

protected boolean displaySensitiveInformation() {
  return false;
}

Muitas vezes você vai ver algo como o método acima que substitui um método na classe base. Este é um importante detalhe de implementação desta classe - nós não queremos informações sensíveis a serem exibidos.

Suponha que este método é alterado na classe pai para

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

Esta mudança não irá causar quaisquer erros de tempo de compilação ou avisos -. Mas muda completamente o comportamento desejado da subclasse

Para responder à sua pergunta: você deve usar a anotação @ Override se a falta de um método com a mesma assinatura em uma superclasse é indicativo de um bug.

Existem muitas respostas boas aqui, então deixe-me oferecer uma outra maneira de olhar para ele ...

Não há exagero quando você está codificando. Não custa nada para tipo @Override, mas a economia pode ser enorme se você mal escrito um nome de método ou tem a assinatura ligeiramente errado.

Pense nisso desta maneira: No tempo que você navegou aqui e digitado este post, você praticamente utilizado mais tempo do que você vai gastar digitação @Override para o resto de sua vida; mas um erro ele impede que você pode economizar horas.

Java faz todo o possível para se certificar de que você não cometer erros em editar / tempo de compilação, esta é uma forma praticamente livre para resolver toda uma classe de erros que não são evitáveis ??de qualquer outra maneira fora de testes abrangentes .

Você poderia chegar a um melhor mecanismo em Java para garantir que quando o utilizador pretende substituir um método, ele realmente fez?

Outro efeito interessante é que, se você não fornecer a anotação que irá avisá-lo em tempo de compilação que você acidentalmente anulou um método pai -. Algo que poderia ser significativo se você não tinha a intenção de fazê-lo

Eu sempre uso o tag. É uma bandeira simples em tempo de compilação para pegar pequenos erros que eu poderia fazer.

Ele vai pegar coisas como tostring() vez de toString()

O pequenas coisas ajuda em grandes projectos.

Usando a anotação @Override atua como uma salvaguarda em tempo de compilação contra um erro de programação comum. Ele vai lançar um erro de compilação, se você tem a anotação em um método que você não está realmente substituindo o método da superclasse.

O caso mais comum onde isso é útil é quando você está mudando um método na classe base para ter uma lista de parâmetros diferente. Um método em uma subclasse que é utilizado para substituir o método da superclasse deixarão de fazê-lo devido a assinatura do método alterado. Isto às vezes pode causar um comportamento estranho e inesperado, especialmente quando se lida com estruturas de herança complexos. As salvaguardas @Override anotação contra isso.

Para tirar proveito do compilador a verificação você deve sempre usar anotação Override. Mas não se esqueça que o compilador Java 1.5 não permitirá que essa anotação ao substituir métodos de interface. Você só pode usá-lo para substituir métodos de classe (abstrato, ou não).

Alguns IDEs, como Eclipse, ainda configuradas com Java 1,6 tempo de execução ou superior, eles manter a conformidade com Java 1,5 e não permitem a @Override uso como descrito acima. Para evitar que o comportamento que você deve ir para:. Propriedades do projeto -> Java Compiler -> Verificar “Ativar configurações específicas do projeto” -> Escolha “Compiler Compliance Nível” = 6.0, ou superior

Eu gosto de usar esta anotação cada vez que eu estou substituindo um método de forma independente, se a base é uma interface ou classe.

Isso ajuda a evitar alguns erros típicos, como quando você está pensando que você está substituindo um manipulador de eventos e, em seguida, você não vê nada acontecer. Imagine que você deseja adicionar um ouvinte de eventos a algum componente da interface do usuário:

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

O acima compila código e run, mas se você mover o mouse dentro someUIComponent o código de “fazer algo” vai notar correr, porque na verdade você não está substituindo o mouseEntered(MouseEvent ev) método base. Você acabou de criar um novo parâmetro-less método mouseEntered(). Em vez de que o código, se você tiver usado a anotação @Override você já viu um erro de compilação e você não tem pensado perder tempo porque seu manipulador de eventos não estava funcionando.

@Override em implementação da interface é inconsistente, pois não há tal coisa como "substituir uma interface" em java.

@Override em implementação da interface é inútil já que na prática ele pega sem bugs que a compilação não iria pegar de qualquer maneira. Há apenas um, cenário muito buscado onde override em implementadores realmente faz alguma coisa: Se você implementar uma interface, ea interface REMOVE métodos, você será notificado em tempo de compilação que você deve remover as implementações não utilizados. Observe que, se a nova versão da interface tem novos ou métodos mudaram você vai, obviamente, obter um erro de compilação de qualquer maneira que você não está implementando o novo material.

@Override em implementadores de interface nunca deveria ter sido permitida em 1,6, e com eclipse infelizmente optando por auto-insert as anotações como comportamento padrão, temos um monte de arquivos de origem desordenado. Ao ler 1.6 código, você não pode ver a partir da anotação @Override se um método realmente substitui um método na superclasse ou apenas implementa uma interface.

Usando @Override quando realmente substituir um método em uma superclasse é bom.

O seu melhor para usá-lo para cada método concebido como uma substituição, e Java 6 +, cada método concebido como uma implementação de uma interface.

Em primeiro lugar, ele pega erros de ortografia como "hashcode()" em vez de "hashCode()" em tempo de compilação. Pode ser desconcertante para depurar porque o resultado do seu método não parece corresponder ao seu código quando a causa real é que seu código nunca é invocado.

Além disso, se uma superclasse muda a assinatura do método, as substituições de assinatura mais velha pode ser "órfãos", deixado para trás como confundindo código morto. A anotação @Override o ajudará a identificar esses órfãos, para que possam ser modificados para coincidir com a nova assinatura.

Se você está substituindo (não-abstratas) métodos, muitas vezes, você provavelmente vai querer dar uma olhada no seu design. É muito útil quando o compilador de outra forma não pegar o erro. Por exemplo tentando substituir initValue () in ThreadLocal, o que eu fiz.

Usando @Override ao implementar métodos de interface (1.6+ metragens) parece um pouco overkill para mim. Se você tem um monte de métodos, alguns dos quais override e outros não, que provavelmente ruim projeto novamente (e seu editor, provavelmente, vai mostrar o que é que se você não sabe).

@Override em interfaces realmente são úteis, porque você vai ter advertências se alterar a interface.

Outra coisa que faz é que torna mais evidente quando a leitura do código que está mudando o comportamento da classe pai. Que pode ajudar na depuração.

Além disso, no livro de Joshua Bloch Effective Java (2ª edição), ponto 36 dá mais detalhes sobre os benefícios da anotação.

Não faz absolutamente nenhum sentido para uso @Override ao implementar um método de interface. Não há nenhuma vantagem para usá-lo nesse caso -. O compilador já vai pegar o seu erro, por isso é apenas a desordem desnecessária

Sempre que um método substitui outro método, ou um método implementa uma assinatura em uma interface.

A anotação @Override garante que você fez, de facto substituir alguma coisa. Sem a anotação corre o risco de um erro de ortografia ou a diferença em tipos de parâmetros e número.

Eu usá-lo o tempo todo. É mais informação que eu possa usar para descobrir rapidamente o que está acontecendo quando eu revisitar o código em um ano e eu esqueci o que eu estava pensando pela primeira vez.

A melhor practive é sempre usá-lo (ou ter o preenchimento IDE-los para você)

@Override utilidade é detectar alterações em classes pai que não tenha sido reportados abaixo na hierarquia. Sem ele, você pode mudar a assinatura do método e se esqueça de alterar suas substituições, com @Override, o compilador vai pegar isso para você.

Esse tipo de rede de segurança é sempre bom ter.

Eu usá-lo em todos os lugares. Sobre o tema do esforço para métodos de marcação, eu deixo Eclipse fazê-lo para mim, então, não é nenhum esforço adicional.

Eu sou religiosa sobre refatoração contínua .... por isso, vou usar cada pequena coisa para torná-lo ir mais suave.

Usado apenas em declarações de método.
Indica que o método anotado declaração substitui uma declaração no supertipo.

Se usado de forma consistente, que protege você de uma grande classe de erros nefastos.

Use @Override anotação para evitar esses erros: (Spot the bug no código a seguir:)

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

Fonte: Effective Java

Tenha cuidado quando você usa Override, porque você não pode fazer engenharia reversa no StarUML depois; fazer a uml em primeiro lugar.

Parece que a sabedoria aqui está mudando. Hoje eu instalei IntelliJ IDEA 9 e percebeu que sua " faltando @Override inspeção " métodos abstratos agora não capturas apenas implementadas, mas os métodos de interface implementadas também. Na base de código do meu empregador e nos meus próprios projetos, eu tenho muito tempo tinha o hábito de utilizar apenas @Override para os ex - implementado métodos abstratos. No entanto, repensando o hábito, o mérito de usar as anotações em ambos os casos se torna claro. Apesar de ser mais detalhado, que faz a proteger contra o problema classe base frágil (não tão grave como C ++ - exemplos relacionados) onde a interface de nome método mudanças, orphaning o método que pretende ser a implementação em uma classe derivada.

É claro que este cenário é principalmente hipérbole; a classe derivada não seria compilar, agora falta uma implementação do método de interface renomeado, e hoje seria provável usar um Método Rename refatoração operação para abordar toda a base de código em massa.

Tendo em conta que a inspeção do IDEA não é configurável para ignorar métodos de interface implementadas, hoje eu vou mudar tanto a minha hábito e critérios de revisão do código da minha equipe.

O @Override anotação é usada para ajudar a verificar se o desenvolvedor que substituir o método correto na classe pai ou interface. Quando o nome de métodos é super mudando, o compilador pode notificar esse caso, que é apenas para a consistência manter com o super e subclasse.

BTW, se não anunciar o @Override anotação na subclasse, mas fazemos substituir alguns métodos da super, então a função pode funcionar como aquele com o @Override. Mas este método não pode notificar o desenvolvedor quando o método do Super foi alterado. Porque ele não sabia que o propósito do desenvolvedor - método de substituição de super ou definir um novo método?

Assim, quando queremos substituir esse método para fazer uso do polimorfismo, temos melhor adicionar @Override acima do método.

Eu usá-lo tanto quanto possível para identificar quando um método está sendo anulado. Se você olhar para a linguagem de programação Scala, eles também têm uma palavra-chave override. Acho que é útil.

Ele não permite que você (bem, o compilador) para captura quando você usou a grafia errada no nome de um método que você está substituindo.

anotação Override é usado para aproveitar o compilador, para verificar se você realmente está substituindo um método de classe pai. Ele é usado para notificar se você cometer nenhum erro como erro de erro ortográfico um nome de método, erro de não correspondendo corretamente os parâmetros

Eu acho que é melhor para o código @Override sempre permitido. ajuda para a codificação. no entanto, de notar, por Ecipse Helios, quer SDK 5 ou 6, a anotação @Override para métodos de interface implementadas é permitido. como para o Galileo, 5 ou 6, anotação @Override não é permitido.

Anotações fornecem dados meta sobre o código para o compilador e a anotação @Override é usado em caso de herança quando estamos substituindo qualquer método da classe base. Ele apenas diz ao compilador que você está substituindo método. Pode avoide alguns tipos erros comuns que podemos fazer como não seguir a assinatura adequada do método ou mispelling em nome do método etc Então, é uma boa prática para usar a anotação @ Override.

Para mim, o @Override me garante que eu tenha a assinatura do método correto. Se eu colocar na anotação e o método não está escrito corretamente, então o compilador reclama deixando-me saber que algo está errado.

Simples, quando você quiser substituir um método presente na sua superclasse, anotação uso @Override fazer uma substituição correta. O compilador irá avisá-lo se você não substituí-lo corretamente.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow