Padrões de Projeto
Em desenvolvimento de sistemas uma das modas, num aspecto mais técnico, é o uso maciço de Padrões de Projeto (Design Patterns). Chega a ser excessivo, em minha opinião e por isso, seu uso, ao invés de ajudar no projeto, atrapalha e cria verdadeiros monstros (impossíveis de entender, dar manutenção, modificar, compreensão do que está sendo feito difícil, etc). Projetos sem padrões é algo um tanto desordenado, mas projetos com uso exagerado ou de forma “incorreta” torna um sistema um elefante branco.
Por volta de 1995, o GoF (Gang of Four – Erica Gamma, Richard Helm, Ralph johnson, John Vlissides), publicou um livro intitulado : “Design Patterns – Elements of Reusable Object-Oriented Software”. Devido a ele, a questão dos padrões de projeto ganhou popularidade e partir de então passou a ser quase que uma obrigação a quem se aventurasse a desenvolver conhecer alguma (as vezes todas) das soluções proposta no trabalho do GoF. Fiz várias entrevistas nas quais me perguntaram se conhecia Patterns; pediram para explicar e desenhar algum em particular; e por ai foram.
Padrões não são ruins. Como vários sites e artigos dizem: esses padrões foram soluções de sucesso e testadas ( ou seja, comprovadamente ela funciona e tem um bom desempenho dentro do cenário que ela se propõe) que alguém fez e resolveu catalogar para que no futuro, alguém ao se deparar com um problema de mesma natureza saiba pelo menos um ponto de partida. De forma bastante simplista, esse catálogo é uma fonte de consulta e onde podemos nos basear, entretanto, não devemos encará-lo como sendo uma verdade absoluta e que não usar o padrão proposto, sem quaisquer alterações, é um heresia. Todo o radicalismo independente do lado que penda é ruim. O radicalismo de alguns em dizer que patterns são besteiras e os dos que dizem somente eles devem ser usados não , na minha forma de ver as coisas, o melhor caminho para seguir se desejarmos fazer códigos de qualidade.
Eric Freeman e Elisabeth Freeman em seu livro “Head First Design Patterns ” (Em português o título do livro é : Use a Cabeça Padrões de Projeto), são um ar fresco e trazem uma nova luz sobre o assunto. Num edição impecável e bem escrita, eles resgatam a questão do uso de padrões do radicalismo e tentam e forma simples mostrar porque devemos pelo menos conhecê-los. O livro vai direto ao ponto e muitas de suas ideias estão de acordo como vejo o tema.
Um primeiro ponto é que para mim não existe verdade absoluta : um padrão não é e nunca será a única solução para um determinado problema. A diferença está, como já disse antes, que o catalogado é de domínio público (facilita a quem terá que entender o sistema depois), testado e já obteve sucesso em sua aplicação. De novo, insisto, não é a única opção e pode até, dependendo do caso, não ser a melhor. Existem diversos fatores a considerar na escolha de um padrão para usar: escopo, custo, tempo, recursos, etc. Como exemplo gosto de citar um caso onde uma pessoa deveria fazer uma aplicação web. Ela teria apenas 4 telas : uma de login, uma para fazer importar uma planilha excel, uma para visualização de dados, etc… O desenvolvedor acabou, por pura preciosismo usando patterns em quantidades generosas… resultado: tudo ficou um lixo e colocaram a culpa do cara que sugeriu que usassem uma tecnologia de ponta (Struts e Hibernate)
Segundo ponto: aprender padrões é aprender a se comunicar. Ao aprender os padrões você está adquirindo uma linguagem, de certa forma. Assim, quando quiser explicar a um desenvolvedor do time que poderia fazer de um jeito, sendo ele um pattern, basta que diga : “Fulano vamos usar o pattern XuxaSbrbublesIce++”.Sei que isso pode parecer radical (justo o que critiquei antes) porém se observarmos de um outro angulo a coisa realmente faz sentido
Terceiro : Em alguma parte antes disse que padrões devem ser usados como ponto de partida. O problema está que a maioria das pessoas usa como objetivo. Acredito que muitos serão os casos em que terei que usar uma implementação da forma que o livro ensina, entretanto, haverão tantos outros que terei que adaptar, misturar, usar parte, etc.
Bom agora vai minha opinião:
Conhecer design pattern é bom mesmo que seja para falar mal enquanto toma cerveja com os amigos num #horaextra. Fora isso, ao conhecê-lo você começa a abrir sua cabeça para novas possibilidades e formas de resolver problemas.