Esse artigo é útil por demonstrar como essas práticas se formam e por que elas devem ser evitadas, estimulando mudanças em alguns hábitos recorrentes de programadores e analistas.
Embora seja uma prática bastante aceita na comunidade de desenvolvedores, o uso de padrões de projeto na engenharia de software não é isento de críticas.
Muito pelo contrário, há uma forte corrente de desenvolvedores que defende a ideia de que o uso de determinados padrões arquiteturais é, na verdade, um fator limitante para o programador.
Algo curioso nessa corrente de pensamento é o fato dela ter ganhado força quase que imediatamente após a publicação do famoso livro da “Gang-of-Four” (GoF) de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, intitulado “Design Patterns: Elements of Reusable Object-Oriented Software”, em 1994.
O que aconteceu foi que em 1995 Andrew Koenig, ex-programador e pesquisador em técnicas de programação, cunhou o termo “anti-padrões”, como uma resposta quase que imediata à publicação do famoso catálogo de padrões que prometia descrever soluções arquiteturais confiáveis para problemas comuns de programação.
Para Koenig, muitos (senão todos) os padrões catalogados, quando não aplicados de maneira consciente, poderiam não só se tornar inefetivos, mas também representar grandes riscos aos projetos de software. E Koenig não para por aí.
Em 1998 ele publicou o livro “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis” e estendeu o uso desse conceito para além da engenharia de software, em áreas como a sociologia, a administração e a gestão de projetos.
Nesse livro, Koenig define anti-padrões de software como sendo uma “prática comum em arquitetura de software, porém inefetiva e contra-produtiva para um problema recorrente, causando de forma geral mais problemas do que benefícios”.
Vale ressaltar que, embora Koenig tenha listado e nomeado um conjunto de más práticas em seu livro, não há especificamente um catálogo de anti-padrões. Sua existência está normalmente relacionada a exageros dos desenvolvedores ao projetar uma solução, ao escrever código ou ao aplicar um reconhecido padrão.
Ainda assim, há tentativas de catalogar anti-padrões, algumas dando a essas más práticas nomes bastante pitorescos, como “fluxo de lava” ou “marcha da morte”.
Além disso, em alguns casos o simples uso de técnicas obsoletas da engenharia de software, como o modelo em cascata, é considerado anti-padrão.
Para outros, o uso de qualquer padrão catalogado, por si só, é um anti-padrão. Apesar disso, no que diz respeito a anti-padrões de engenharia de software, as seguintes categorias são comumente aceitas:
- Anti-padrões de projeto de software;
- Anti-padrões de análise orientada a objetos;
- Anti-padrões de programação;
- Anti-padrões metodológicos.
Há ainda, embora não tão discutida, uma categoria para anti-padrões de gerência da configuração, onde podemos encontrar problemas relacionados à gestão de versões ou de empacotamento.
O tema da existência de anti-padrões tem sido bastante explorado, seja pela comunidade de desenvolvedores em geral ou especificamente pela comunidade de desenvolvedores Java.
Uma publicação que pode ser considerada seminal sobre anti-padrões de arquitetura de software é o livro de 1998 “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”, de William Brown, Raphael Malveau, Skip McCormick, Tom Mowbray, sugestivamente autointitulados de “Upstart Gang-of-Four” e considerados “evangelistas” dos anti-padrões.
É um livro importante por ressaltar, além dos anti-padrões em si, as forças ou tentações que levam à recorrência em sua aplicação.
Especificamente para a comunidade Java, em 2003, o livro “J2EE Design patterns”, de William Crawford e Jonathan Kaplan, dedica um capítulo ao tema anti-padrões, listando alguns dos considerados mais presentes nas aplicações Java EE até aquele momento.
Em seu livro, Crawford e Kaplan destacam o quão importante é estudar não apenas as boas práticas de arquitetura de software, mas também o que deu errado na aplicação dessas práticas.
Esses autores se concentraram em anti-padrões que prejudicam a escalabilidade, que afetam a camada de apresentação das aplicações Java, mas, principalmente, no mau uso da especificação Enterprise JavaBeans (EJBs – ver BOX 1), que se popularizava à época.
EJB é um modelo presente na especificação Java Enterprise Edition (Java EE) desde 1997 para a construção de componentes server-side que encapsulem lógica de negócio, sendo responsáveis por operações como persistência, integridade transacional, segurança etc., especialmente entre aplicações distribuídas.
Também é um livro importante por discutir, na mesma publicação, padrões GoF e anti-padrões, estimulando a reflexão do desenvolvedor. Complementando essa discussão, no mesmo ano foi lançado o livro “J2EE AntiPatterns”, de Bill Dudney, Stephen Asbury, Joseph K. Krozak e Kevin Wittkopf.
Nesse livro, os autores, estabelecem, de certa forma, um catálogo de anti-padrões J2EE, que embora não formalmente categorizados, apresentam alguma classificação, como anti-padrões de escalabilidade, de persistência, e, novamente, de EJBs.
É preciso, no entanto, deixar claro que há uma distinção entre um anti-padrão e um simples mau hábito de programação, uma vez que toda solução envolve riscos, que são maiores ou menores dependendo da forma como ela é implementada.
Por exemplo, a iniciativa de muitos programadores, especialmente iniciantes, em resolver todos os problemas aplicando padrões catalogados resulta diversas vezes em anti-padrões.
Nesse artigo vamos demonstrar anti-padrões que aparecem de forma bastante recorrente.
Para cobrir os casos mais comuns ...
