Design Patterns ou Padrões de Projeto são sugestões de modelagem de classes (utilizando o Paradigma de Orientação a Objetos) que visam resolver problemas comuns do Paradigma de Programação Estruturado.
Na programação estruturada é comum termos uma situação em que após a execução de um comando que retorna um valor colocar-se um if para verificar a validade do valor retornado. Em seguida, executa-se algumas chamadas de função não inerentes ao fluxo das regras de negócio principal, mas necessárias para o fluxo de regras de negócio secundárias. Regras, estas, relacionadas ao valor gerado pela execução de comando inicial. Vejamos o fluxograma abaixo para entender melhor.
O fluxo principal do negócio seria: Cadastrar novo produto, Atender os clientes, Efetuar a venda, e por último Entregar o produto vendido ao cliente. Todas as lojas tem como objetivo principal vender produtos, para faturar, e obter lucro. Como ilustrado no diagrama de atividades abaixo.
Observe que existe uma grande diferença entre o diagrama de ativos onde é cada noção do sistema tá descrito nele e como o fluxo é bem mais simples. Até então não sabemos qual é a maneira mais adequada para criar os objetos organizar a estrutura eles e controlar o comportamento deles. Ainda existe muita coisa subtendida nessas abstrações.
Digamos ainda que uma loja insira em seu catálogo um novo produto ou atualize o estoque dele. Mas, ela também deseje realizar tarefas secundárias importantes, como: escrever no log a operação feita, criar anúncios nas redes sociais, atualizar anúncios no marketplaces ou ainda enviar uma campanha de e-mailmarketing para os clientes, dentre outras; não fazem parte do Fluxo principal de regras de negócio de vendas de mercadorias. Recebemos aqui que existem várias sob atividades e subfluxos que Precisamos desenhar para atender a necessidade do sistema. O diagrama UML de atividades a seguir demonstra o caso.
Essas são operações que precisam ser executadas todas as vezes que um produto novo é inserido no ecommerce (ou um produto que estava indisponível para venda), devido a falta de mercadorias no estoque, se tornou disponível. Vejamos um exemplo de código que ilustra esse cenário.
Essa é a forma como geralmente costumamos programar utilizando o Paradigma Estruturado. Nele temos alguns problemas, como por exemplo: uma bifurcação (if) que não deveria existir, e atividades aninhadas (escrever no log, postar no Instagram e enviar e-mails). Pelo fato desse código estar estruturado a cada vez que precisar de manutenção tem de se alterar essa função. Essa função também tem responsabilidades demais, pois ela envia e-mails, posta em rede social, e escreve no log enquanto deveria apenas salvar produto que está sendo cadastrado. Escrever código dessa forma faz com que o sistema fique mais vulnerável a bugs. Claramente, essa função não respeita os princípios SOLID.
Além disso, surgem várias dúvidas sobre como organizar e manter esse código. Essas dúvidas são divididas em 3 categorias. Os problemas criacionais, estruturais e comportamentais.
Nos padrões criacionais decidimos quais são as melhores formas de resolver problemas de criação de objetos. Nos padrões estruturais temos soluções que estruturam o código para suportar determinada carga de trabalho. Já nos padrões comportamentais evitamos que o software consiga se comportar de maneira inadequada, por isso, controlamos o comportamento dele.
Nos próximos posts apresentarei cada um dos padrões de projeto demonstrando quais problemas eles resolvem e como programar cada padrão.
Comentários