Padrões de projeto

Não há como negar a influência deste termo na vida de quem trabalha com desenvolvimento de software. Seja por bem ou por mal, os padrões de projeto estão presentes há mais de uma década, talvez desde que começaram a possibilitar melhorias no desenvolvimento de software, ou então quando começaram a serem vistos com bons olhos pelo mercado de trabalho.

Todavia, também começaram a causar deterioração de código e discórdias, seja por mau uso, falta de entendimento a respeito ou falta de planejamento. Desta forma, passaram a ser criticados ao mesmo tempo em que elogiados.

Tipicamente, padrões de projeto são certamente benéficos, desde que implementados de maneira adequada e tendo em mente certos princípios – alguns dos quais serão apresentados aqui.

A intenção deste artigo é esclarecer aos que lidam com padrões de projeto, tanto os que forem a favor quanto os que forem contra, que padrões de projeto não são balas de prata. Eles podem ser soluções para determinados problemas e problemas para determinadas soluções. Por isso, é importante analisar cada situação com senso crítico.

Portanto, serão apresentados conceitos, princípios e exemplos que lhe permitirão identificar situações parecidas em seu dia-a-dia, além de considerações gerais para aplicar seu senso crítico visando alcançar uma solução adequada.

Em busca do código perfeito

Ser um experiente desenvolvedor de software não é um patamar que se alcança de um dia para o outro. São necessários anos e anos de criteriosos estudos e vivência profissional para se tornar digno de tal denominação.

Para reduzir este hiato, muitos desenvolvedores procuram aprimorar-se nos atributos geralmente louvados que todo habilidoso desenvolvedor de softwares deva possuir. O que é de fato uma boa iniciativa, desde que se dê minuciosa atenção a cada habilidade aprimorada.

O problema acontece quando o desenvolvedor quer chegar neste nível muito rápido, e acaba pecando no nível de critério, afirmando saber algo que apenas tem uma noção, e na hora da prática acaba faltando o devido embasamento teórico.

É exatamente o caso dos padrões de projeto. É muito fácil alguém “achar que sabe bem” padrões de projeto simplesmente por ter visto algumas implementações, ou por ter lido em alguma revista. É claro que temos exceções, mas geralmente é necessário um pouco mais de vivência para a real compreensão. E justamente pela tal falta de vivência, criam-se situações onde padrões de projeto não são devidamente utilizados.

Para exemplificar, confira algumas causas comuns da má utilização de padrões de projeto:

Desatenção à definição de padrão

O propósito real dos padrões de projeto é muitas vezes deixado de lado. Segundo Craig Larman, em seu livro Applying UML and Patterns (2005), um padrão é um par nomeado de problema/solução que pode ser aplicado em um determinado contexto, possuindo orientação em como ser aplicado e discussão de suas consequências.

Desta forma, ao utilizar qualquer padrão, todo desenvolvedor deve atentar a duas premissas:

1. Apenas implementar o padrão se sua aplicabilidade estiver de acordo com o cenário;

2. Apenas implementar o padrão se suas consequências forem aceitáveis no cenário.

Quem implementa padrões tem toda a responsabilidade pelo que está introduzindo, então o mínimo que se espera é que se busque justificar a introdução do padrão a partir das premissas acima.

Vejamos um exemplo favorável à introdução de um padrão de projeto: em um sistema de e-commerce, é requisitado que o usuário possa escolher dentre diversos critérios para ordenar os resultados. Assim, um desenvolvedor considera o uso do padrão de projeto GoF Strategy (Estratégia).

Ao consultar a aplicabilidade de Strategy, ele percebe que sua ideia está de acordo com a proposta do padrão, visto que temos diversas variações de um algoritmo, não é desejável expor os detalhes de cada algoritmo e a escolha do critério seria tipicamente codificada com condicionais múltiplos.

Agora, ao consultar as consequências de Strategy, ele verifica que criará uma família de algoritmos relacionados, eliminará condicionais múltiplos e poderá escolher um critério diferente a qualquer momento. Por outro lado, haverá um maior número de objetos em memória, o código cliente precisará estar pronto para receber diversos " [...] continue lendo...