Seções iMasters
Desenvolvimento + Java

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.

Mensagem do anunciante:

Torne-se um Parceiro de Software Intel®. Filie-se ao Intel® Developer Zone. Intel®Developer Zone

Comente também

2 Comentários

Flavio Ferreira

muito bom :D

Marcelo Hofer

Muito bom seu artigo, mostrou que não é necessário saber de cor e salteado todas as implementações dos padrões de projeto, mas sim suas intenções.

Sou novo no estudo desse assunto e se voçês puderem me ajudar agradeço.
Vou tentar explicar uma situação de modelagem em que, possivelmente, possa ser usado um desses padrões de projeto (vou tentar ser sucinto):

O sistema é de Solicitação de Serviços.

1. Um usuário (proponente) solicita um serviço descrevendo-o (descrição das atividades, justificativa, prazo, nome da área, etc.).
2. Esta solicitação de serviço deve ser aprovada pelo gerente do proponente.
3. Uma vez aprovado, o serviço é encaminhado para o gerente da área do serviço, que vai liberar o serviço para um funcionário executar.
4. O funcionário recebe a ordem, executa o serviço e informa o gerente da área quando do término.
5. O gerente da área confirma a execução do serviço e informa o proponente.
6. O proponente confirma o recebimento do serviço alegremente e o processo termina.

Inicialmente pensei em usar um atributo para representar o estado do serviço (‘solicitação’, ‘aprovado’, ‘liberado’ and so on), mas a medida que o serviço muda estado ele pode ganhar novos atributos/associações.
Pensei também em usar o padrão State, mas ele está mais relacionado com os métodos que dependem do estado do objeto em questão (pode ser útil). Lendo o artigo achei que o padrão Memento pode se encaixar nessa situação, vou estudá-lo pra ver se realmente é conveniente.

E vocês o que acham? Qual padrão poderia ser mais útil nesse caso?

Qual a sua opinião?