Código com Café

Quem desenvolve softwares orientados a objetos muito provavelmente utiliza padrões de projeto. Neste post vou dar uma pequena introdução a esse assunto tão extenso (e recorrente) na área de desenvolvimento de aplicações.

A definição inicial de “padrão de projeto” (design pattern em inglês) veio de Christopher Alexander, que afirmou que “cada padrão descreve um problema que ocorre muitas e muitas vezes em nosso ambiente, e então descreve o cerne da solução deste problema, de uma forma que você possa usar essa solução mais de um milhão de vezes, sem nunca fazer da mesma maneira duas vezes”^[1]. Tudo bem que Alexander estivesse falando de padrões na construção civil, mas esta ideia serviu de base para a bem conhecida “Gang of Four”, composta por Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides, que criou o livro “Design Patterns – elements of reusable object-oriented software”^[2]. Esse livro é a principal referência deste post (na versão em português do livro) e é reconhecido como o início oficial dos padrões de projeto em desenvolvimento de software.

Por que usar padrões de projeto? A resposta é simples: para facilitar o seu trabalho. Quando se cria um software orientado a objetos, em geral se espera que ele seja facilmente adaptável e reutilizável, para ajudar em pequenas alterações e correções futuras, além de evitar a repetição de código. Os padrões tornam isso possível e muito mais prático.

É muito comum a utilização de funções semelhantes para problemas semelhantes dentro de um mesmo programa. Os padrões podem evitar que se reescreva trechos de código, facilitando (e muito) uma alteração futura. Além disso, uma solução para uma parte de um software pode já ter sido feita em outro software. É muito mais fácil reutilizar o código com poucas alterações se você usa os padrões de projeto.

Provavelmente o principal motivo é: se já existe a solução para o seu problema, por que tentar criar outra? Seria como reinventar a roda.

Aqui vai uma lista dos padrões tratados no livro:

Padrões de Criação:

Abstract Factory: Fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.
Builder: Separa a construção de um objeto da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações.
Factory Method: Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe a ser instanciada. O Factory Method permite a uma classe postergar (defer) a instanciação às subclasses.
Prototype: Especifica os tipos de objetos a serem criados usando uma instância prototípica e criar novos objetos copiando este protótipo.
Singleton: Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela.

Padrões Estruturais

Adapter: Converte a interface de uma classe em outra interface esperada pelos clientes. O Adapter permite que certas classes trabalhem em conjunto, pois de outra forma seria impossível por causa de suas interfaces incompatíveis.
Bridge: Separa uma abstração da sua implementação, de modo que as duas possam variar independentemente.
Composite: Compõe objetos em estrutura de árvore para representar hierarquias do tipo partes-todo. O Composite permite que os clientes tratem objetos individuais e composições de objetos de maneira uniforme.
Decorator: Atribui responsabilidades adicionais a um objeto dinamicamente. Os decorators fornecem uma alternativa flexível a subclasses para extensão da funcionalidade.
Façade: Fornece uma interface unificada para um conjunto de interfaces em um subsistema. O Façade define uma interface de nível mais alto que torna o subsistema mais fácil de usar.
Flyweight: Usa compartilhamento para suportar grandes quantidades de objetos, de granularidade fina, de maneira eficiente.
Proxy: Fornece um objeto representante (surrogate), ou um marcador de outro objeto, para controlar o acesso ao mesmo.

Padrões Comportamentais

Chain of Responsability: Evita o acoplamento do remetente de uma solicitação ao seu destinatário, dando a mais de um objeto a chance de tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um objeto a trate.
Command: Encapsula uma solicitação como um objeto, desta forma permitindo que você parametrize clientes com diferentes solicitações, enfileire ou registre (log) solicitações e suporte operações que podem ser desfeitas.
Interpreter: Dada uma linguagem, define uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças nesta linguagem.
Iterator: Fornece uma maneira de acessar sequencialmente os elementos de um objeto agregado sem expor sua representação subjacente.
Mediator: Define um objeto que encapsula como um conjunto de objetos interage. O Mediator promove o acoplamento faco ao evitar que os objetos se reforam explicitamente uns aos outros, permitindo que você varie suas interações independentemente.
Memento: Sem violar a encapsulação, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa posteriormente ser restaurado para este estado.
Observer: Define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes sõ automaicamente notificados e atualizados.
State: Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado de classe.
Strategy: Define uma família de algoritmos, encapsula cada um deles e os faz intercambiáveis. O Strategy pernite que o algoritmo varie independentemente dos clientes que o utilizam.
Template Method: Define o esqueleto de um algoritmo em uma operação, postergando a definição de alguns passos para subclasses. O Template Method permite que as subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura.
Visitor: Representa uma operação a ser executada sobre os elementos da estrutura de um objeto. O Visitor permite que você defina uma nova operação sem mudar as classes dos elementos sobre os quais opera.

Estes padrões independem de linguagem, embora alguns deles sejam mais facilmente implementados em certas linguagens.

Esta foi só uma introdução bem simples ao assunto bem extenso de padrões de projeto. O livro contém esses padrões listados de forma bem explicada, com alguns exemplos de implementação e aplicações reais. Eu realmente recomendo. A internet é sempre uma fonte de bom (e mal) conteúdo, então sugiro pesquisar, pois existem padrões de projeto que não constam no livro. E é bem possível que eu acabe comentando mais profundamente um outro padrão no decorrer do tempo (e conforme eu mesmo os utilizar), então aguardem. Se quiserem saber mais sobre um padrão em específico, comente que eu pensarei no assunto.

Fontes: