Rodrigo Kumpera Weblog

Esse artigo é acima de tudo uma reclamação, um desabafo. Outro dia peguei uma pérola para dar manutenção que possuia tantas camadas de abstração que acompanhar o fluxo do código simplesmente lendo ele era muito dificil. O problema era bem simples, muita abstração inutil, hierarquias de classe com quatro níveis e uma classe em cada um! Não entendo por que tem gente que adora isso, criar toneladas de código que simplemente obfusca o real objetivo dele. Enfim, corrigir isso é razoavelmente simples, tanto que abaixo vai a receitinha.
Mas vamos lá, esse anti-pattern é bem facil de identificar e corrigir. Primeiro, identificar, quando existem hierarquias muito longas com uma classe em cada nível. Pode-se argumentar que essa estrutura foi adotada pensando em usos futuros, bom, nesse caso o correto e somente no futuro introduzir essas classes; outro argumento é por conta do tamanho da classe, que foi feito isso para evitar criar bloat, só que no final das contas, o resultado é o mesmo e existem formas melhores de decompor uma classe que via herança.

Agora que já sabemos quando nos deparamos com esse problema, resolver é questão de ter boas ferramentas e vontade. Caso o código esteja escrito em uma linguagem com tipagem latente (feito Ruby), basta agrupar o código de todos os tipos da hierarquia e caso alguma das classes base não seja abstrata, troque os clientes delas para instanciar o tipo final. Caso contrario, se código for escrito em uma linguagem com tipagem estática (feito Java), basta usar uma ferramenta de refatoração para remover todas referencias aos tipos a serem apagados.

Uma vez removida essa hierarquia de classes supérflua, provavelmente vai sobrar uma classe bem inchada pedindo para ser decomposta, daí só usar as ferramentas básicas que o Fowler recomenda. Faltou dizer a motivação para esse anti-pattern, uma é a criar a falta ilusão de um tipo menos inchado, outra é tentar introduzir as abstrações que futuramente o sistema sistema precisará, ou seja, fazer papel de adivinho.