Padrões de projeto: o que são e o que resolvem

Padrões de projeto: o que são e o que resolvem – Design Patterns (comumente relacionados na literatura de TI como “Padrões de Projeto”) são soluções para problemas comuns que encontramos no desenvolvimento ou manutenção de um software orientado a objetos (não são tão bem aplicáveis em outros paradigmas). Olhando assim parece ser algo realmente bem “requintado”, não é?

Vamos tentar entender sob outra perspectiva: imagine você no futuro, daqui 15 anos, certamente terá passado por N problemas, repetidamente e em diferentes projetos. A tendência natural é que você crie soluções comuns (mas elegantes, assim esperamos, né? :P) para resolvê-los de tal forma que você consiga aplicá-las no futuro em outros projetos. Essas soluções, criadas por você, mesmo que não compartilhadas à literatura (livros ou artigos acadêmicos), podem ser consideradas como sendo Design Patterns, sim, padrões de projeto criados por você para resolver os seus problemas. Nada mais justo, não?

Sorte do dia: Não precisamos esperar uma dezena ou mais de anos para acumularmos experiência (e, consequentemente, perda de cabelo) para que tenhamos desenvolvido eficientes soluções para os nossos softwares.

Isaac Newton certa vez dissera:

Se cheguei até aqui foi porque me apoiei no ombro de gigantes.

Lhe convido a absorver essa ideia que nos foi “presenteada” séculos atrás por esse brilhante cientista (alguns diriam que ele foi um “full stack” por ter sido físico, matemático, astrônomo, filósofo, teólogo, alquimista e coisas mais. :P).

Engenheiros de softwares por décadas desenvolveram padrões de projeto para resolver problemas comuns. Por que não dar uma chance de conhecê-los e, quem sabe, utilizá-los?

Parafraseando o filósofo e professor da USP, Clóvis de Barros Filho, em uma palestra muito especial:

Os caras escreveram as soluções, véio. Eles tiveram que tirar o negócio do zero! Só precisamos entender e aplicar a bagaça!

Como tudo começou

Toda a inspiração por trás do nosso conceito de “padrões de projeto” veio, na realidade, da arquitetura (sim, àquela área de conhecimento que projeta e arquiteta ambientes), de um livro chamado “A Patter Language”, escrito por Christopher Alexander, Sara Ishikawa e Murray Silverstein, foi o que primeiramente lançou a ideia de “linguagem de padrões”. O livro teve como propósito apresentar centenas de padrões sobre como cidades, bairros, casas e ambientes no geral poderiam ser projetados.

O primeiro grande trabalho da área de desenvolvimento de software que absorveu tal ideia coletando e desenvolvendo dezenas de padrões para softwares se deu em 1994 em um livro chamado “Design Patterns: Elements of Reusable Object-Oriented Software”, escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Originalmente o livro discutiu 23 padrões de projetos. Os autores e o livro causaram tanto impacto que começaram a ser chamados e reconhecidos por Gang of Four (GoF) (gangue dos quatro) e tais padrões começaram a ser intitulados de GoF Patterns (Padrões GoF).

Olhando assim parece até que em uma noite chuvosa a “gangue dos quatro” reunida na garagem de um deles se acometeu de uma sobrenatural inspiração e então gritaram ==“Eureka! Eureka!”== e logo já escreveram os 23 padrões, não é? É, só parece. Os padrões, na realidade, são soluções de problemas retirados de ==códigos reais==.

Categorias dos padrões GoF

Os padrões GoF foram divididos e categorizados de acordo com a natureza do problema que eles resolvem (ou ao menos tentam, uma vez que software, como bem você sabe, é algo com “vida própria” haha):

Padrões de Criação: Tem como objetivo abstrair a instanciação de objetos. Com eles, o sistema vai solicitar um objeto de um determinado tipo e o terá prontinho, sob demanda, sem nem se preocupar com as nuances da criação. Fazendo um paralelo com o mundo real, uma empresa automobilística quando precisa de amortecedores, ela terceiriza (solicita-os) e então os instala em seus carros, sem se preocupar com o todo envolvido na criação desse componente.

Padrões estruturais: Os padrões dessa categoria se preocupam em melhor organizar a estrutura das classes e os relacionamentos entre classes e objetos.

Padrões comportamentais: Os padrões dessa categoria atuam diretamente na delegação de responsabilidades, definindo como os objetos devem se comportar e se comunicar.

Padrões GoF

Abaixo a relação dos padrões GoF.

Concluindo

Os padrões GoF foram descritos há décadas e, software é quase como um organismo vivo, ele passa por transformações para se adaptar às novas realidades do “ambiente”.

Nem todos os padrões GoF são bem aceitos nas comunidades de desenvolvimento, por exemplo, você já deve ter ouvido de algum colega desenvolvedor que você deveria passar longe de usar um Singleton por ser um “anti pattern”. Não tenho como propósito aqui fazer julgamento de valor mas, nem tudo é “preto no branco”. Conheço grandes softwares open sources (Frameworks de linguagens bem estabelecidas) que usam Singleton em alguma parte de seus códigos e nem por isso deixaram de ser bons.

Abusar no uso de padrões de projeto pode nos levar a caminhos tortuosos. Na realidade, supervalorizar qualquer coisa nessa nossa complexa vida pode ser perigoso, pois tendemos a criar determinamos “vícios” nas resoluções dos nossos problemas. O bom senso é sempre fundamental. E no final, como sempre, nunca teremos todas as respostas. Nossos softwares nunca serão “perfeitos e impecáveis” e nunca estaremos em plenitude satisfeitos com o código que escrevemos. O desenvolvimento intelectual tem que ser constante e a paranóia precisa ser moderada. Então, vai uma cerveja (ou coca) aí? 😛

Em futuros artigos veremos a aplicação de alguns desses padrões.