The latest articles on DEV Community by Ricardo Ludwig (@ricardoludwig). https://dev.to/ricardoludwig https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F60139%2F63dbb505-353f-4064-a9b7-9d47eb3c6871.jpg https://dev.to/ricardoludwig en Ricardo Ludwig Sat, 22 Mar 2025 23:35:57 +0000 https://dev.to/ricardoludwig/padroes-de-projetos-design-patterns-3jnj https://dev.to/ricardoludwig/padroes-de-projetos-design-patterns-3jnj <p><em>Design Patterns</em> são soluções comprovadas para problemas recorrentes. No<br> mundo do desenvolvimento de software temos os padrões de projetos apresentados<br> no livro <em>Design Patterns: Elements of Reusable Object-Oriented Software</em><br> escrito por <em>Erich Gamma</em>, <em>Richard Helm</em>, <em>Ralph Johnson</em> e <em>John Vlissides</em>.</p> <p>Os 23 padrões de projetos apresentados no livro são divididos em três categorias:</p> <ol> <li>Padrões de Criação (<em>Creational Patterns</em>)</li> <li>Padrões Estruturais (<em>Structural Patterns</em>)</li> <li>Padrões Comportamentais (<em>Behavioral Patterns</em>)</li> </ol> <h2> Padrões de Criação (<em>Creational Patterns</em>) </h2> <h2> O que são? </h2> <p>São os padrões que focam na <strong>forma como objetos são criados</strong>. Eles encapsulam <br> a lógica de instanciação, promovendo maior flexibilidade ao permitir que o <br> código fique <strong>independente da implementação concreta</strong> das classes que utiliza.</p> <p>O objetivo principal é <strong>desacoplar o processo de criação dos objetos do seu <br> uso</strong>, facilitando mudanças e promovendo maior reutilização de código.</p> <h2> Problemas que resolvem </h2> <ul> <li> <strong>Criação direta de objetos</strong> que depende de implementações específicas, dificultando a manutenção e evolução do código.</li> <li> <strong>Código duplicado</strong> relacionado à instância de objetos com lógica complexa de construção.</li> <li> <strong>Dependência de classes concretas</strong>, reduzindo a flexibilidade e a capacidade de testar.</li> <li> <strong>Incapacidade de controlar ou padronizar a criação de instâncias</strong> em contextos mais complexos (por exemplo, sistemas com muitas variações de objetos ou que exigem controle de ciclo de vida).</li> </ul> <h2> Exemplos de Padrões de Criação </h2> <ul> <li> <strong>Singleton</strong> – Garante que uma classe tenha apenas uma instância e fornece um ponto global de acesso a ela.</li> <li> <strong>Factory Method</strong> – Define uma interface para criar um objeto, mas permite que subclasses decidam qual classe instanciar.</li> <li> <strong>Abstract Factory</strong>, é uma <em>factory</em> de <em>factories</em>, ou seja, é uma classe capaz de criar outras classes. É uma classe que encapsula múltiplos métodos de fábrica.</li> <li> <strong>Builder</strong>, utilizado para criação de objetos complexos, onde a criação do objeto depende de muitos parâmetros. O padrão de design <strong>Builder</strong> desacopla a atribuição de argumentos da criação de objetos e permite a construção de objetos complexos passo a passo. </li> <li> <strong>Prototype</strong>, utilizado para a criação de objetos ligeiramente diferentes. Isso é feito clonando um objeto existente e fazendo as alterações necessárias.</li> </ul> <h2> Desvantagens </h2> <p>Apesar de trazerem maior flexibilidade, os padrões de criação também têm <br> <strong>desvantagens</strong>:</p> <ul> <li> <strong>Complexidade de código</strong>: Introduzem várias interfaces, classes abstratas ou objetos auxiliares, o que pode aumentar o esforço de entendimento.</li> <li> <strong>Sobrecarga desnecessária</strong>: Para casos simples, aplicar padrões como Builder ou Abstract Factory pode ser exagero e resultar em <em>overengineering</em>.</li> <li> <strong>Dificuldade de depuração</strong>: A criação indireta pode dificultar o rastreamento da origem de objetos em ambientes com muitos níveis de abstração.</li> <li> <strong>Excesso de classes</strong>: Muitos desses padrões requerem várias classes ou estruturas auxiliares, o que pode poluir o projeto se não for bem organizado.</li> </ul> <h2> Padrões Estruturais (<em>Structural Patterns</em>) </h2> <h3> O que são? </h3> <p>Os <strong>Padrões Estruturais</strong> tratam da <strong>forma como classes e objetos são <br> compostos para formar estruturas maiores</strong>. Seu principal objetivo é facilitar <br> o <strong>design de sistemas flexíveis e reutilizáveis</strong>, promovendo o baixo <br> acoplamento entre os componentes.</p> <p>Eles se concentram em <strong>como as entidades são conectadas</strong>, facilitando a <br> <strong>extensão de funcionalidades</strong> sem necessidade de modificar o código <br> existente (aderência ao princípio <strong>Open/Closed</strong>).</p> <h3> Problemas que resolvem </h3> <ul> <li> <strong>Acoplamento rígido entre classes</strong> que dificulta a reutilização.</li> <li> <strong>Designs que não escalam bem</strong> com o crescimento do sistema.</li> <li> <strong>Dificuldade em alterar a estrutura interna de objetos</strong> sem impactar o restante da aplicação.</li> <li> <strong>Incompatibilidade entre interfaces de classes</strong> que precisam trabalhar juntas.</li> </ul> <h3> Exemplos de Padrões Estruturais </h3> <ul> <li> <strong>Adapter</strong> – Permite que interfaces incompatíveis trabalhem juntas.</li> <li> <strong>Bridge</strong> – Separa uma abstração da sua implementação.</li> <li> <strong>Composite</strong> – Permite tratar objetos individuais e composições de objetos de maneira uniforme.</li> <li> <strong>Decorator</strong> – Adiciona responsabilidades a objetos dinamicamente.</li> <li> <strong>Facade</strong> – Fornece uma interface simplificada para um subsistema complexo.</li> <li> <strong>Flyweight</strong> – Compartilha objetos para economizar memória.</li> <li> <strong>Proxy</strong> – Fornece um substituto ou representante de outro objeto.</li> </ul> <h3> Desvantagens </h3> <p>Embora tragam muitos benefícios, os padrões estruturais também têm <br> <strong>desvantagens</strong>, como:</p> <ul> <li> <strong>Complexidade adicional</strong>: Podem introduzir novas classes e interfaces, tornando o sistema mais difícil de entender.</li> <li> <strong>Sobrecarga de abstrações</strong>: O uso excessivo pode dificultar a manutenção por causa do número de camadas envolvidas.</li> <li> <strong>Desempenho</strong>: Em alguns casos, como com <code>Proxy</code> ou <code>Decorator</code>, pode haver uma penalidade de desempenho devido à delegação de chamadas.</li> <li> <strong>Dificuldade de depuração</strong>: Quando muitas estruturas envolvem um objeto, rastrear a origem de um problema pode se tornar mais difícil.</li> </ul> <h2> Padrões Comportamentais (<em>Behavioral Patterns</em>) </h2> <h3> O que são? </h3> <p>Os <strong>Padrões Comportamentais</strong> tratam da <strong>comunicação e interação entre <br> objetos</strong>. Eles definem <strong>como responsabilidades são distribuídas</strong> entre os <br> objetos e <strong>como eles colaboram</strong> para realizar tarefas, respeitando o baixo <br> acoplamento e promovendo maior flexibilidade e reutilização.</p> <p>Esses padrões ajudam a <strong>encapsular o comportamento</strong> e <br> <strong>delegar responsabilidades</strong>, tornando o código mais coeso e fácil de manter.</p> <h3> Problemas que resolvem </h3> <ul> <li> <strong>Distribuição ineficiente de responsabilidades</strong> entre classes.</li> <li> <strong>Acoplamento forte entre objetos</strong>, dificultando a reutilização e testes.</li> <li> <strong>Dificuldade em alterar comportamentos</strong> sem modificar o código existente.</li> <li> <strong>Falta de flexibilidade nas interações entre objetos</strong>, levando à rigidez do sistema.</li> <li> <strong>Código com muitos condicionais</strong> para decidir qual comportamento executar.</li> </ul> <h2> Exemplos de Padrões Comportamentais </h2> <ul> <li> <strong>Chain of Responsibility</strong> – Passa a solicitação por uma cadeia de objetos até que um deles a processe.</li> <li> <strong>Command</strong> – Encapsula uma solicitação como um objeto, permitindo parametrizar clientes com diferentes requisições.</li> <li> <strong>Interpreter</strong> – Avalia sentenças em uma linguagem, representando sua gramática com classes.</li> <li> <strong>Iterator</strong> – Fornece uma maneira de acessar os elementos de um objeto agregado sequencialmente sem expor sua estrutura interna.</li> <li> <strong>Mediator</strong> – Define um objeto que centraliza a comunicação entre objetos, promovendo o baixo acoplamento.</li> <li> <strong>Memento</strong> – Captura e externaliza o estado interno de um objeto sem violar seu encapsulamento.</li> <li> <strong>Observer</strong> – Define uma dependência um para muitos entre objetos para que, quando um objeto mudar de estado, todos os seus dependentes sejam notificados.</li> <li> <strong>State</strong> – Permite que um objeto altere seu comportamento quando seu estado interno muda.</li> <li> <strong>Strategy</strong> – Define uma família de algoritmos, encapsula cada um deles e os torna intercambiáveis.</li> <li> <strong>Template Method</strong> – Define o esqueleto de um algoritmo em uma operação, deixando alguns passos para as subclasses.</li> <li> <strong>Visitor</strong> – Permite adicionar operações a objetos de uma estrutura sem alterar suas classes.</li> </ul> <h2> Desvantagens </h2> <p>Embora úteis, os padrões comportamentais também apresentam <strong>desvantagens</strong>:</p> <ul> <li> <strong>Aumento da complexidade</strong>: Muitos padrões introduzem várias interfaces e classes auxiliares, o que pode complicar o projeto.</li> <li> <strong>Dificuldade de rastreamento</strong>: A lógica distribuída entre vários objetos ou métodos pode dificultar o entendimento do fluxo de execução.</li> <li> <strong>Possível sobrecarga de abstrações</strong>: Em casos simples, pode ser exagerado aplicar esses padrões, gerando código mais difícil de manter.</li> <li> <strong>Manutenção complexa</strong>: Comportamentos espalhados por múltiplos objetos ou delegados a outras classes podem dificultar a depuração e manutenção do sistema.</li> </ul> designpatterns