O terceiro "code smell" detecta-se quando passamos classes crescidinhas, com muitas variáveis de instância (como se traduz field? campo? variável de instância?) ou com diversos métodos com muitas linhas. Quando encontramos estas classes, o código duplicado e a falta de legibilidade costumam ser fartas, tornando o código mais difícil de manter, mais sujeito a erros, bla bla bla.... Adicionalmente, como opinei no post anterior, cada classe deve ter uma e uma só responsabilidade. Regra geral, classes grandes têm muitas responsabilidades diferentes, perdendo coesão interna. Classes grandes aproximam-se muito do paradigma procedimental e são mais comuns no código construído por quem tem esse background.

Existem diversos refactorings que se podem aplicar para pôr o código em forma. Se temos muitas variáveis de instância, provavelmente podemos extrair a classe, com um Extract Class - será que faz sentido traduzir os nomes dos refactorings? - ou eventualmente, um Extract SubClass. Normalmente os dados funcionam em grupo e é simples apercebermo-nos de quais variáveis devem migrar. Procurar por prefixos ou sufixos comuns nos nomes das variáveis, como "NomePessoa" e "IdadePessoa", costuma ser boa política. Se temos muito código, muito provavelmente, também podemos aplicar um Extract Class ou um Extract SubClass. Por vezes um Extract Interface pode ajudar a identificar os métodos com responsabilidades comuns. Cada interface pode eventualmente dar origem a uma classe.

Os Code Smells, como devem ter começado a aperceber, podem-se combinar uns com os outros. Quando temos métodos longos e decidimos "limpar o ambiente", podemos ficar com uma série de métodos novos que partilham a mesma responsabilidade e, consequentemente, podem migrar para uma nova classe.

Este post, à semelhança de todos os Code Smells, baseia-se no livro "Refactoring - Improving the Design of Existing Code". Mas ainda não o leram?