Se você nobre leitor, tem uma mínima vivência na área de desenvolvimento/arquitetura de software com certeza já deve ter ouvido falar ou lido a respeito dos famosos design patterns ou simplesmente padrões de projeto no bom português, muito se fala sobre os famosos padrões do GOF , princípios S.O.L.I.D e afins, mas, você realmente domina os padrões de projeto?

Eu acredito que a melhor forma de entender os padrões de projeto é entender os padrões “não-técnicos” que você usa no seu dia a dia, vamos usar como exemplo um currículo.

Currículos não são iguais, porém, todos os currículos tem geralmente o mesmo objetivo, informar ao contratante/leitor das suas habilidades e por quê o dono daquele currículo deve ser contratado para a oportunidade em questão, a maioria das pessoas que enviam currículos para vagas de emprego, sabe que eles devem fazer um resumo dos empregos/experiências anteriores, formatar propriamente o documento e utilizar uma linguagem adequada.

Este é um padrão, alguns podem chamar de modelo, mas um modelo não é um padrão? Existem várias outras coisas na vida que seguem um padrão,  outro exemplo conhecido é a construção de um carro, apesar de existirem vários modelos e preços, geralmente os fabricantes seguem um padrão básico: 4 rodas, volante, acelerador, freio, etc…

Todas as coisas construídas repetidamente, irão, inevitavelmente, seguir um padrão em seu design … seja carros, pizza, caixas eletrônicos, o que quer que seja…

Utilizar padrões de projeto gera vários benefícios, mais os 2 benefícios abaixo são os que mais chamam minha atenção

– Definir uma metodologia comum de desenvolvimento (geralmente visando facilitar a vida de quem desenvolve ou dá manutenção no sistema);

– Acelerar o processo de desenvolvimento (com padrões definidos podem ser criadas ferramentas de produtividade para automatizar algumas partes do desenvolvimento)

Vamos voltar  no exemplo dos currículos que foi falado anteriormente, vamos supor que um ou outro candidato ao invés de seguir o padrão definido, por pressa ou algum outro motivo, resolva enviar o currículo no corpo do email, sem nenhuma formatação… Esses candidatos correm o sério risco de ficar sem ao menor participar do processo seletivo, pois não estão seguinte o padrão altamente difundido, que é enviar um currículo bonitinho, bem formatado e tals, obviamente existem exceções à regra, pode ser que ao invés de enviar um currículo, o candidato envie o link do seu portfólio na internet, algumas empresas podem gostar do trabalho já desenvolvido por ele e podem chamá-lo, mas obviamente isso é só um experimento, é questão de tentativa, o cara pode se dar bem ou não.

Geralmente em um ambiente de desenvolvimento, você não pode se dar ao luxo de “tentar” acertar, uma empresa geralmente trabalha com prazos, e qualquer re-trabalho deve ser evitado ao máximo, o tempo que você gasta com um re-trabalho, você poderia estar utilizando para fazer outra tarefa, que agregue valor (de preferência financeiro) para a empresa, empresas de software em sua maioria não são filantrópicas, ou seja, tempo perdido é dinheiro perdido.

Muitos padrões de projeto tem variações, algumas variações chegam a ser mais famosas do que o padrão origem, e acabam se tornando um novo padrão de projeto, geralmente são padrões já testados e consolidados no mercado, conhecendo um padrão de projeto você se comunica mais facilmente com os outros desenvolvedores e outras partes do projeto.

Padrões de projeto não são um framework, ou uma tecnologia que alguma empresa criou, são conceitos abertos, que visam resolver um ou mais problemas, são melhores práticas descobertas por desenvolvedores experientes, que passaram por problemas que você possivelmente já passou ou vai passar, a verdade é que não existe motivo para re-inventar a roda, se o método de criar a roda é público, você pode usar um padrão para criar um sistema de imobiliária e em seguida pode usar o mesmo padrão para desenvolver um sistema de gestão de empresas, a maioria dos padrões de projeto são genéricos, significando que você pode usá-los em qualquer tipo de projeto e com a maioria das linguagens de programação da atualidade.

Agora a pergunta que não quer calar, como aprender os tais padrões de projeto? obviamente a melhor forma de aprender é pesquisando na internet, lendo livros, estudando softwares prontos de código aberto que seguem padrões, não basta só ler os livros ou os artigos, ler é relativo, qualquer um que saiba ler vai ler, você tem que abrir sua mente e tentar aprender o conceito, uma vez entendido o conceito, tente transcrever o conceito para código, profissionais que dominam as boas práticas de desenvolvimento de software, geralmente ganham renome no mercado e pelas empresas que passam.

Este post não teve a intenção de falar sobre cada padrão de projeto definido pelo GOF e os demais que existem por aí, isso você acha em qualquer lugar da internet, a minha intenção foi claramente dissertar sobre a utilidade dos padrões de projeto para o desenvolvedor/analista/arquiteto de sofrware nos dias atuais… como forma de colaboração eu gostaria de sugerir 2 livros que na minha humilde opinião são duas excelentes leituras, primeiramente ele, que já é um clássico sobre o tema, Patterns of Enterprise Application Architeture do Martin Fowler, um livro que apesar de antigo para muitos é o livro de referência sobre projetos (junto com o do GOF talvez), ele pode ser encontrado em português nas livrarias brasileiras (apesar de eu preferir a versão em inglês por que certas vezes a tradução ao pé da letra de termos técnicos é um pé no saco), outro livro que eu recomendo é Professional ASP.NET Design Patterns, para você que é burro igual uma porta só consegue entender com exemplos práticos, esse livro é um prato cheio, tem vários exemplos, além de ter explicações bem detalhadas.

VN:F [1.9.22_1171]
Rating: 9.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
Padrões de projeto de software não são coisa do capiroto, 9.0 out of 10 based on 1 rating