Muito diferente do que a pergunta do t\u00edtulo possa sugerir, o tema que abordo trata de Engenharia de Software. Muito se l\u00ea em livros que tratam de refatora\u00e7\u00e3o (como o do Fowler et al) e de boas pr\u00e1ticas de c\u00f3digo (como o do Robert Martin) sobre como identificar c\u00f3digos OO mal redigidos. Fala-se sobre v\u00e1rios princ\u00edpios, como o Aberto\/Fechado, o de substitui\u00e7\u00e3o de Liskov, o de Responsabilidade \u00danica, etc; o livro do Fowler d\u00e1 at\u00e9 dicas sobre como identificar tais problemas no c\u00f3digo OO: os maus cheiros de c\u00f3digo.<\/p>\n
N\u00e3o obstante, tais percep\u00e7\u00f5es n\u00e3o s\u00e3o t\u00e3o \u00f3bvias para o desenvolvedor ne\u00f3fito. Descobrir que uma classe viola o princ\u00edpio de substitui\u00e7\u00e3o de Liskov, por exemplo, n\u00e3o \u00e9 uma tarefa f\u00e1cil; exige muito conhecimento e reflex\u00e3o sobre o c\u00f3digo.<\/p>\n
Andrew Binstock, editor da Dr.Dobbs, cita uma excelente dica em seu artigo publicado na edi\u00e7\u00e3o desse m\u00eas (In Praise of Small Classes). Ele fala de uma par\u00e2metro bastante tang\u00edvel para identificarmos um c\u00f3digo mal projetado: o tamanho de uma classe. Segundo Binstock, tal par\u00e2metro \u00e9 colocado por Jeff Bay no livro “The ThoughtWorks anthology”, e estabelece o valor de at\u00e9 60 linhas de c\u00f3digo. Acima disso ter\u00edamos um ind\u00edcio de que a classe precisa perder responsabilidades atrav\u00e9s de refatora\u00e7\u00e3o.<\/p>\n
O pequeno artigo transcorre sobre os conhecidos efeitos colaterais de c\u00f3digo OO mal projetado sobre os testes. Vale a pena a leitura!<\/p>\n