Por: iMaster
Vamos abordar uma situação problemática relacionada com o uso de padrões de projeto. Percebo isso acontecer repetitivamente com profissionais Java. Qualquer ser humano normal que já investiu tempo estudando diversos livros e materiais relacionados com catálogos de padrões de projeto tem a tendência natural de esquecer grande parte do conteúdo depois de um certo tempo.
Partindo da ideia central de que um padrão simplesmente acontece em uma arquitetura, posso claramente afirmar que existe uma grande chance do profissional não visualizar um determinado cenário favorável para a aplicação do padrão.
Por mais que uma situação arquitetural aponte para um padrão de forma escancarada, se o profissional não estiver com as características daquele padrão injetadas na memória, ele fatalmente não irá se beneficiar dos objetivos motivadores da existência de um padrão, enviando possivelmente sua arquitetura para o penoso caminha da inflexibilidade.
Mas como podemos então evitar tudo isso? A resposta é simples:
O profissional precisa apenas se preocupar em memorizar a “intenção central” de um padrão para que quando o cenário arquitetural aparecer, ele possa facilmente identificar o caso de aplicabilidade.
Com o objetivo de ajudar os desenvolvedores, eu gostaria de publicar o meu resumo de intenções do catálogo 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, esse tipo de padrão é usado 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 no qual não se tem conhecimento dos tipos concretos de todos os 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 de outro objeto molde, denominado de “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 somente 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 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 modo a 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 à 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 que suporte um grande número 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 com que o objeto-substituto possa, de forma transparente, intermediar as interações para esse objeto-real.
Padrões Comportamentais
As motivações dos padrões comportamentais estão centralizadas nas responsabilidades e 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. Isso possibilita que múltiplos objetos-receptores possam ser dinamicamente enfileirados para manipular o pedido, de forma transparente.
Command – sua intenção é fazer com que uma requisição de um comando possa ser encapsulada como um objeto uniforme, permitindo 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 dois outros objetos, fazendo com que o determinado relacionamento destes dois objetos alvo possam 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 com que esse objeto possa ser restaurado para o estado original.
Observer - sua intenção é definir uma forma que possibilite a 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 a 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 de alterar sua estrutura de definição.
Dicas
Se porventura você é um desenvolvedor que deseja não perder nenhuma oportunidade de aplicar um padrão GOF, deve obrigatoriamente entender e decorar cada uma dessas motivações.
A dica principal é que você primeiro precisa entender a motivação do padrão, para depois memorizar a sua intenção.
Caso exista algum padrão GOF que você não tenha compreendido, separe um tempo de qualidade para estudá-lo, para que posteriormente você tenha condições de memorizar sua motivação.
Essas dicas servem também para serem aplicadas a outros catálogos.
Nenhum comentário:
Postar um comentário