Dicas e Ajudas por Paulo Francis: Intenções de padrões de projeto

Hoje gostaria de abordar uma situação problemática que já vi acontecer repetitivamente com profissionais Java, relacionada com o uso de padrões de projeto. Quem já investiu tempo estudando diversos livros e materiais relacionados com catálogos de padrões de projeto tem tendência a esquecer grande parte do conteúdo depois de um certo tempo. Partindo da ideia central de que um padrão acontece em uma arquitetura, posso afirmar que existe uma grande chance de o profissional não visualizar um determinado cenário favorável para a aplicação de um padrão. Por mais visível que esteja que uma situação arquitetural aponte para um padrão, se o profissional não estiver com as características dele injetadas na memória, fatalmente não ira se beneficiar dos objetivos motivadores da existência daquele padrão, enviando, possivelmente, sua arquitetura para o penoso caminho da inflexibilidade.

Mas como podemos então evitar tudo isso? A resposta é simples:

O profissional precisa se preocupar apenas em memorizar a “intenção central” de um padrão, para que ele possa facilmente identificar o caso de aplicabilidade quando o cenário arquitetural aparecer.

Com o objetivo de ajudar os desenvolvedores, gostaria de publicar o meu resumo de intenções do catalogo de padrões GOF que utilizei para fazer esse mapeamento mental. Segue abaixo:

Padrões de criação

As motivações dos padrões de criação estão centralizadas em como os objetos são criados. Ou seja, eles são usados para capturar intenções focalizadas na criação de objetos.

Factory Method – sua intenção é definir um ponto de criação para um tipo de objeto no qual não se tem conhecimento do tipo concreto a ser usado.
Abstract Factory – sua intenção é definir um ponto de criação para uma família de objetos relacionados, ou dependentes, na qual não se tem conhecimento dos tipos concretos de todos esses objetos a serem usados. O Abstract Factory é basicamente uma “extensão em massa” do padrão Factory Method.
Prototype – sua intenção é definir um ponto de criação de objetos que precisam ser instanciados, usando como base a cópia, ou outro objeto de molde, denominado “protótipo”. Todos os objetos criados passam a existir contendo valores copiados desse suposto objeto protótipo.
Singleton – sua intenção é definir um ponto de criação de objetos que necessitem ser instanciados apenas uma vez durante todo o ciclo de execução da solução e oferecer um ponto único de acesso para essa referência.
Builder – sua intenção é definir um ponto de criação de um objeto complexo de sua representação, de forma que esse ponto de construção possa ser parametrizado para construir diferentes variações desse mesmo objeto.

Padrões estruturais

As motivações dos padrões estruturais estão centralizadas na organização e na composição de classes e seus objetos. Ou seja, eles são usados para capturar intenções focalizadas na composição estrutural dos objetos.

Adapter – sua intenção é converter a interface de uma classe para outra interface requerida, definindo um ponto intermediário de ligação com o objetivo de promover comunicação entre duas interfaces incompatíveis.
Bridge – sua intenção é separar a abstração de uma ação de suas diferentes implementações, de forma que ambas possam ser flexivelmente intercambiais.
Composite – sua intenção é fazer com que um objeto possa ser genericamente operado, de forma que represente uma estrutura dinâmica hierárquica de composições de objetos.
Decorator – sua intenção é definir um meio alternativo para a herança de adicionar responsabilidades a um objeto de forma flexível e dinâmica em tempo de execução.
Facade – sua intenção é definir uma interface fácil, simples e unificada para um ou mais conjuntos de operações relacionados a subsistemas internos.
Flyweight – sua intenção é definir um ponto de compartilhamento eficiente e que suporte um grande numero de manipulações de objetos de granulação fina reutilizáveis.
Proxy – sua intenção é definir um objeto-substituto para um objeto-real, de forma que o objeto-substituto possa, transparentemente, intermediar as interações para esse objeto-real.

Padrões comportamentais

As motivações dos padrões comportamentais estão centralizadas nas responsabilidades e nos relacionamentos dos objetos. Ou seja, eles são usados para capturar intenções focalizadas no que um objeto pode fazer e como ele se relaciona com os outros.

Chain of Responsability – sua intenção é desacoplar o objeto-enviador de um pedido dos supostos objetos-receptores, possibilitando que múltiplos objetos-receptores possam ser enfileirados de forma dinâmica para manipular o pedido transparentemente.
Command – sua intenção é fazer com que uma requisição de um comando possa ser encapsulada como um objeto uniforme, permitindo com que objetos-clientes possam ser parametrizados flexivelmente com diferentes objetos-comandos intercambiais.
Interpreter – sua intenção é definir objetos que possam representar e interpretar intercambialmente uma determinada gramática textual qualquer.
Iterator – sua intenção é definir uma forma com que objetos agregados dentro de um objeto possam ser sequencialmente acessados por outros objetos sem expor os detalhes internos de seus relacionamentos e implementações.
Mediator - sua intenção é definir um objeto utilizado para encapsular o relacionamento entre outros dois objetos, fazendo com que determinado relacionamento possa ser implementado de forma indireta, flexível e intercambial.
Memento - sua intenção é definir uma forma de capturar e armazenar o estado de um objeto, de forma que ele possa ser restaurado para o estado original anterior.
Observer - sua intenção é definir uma forma que possibilite um objeto agregador notificar e atualizar automaticamente outros objetos agregados dependentes quando ocorrer uma alteração no estado no objeto agregador.
State - sua intenção é definir uma forma que possibilite um objeto variar intercambialmente seus comportamentos quando mudanças internas no seu estado acontecerem.
Strategy - sua intenção é definir um objeto que possua determinados comportamentos que sofram variações intercambiais, dependendo de outros objetos clientes que os manipulam.
Template Method - sua intenção é definir objetos que implemente um algoritmo previamente formatado dentro de um comportamento, fazendo com que outros objetos possam, intercambialmente, substituir partes das funcionalidades desse algoritmo.
Visitor - sua intenção é definir uma forma que possibilite que diversas operações possam ser dinamicamente aplicadas para um objeto, sem a necessidade alterar sua estrutura de definição.

Dicas

Se porventura você é um desenvolvedor que não quer perder nenhuma oportunidade de aplicar um padrão GOF, deve obrigatoriamente entender e decorar cada uma dessas motivações. A dica principal é que o candidato primeiro precisa entender a motivação do padrão, para depois memorizar sua intenção. Caso exista algum padrão GOF que você não tenha compreendido, separe um tempo para estudá-lo, para que posteriormente você tenha condições de memorizar sua motivação. Vale lembrar também que a dica serve para ser aplicada para outros catálogos.

Escrito por Fernando Franzini