Dúvida Sonar - Rule Design for Extension

Bruno,

O Sonar é uma ótima ferramenta!

Pode-se configurar esses “erros” opcionais, como o Design for Extension, para serem ignorados, pois se tratam mais de conveções.

O que o Design for Extension quer dizer é que se sua Classe for herdada por outra alguém pode sobrescrever esse método de maneira a comprometer o funcionamento correto desse método.
Mas tornar essas classes ou métodos abstratos, finais ou vazios demada uma certa análise. Uma classe final, por exemplo, não pode ser sobrescrita. Mas será que você realmente vai querer perder a extensibilidade de sua classe? Tem certeza de que não precisará em momento algum criar uma sub-classe? Sua classe atende todas as suas necessidades?

Sugiro que dê uma olhada em cada um dos “erros” opcionais do sonar e crie um perfil mais adequado à sua realidade, o perfil padrão do sonar tem pouco mais de 100, já o completo chega a 400 “erros”.

Configure apenas o que achar mais interessantes.

Pessoal, instalei o Sonar porém não consigo logar e diz que houve falha na autinticação como se a senha ou o usuário estivesse errado. A minha versão do sonar é a 2.0.1

Grato!

Bruno Lacerda:

Boa tarde!
Pessoal, instalei o Sonar aqui na minha máquina, a parada é show de bola.
Agora dando uma olhada nas regras que ele sinaliza como Erro (Minor) existe a seguinte:
Design for Extensions (Checks that classes are designed for inheritance.)
Aí fui olhar as classes e eram Daos e um bean que não implementava Serirializable.
Um dos erros é: Design For Extension :
Design For Extension : O método ‘setNome’ não foi concebido para extensão - precisa de ser abstracto, final ou vazio.

Pergunta: Toda a classe que não for feita para ser herdada deve ser obrigatoriamente declarada como final ou abstrata (por convenção)?

Não é uma convenção. É resultado de uma analise lógica do problema da herança. Para detalhes leia Efective Java.

Quando vc declara a classe final isso impossibilita herança e portanto impossibilita os problemas. Isso não significa que ao tirar o final exista alguma problema, mas vc perdeu a garantia
Por exemplo, sem final, vc não impede que alguem sobrescreva o método setNome e o modifique de alguma forma. Ai seu sistema quebra e vc não sabe porque.

Essa regra é muito rígida e é feita para classes em API reutilizáveis. Ela não deve ser aplicada cegamente a todo o codigo.
Contudo, se aplicada cegamente o máximo que vai acontecer é vc ter que escrever final em todas as classes, ou em todos os métodos da classe.