Continuando com a Série Coisas que todo Sênior deve saber, vamos falar sobre Design Patterns e como eles podem ajudar no seu desenvolvimento.

Porque Design Patterns?

Quando você pega um problema e abre sua IDE favorita, você logo começa a pensar em como resolver esse problema. Certo?

E se seu problema já tiver sido solucionado por uma infinidade de pessoas? Você não estaria perdendo tempo em pensar como resolvê-lo?

São aí que surgem os Design Patterns. Na verdade esse nome vem do livro escrito por 4 engenheiros de software, <ironia> em uma época um tanto remota 1994</ironia>, Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos

Pra ser sincero eu não li o livro, mas ainda pretendo ler ele.

Tipos de Problemas

Antes de partir para descrever os Padrões de Projetos, precisamos entender os tipos de problemas que eles tentam resolver.

Essas classificações são minhas!!!

Algoritmos são receitas de bolo para software. Todo software é composto por algoritmo. Mas vou classificar algoritmos como os passos para solução de problemas complexos. Não vou falar deles aqui.

Padrões de Projetos são receitas simples para problemas de projeto. Você vai usa-los em projeto um pouco maiores, mas são problemas como: Criação de Objetos, Interpretar Comandos, Aplicar operações em Elementos.

Vamos valor sobre Padrões de Projetos!

Como os conheci?

Muito tempo atrás, estava trabalhando no desenvolvimento de ferramentas de desenvolvimento, e desenvolvíamos um produto baseado no Eclipse para uma multinacional que na época era a número 1 na venda de telefones celulares (o smartphone ia nascer em poucos meses).

Fizemos um prototipo e sucesso! Ganhamos o projeto. E de 3 pessoas o projeto foi pra 60!!!!! 😱😱😱😱

Então nosso código começou a desandar! Tínhamos por volta de 4 equipes com 10 pessoas cada (falta 20, né?), imagina 10 pessoas colocando a mão no código! Então fizemos um Working Group para melhorar a qualidade do nosso código, desse Grupo de Trabalho saiu a ideia de investigarmos os Padrões de Projetos e cada semana alguém escolher 1, apresentar e propor uma alteração que poderíamos fazer no produto com ele.

Tipos de Padrões de Projetos

No livro Padrões de Projeto, são propostos 3 tipos de padrões.

1. Padrões de criação: são padrões que guiam a criação de objetos. Deve responder perguntas básicas do seu software como "como criar objetos?", "quem implementa meus objetos?". Conhecer eles ajuda bastante em soluções inteligente, assim você consegue um baixo acoplamento em seu software já criado.
2. Padrões estruturais: são padrões que guiam como objetos podem ser implementados.
3. Padrões comportamentais: são padrões que auxiliam na implementações de soluções dentro do seu programa.

Muitas vezes você pode estar quebrando cabeça com algum problema e nem imagina que existem uma solução como a que está aí sendo desenvolvida.

Meu primeiro Padrão Implementado

Quando chegou minha vez de apresentar, eu tinha acabado de desenvolver uma feature para deploy da aplicação no celular. O ano era 2006, uma aplicação era bem diferente do que você conhece hoje! 🤔

Eu tinha implementado o protocolo OBEX para transferir o pacote para o celular. E não estava feliz. Havia alguns erros nele, e tinha um que ocorria muito esporadicamente e era difícil de pegar. O código era macarrônico, como era comum naquela época. então resolvi estudar o Command.

Command Pattern

Se você for pesquisar as referências sobre esse padrão verá que ele se aplica muito para comandos de interface gráfica. Mas aí que está a beleza dos Design Patterns, você pode adaptar uma solução para vários problemas diferentes.

O Command nos obriga a separar o que é código de execução de um comando de outros códigos como interface, controle de sessão, etc... Assim ao aplicar a minha implementação do OBEX, eu deveria antes de tudo me perguntar: quais comandos o protocolo tinha?

Dada essa resposta, eu criei uma classe abstrata Command, uma classe Session e voilà. Estava quase tudo pronto!!!!! 😲

Só faltava implementar os comandos e cada um só precisava saber das suas responsabilidades. A partir daí, comecei a refatorar o código a fim de separar cada operação.

Sabe aquele bug esporádico que acontecia? Pois é, era um lixo que ficava na sessão de sessões anteriores que não dava pra ver com um código macarrônico. Mas quando eu refatorei, ao abrir uma classe eu via apenas a lógica dela, nada mais. Sabia como ela interagia com as outras.

Resultado

Com a aplicação do Command muito do meu código foi literalmente apagado. Havia muita duplicação.

A lógica ficou evidente, facilitando a manutenção do mesmo. Tanto que nunca mais tivemos bugs ali. Ele durou até o SmartPhone decretar o fim do Feature Phone.

Outros Padrões

Ok. O mundo mudou desde 2006. Mas existem outros padrões que devemos seguir?

Sim!

Caso você trabalhe com microserviços? Obrigatoriamente você tem que conhecer os padrões de microserviços. Vá em microservices.io e leia.

Caso você trabalhe com Java? Existem alguns padrões do extinto Java EE, agora Jakarta EE. Eu falo de um deles aqui:

Conclusão

Todo Sênior deve conhecer ao menos 1 Design Pattern de cabeça, isso quer dizer, sabe implementar ele sem consultar nada. Deve ter ao menos 2 favoritos.

Design Patterns nos ajudam a classificar e resolver problemas simples que não são importantes no negócio da nossa aplicação, mas se não funcionar impacta o negócio.

Design Patterns ajudar seu código a ficar elegante. Isso impressiona! 🧔

Design Patterns é o pão de cada dia do desenvolvedor. Ele deve ser básico, usado diariamente.

Indicações de Leitura

Estão em ordem de prioridade! 😉

• Como ser um Programador Melhor: um Manual Para Programadores que se Importam com Código
• Código Limpo: Habilidades Práticas do Agile Software
• Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos