Muito diferente do que a pergunta do título possa sugerir, o tema que abordo trata de Engenharia de Software. Muito se lê em livros que tratam de refatoração (como o do Fowler et al) e de boas práticas de código (como o do Robert Martin) sobre como identificar códigos OO mal redigidos. Fala-se sobre vários princípios, como o Aberto/Fechado, o de substituição de Liskov, o de Responsabilidade Única, etc; o livro do Fowler dá até dicas sobre como identificar tais problemas no código OO: os maus cheiros de código.

Não obstante, tais percepções não são tão óbvias para o desenvolvedor neófito. Descobrir que uma classe viola o princípio de substituição de Liskov, por exemplo, não é uma tarefa fácil; exige muito conhecimento e reflexão sobre o código.

Andrew Binstock, editor da Dr.Dobbs, cita uma excelente dica em seu artigo publicado na edição desse mês (In Praise of Small Classes). Ele fala de uma parâmetro bastante tangível para identificarmos um código mal projetado: o tamanho de uma classe. Segundo Binstock, tal parâmetro é colocado por Jeff Bay no livro “The ThoughtWorks anthology”, e estabelece o valor de até 60 linhas de código. Acima disso teríamos um indício de que a classe precisa perder responsabilidades através de refatoração.

O pequeno artigo transcorre sobre os conhecidos efeitos colaterais de código OO mal projetado sobre os testes. Vale a pena a leitura!

Clique aqui.