Se você já possui algum tempo de experiência como desenvolvedor, deve ter percebido que alguns problemas (requisitos) são muito recorrentes durante o nosso trabalho.
Para citar apenas alguns exemplos, esses problemas vão de garantir que exista apenas uma instância de um determinado recurso no sistema (Singleton Design Pattern), passando pela execução de comandos/ações (Command Design Pattern) e o encapsulamento de um objeto complexo a fim de simplificar o seu uso (ou, então, de um componente que será substituido no futuro) (Proxy Design Pattern). Esses são problemas com os quais nos deparamos quando estamos codificando. Existem alguns problemas que devem ser resolvidos antes mesmo de partimos para o código, por exemplo, como a aplicação será estruturada (Architectural Patterns, ou padrões de Arquitetura, ajudam a resolver esses problemas).
Assim, ao ter que implementar os mesmos requitisos/resolver os mesmos problemas várias e várias vezes, é comum que você caia na repetição (repeat yourself). É exatamente essa repetição que deu origem aos Padrões (Patterns). Entretanto, os Patterns possuem algo de especial, eles não são simplesmente uma maneira repetitiva de resolver um determinado problema, eles são justamente a melhor maneira para se resolver aquele problema. Assim, é coerente dize que para cada um dos problemas recorrentes identificados, existe uma maneira otimal para resolvê-lo e essa menira otimal é o Pattern.
Por outro lado, da mesma forma é possível repetir boas soluções para determinados problemas, também é plausível que sejam repetidos erros ou práticas ruins. Sim, é possível que eu ou você tenhamos cometido o mesmo erro várias e várias vezes.. essa repetição acontece, em geral, até que você descubra que o que você está fazendo ou está errado e introduzirá potenciais bugs no código ou, então, não faz sentido para a linguagem/framework no qual você está trabalhando. Alguns desses erros / práticas sem sentido foram identificadas como sendo praticadas por vários desenvolvedores e, por terem se tornado comuns, receberam o nome de Anti Patterns (Anti Padrões).
É seguro afirmar que a maioria dos Anti Padrões são praticados pelos seguintes motivos:
- Falta de conhecimento da plataforma/linguagem/framework utilizado
- Utilização de técnicas defensivas de programação que são utilizadas e fazem sentido em outras linguagens
Se você estiver confuso, dê-me mais alguns parágrafos até examinarmos alguns exemplos, acredito que tudo fica mais claro com a prática.
Antes de examinarmos com mais detalhes alguns exemplos, vejamos algumas características que permitem identificar um Anti Pattern.
- O código/a prática não resolve o problema
- O código/a prática falha em algum ou vários cases de extremidade (edge-cases)
- O código/a prática contém código que é lento e não performa quando sob alta demanda
- O código/a prática contém código ilegível
- O código/a prática contém código reduntante (que não tem nenhuma ação prática)
(CONTINUA)
Paulo Ricardo Stradioti 