Como os padrões de projeto contribuem para a comunicação

Introdução

No desenvolvimento de software, a comunicação eficiente entre membros da equipe e a criação de soluções flexíveis e escaláveis são desafios constantes. Padrões de projeto (https://refactoring.guru/design-patterns) são soluções testadas e comprovadas para problemas recorrentes no design de software, promovendo a reutilização de código e melhorando a comunicação entre desenvolvedores.

Este artigo compara duas abordagens diferentes para resolver um problema de monitoramento de eventos e notificações: uma abordagem sem o uso de padrões de projeto e outra que utiliza um padrão de projeto específico para criar uma solução mais modular e eficiente.

Problema

À medida que a aplicação evolui, cresce a necessidade de monitorar e notificar eventos aos usuários. No entanto, com a adição de novas funcionalidades, surgem problemas como o forte acoplamento entre componentes, dificultando a realização de alterações simples e atrasando entregas.

Nossa aplicação possui um forte acoplamento aos Eventos de Monitoramento e Notificação. Estes são chamados sempre que há necessidade de criar ou assinar uma tarefa, adicionar ou alocar um recurso. Devido ao forte acoplamento, surgem dificuldades ao realizar alterações ou melhorias nesses eventos.

Comparação entre as Abordagens

Time A: Abordagem Sem Padrões de Projeto

Método

O Time A realiza uma reunião detalhada para discutir a solução, onde cada classe e função é especificada individualmente.

Desenho

Padronizamos os parâmetros recebidos ao capturar os eventos de monitoramento e notificação. Em seguida, criamos classes específicas para transformar o tipo de tarefa em tipo de monitoramento e, consequentemente, em tipo de notificação.

Por fim, transferimos as responsabilidades de criação, atribuição, adição e alocação para classes específicas responsáveis pelo envio dos eventos.

O design detalha cada componente do sistema sem utilizar padrões de projeto. O foco é na implementação direta e específica de cada função.

Resultado

A solução é funcional, mas apresenta um alto grau de acoplamento entre os componentes, o que dificulta futuras manutenções e expansões. A reunião é mais longa e a comunicação menos eficiente, já que todos os detalhes precisam ser discutidos extensivamente.

Time B: Abordagem com Padrões de Projeto

Método

O Time B utiliza padrões de projeto para estruturar a solução. Em vez de discutir cada detalhe, a equipe utiliza palavras-chave e conceitos de padrões de projeto para definir a arquitetura do sistema.

Aqui está o grande diferencial ao utilizar padrões de projeto na comunicação: quando nos deparamos com problemas recorrentes, como a necessidade de notificar várias "pessoas" sobre a criação ou alteração de algo, é quase certo que utilizaremos o padrão de projeto Observer.

O Observer é um padrão de projeto comportamental que permite que você defina um mecanismo de assinatura para notificar múltiplos objetos sobre quaisquer eventos que aconteçam com o objeto que eles estão observando (https://refactoring.guru/pt-br/design-patterns/observer)

Isso nos poupa um tempo significativo em discussões sobre a melhor abordagem a ser utilizada, já que a solução é clara e bem estabelecida.

Desenho

Primeiramente, para desacoplar a ferramenta Sentry, frequentemente utilizamos o padrão de projeto Adapter. Esse padrão permite conectar qualquer tipo de ferramenta de monitoramento à nossa aplicação sem grandes impactos.

O Adapter é um padrão de projeto estrutural que permite objetos com interfaces incompatíveis colaborarem entre si (https://refactoring.guru/pt-br/design-patterns/adapter)

Para criar uma tarefa ou adicionar um recurso sem precisar conhecer antecipadamente as funcionalidades de monitoramento ou notificação, utilizamos o padrão de projeto Observer. Este padrão permite que nosso Gerenciador de Eventos notifique automaticamente os interessados quando uma nova informação está disponível.

O design utiliza principalmente o design pattern Observer e Adapter, para criar uma solução modular e flexível.

Resultado

A solução é mais elegante e desacoplada. A reunião é mais curta e a comunicação mais eficiente, pois os padrões de projeto fornecem uma linguagem comum e compreensível para todos os desenvolvedores.

Overengineering

Usar padrões de projeto não deve ser uma regra fixa; cada cenário deve ser avaliado individualmente. Em alguns casos, pode não fazer sentido desacoplar tanto a aplicação apenas para utilizar um padrão de projeto, pois isso pode adicionar complexidade desnecessária ao código. Portanto, pense bem antes de adotar padrões de projeto e converse com o time para analisar a real necessidade na sua aplicação.

Conclusão

A comparação entre as duas abordagens mostra claramente os benefícios de utilizar padrões de projeto no desenvolvimento de software. A abordagem do Time B, que utiliza padrões como Observer e Adapter, resulta em uma solução mais modular, flexível e fácil de manter. Além disso, a comunicação entre os desenvolvedores é mais eficiente, graças ao uso de uma linguagem comum proporcionada pelos padrões de projeto.

Incorporar esses padrões no seu fluxo de trabalho pode melhorar significativamente a qualidade do software produzido, reduzindo o acoplamento entre componentes e facilitando a manutenção e expansão do sistema. Portanto, a adoção de padrões de projeto é uma prática recomendada para equipes de desenvolvimento que buscam eficiência e qualidade em seus projetos.