Padrão de comportamento

Na programação orientada a objetos, os objetos trocam informações entre si

por meio de parâmetros. Essa comunicação pode ser expressa por intermédio do
diagrama de sequência da Linguagem de Modelagem Unificada (UML).
Os padrões comportamentais se preocupam com a comunicação entre objetos,
pois têm como objetivo caracterizar o controle complexo do fluxo de comunicação,
afinal essa troca se torna mais difícil em situações de execução. Para permitir um foco
maior na relação dos objetos, esses padrões desviam o fluxo de controle.
A concepção de herança é utilizada para distribuir o comportamento entre as
classes. Já o conceito de composição é aplicado para definir a conduta entre objetos.
A ideia é que objetos trabalhem em pares para executar tarefas que não seriam
capazes de realizar sozinhos.
A família de padrões de comportamento pode ser dividida em:
Chain of Responsability: Uma solicitação é passada por uma cadeia onde,
individualmente, cada objeto decide se vai executá-la ou continuar repassando.
• Command: transforma uma solicitação de comando em um objeto;
• Interpreter: uma forma de inclusão de elementos de linguagem em um
programa;
• Iterator: fornece acesso sequencial aos elementos de uma coleção
(lista).
• Mediator: define um objeto mediador para a comunicação entre as
classes;
• Memento: captura e restaura o estado interno de um objeto sem revelar
os detalhes da sua implementação;
• Null Object: desenvolvido para ser o valor padrão de um objeto;
• Observer: uma maneira de alertar várias classes a respeito de uma
modificação sofrida pelo objeto observado;
• State: modifica o comportamento de um objeto ao ter o seu estado
alterado.
 • Strategy: encapsula algoritmos dentro de classes;
• Template Method: define etapas de execução para métodos de classe
abstrata;
• Visitor: define uma nova operação para uma classe sem alterá-la.

Agora, vejamos um exemplo prático de uso do padrão Iterator no acesso a uma

lista de dados tipo string.

Figura– Padrão Iterator

Esse código simples de interface iterator aplica o conceito de classe para

resgatar elementos dentro da lista de nomes criada na linha nove. O padrão faz um
loop e acessa sequencialmente os elementos dentro da lista (da linha 20 até a 22). O
método de iteração é aplicado à lista e atribuído ao objeto tipo iterator na linha 18.
 GRASP

O General Responsibility Assignment Software Patterns (GRASP) é um

conjunto de padrões/princípios relacionados a softwares de atribuição de
responsabilidade geral. A responsabilidade do software é fundamental não só para o
entendimento da classe, mas também para os módulos e sistemas.
Uma classe pode ser dividida em responsabilidade e dados ou em
comportamento (métodos) e estado (características) (BARNES; KOLLING, 2009).
O comportamento está relacionado às responsabilidades que a classe deve
cumprir, ou seja, criar objetos, processar informações (dados) e iniciar operações de
outros objetos. Já o estado trata daquilo que o objeto sabe, portanto se refere a quais
são os seus dados; se estes são privados ou públicos; quais as suas referências aos
objetos; e quais objetos podem ser derivados.
Segundo Martin (2000), são usados exatamente nove padrões de software de
atribuição de responsabilidade geral no GRASP. Eles são:
• Information Expert: esse princípio tem como finalidade identificar os
locais de responsabilidade. Trata-se do princípio mais fundamental da
orientação a objetos, pois todo objeto deve delegar responsabilidades;
• Creator: quando um objeto B da classe A é criado, A fica responsável
pela criação de B. Desta forma, a classe contém informações dos atributos e
da inicialização do objeto;
• Controller: responsável por definir objetos que gerenciarão os eventos
do sistema. Podemos citar como exemplo prático o controller da arquitetura
MVC;
• Low Coupling: o conceito de acoplamento faz referência ao
relacionamento de dependência que um objeto tem com outro. Quanto maior a
dependência, maior o acoplamento. Low coupling, portanto, refere-se à baixa
dependência no relacionamento entre objetos. Desta forma, é possível fazer
alterações nos objetos sem causar mudanças significativas no sistema em
geral;
 • High Cohesion: coesão está relacionada às responsabilidades dos
objetos. Desta forma, um objeto altamente coeso tem suas responsabilidades
muito bem definidas e não depende de outros objetos para executá-la. Pode-
se dizer que um objeto de alta coesão tem acoplamento baixo;
• Indirection: o padrão de indireção faz uso de um objeto intermediador
para estabelecer uma comunicação entre dois outros objetos com baixo
acoplamento. No modelo MVC, o controller faz a mediação entre Objeto View
e o Objeto Model;
• Polymorphism: polimorfismo é um conceito fundamental na orientação
a objetos que define que um determinado objeto tenha o mesmo nome de um
método pertencente a uma superclasse, podendo, porém, ser implementado de
outra forma. O padrão de estratégia faz uso deste conceito;
• Pure Fabrication: devido à dificuldade existente na programação
orientada a objetos de determinar onde ficará a responsabilidade de um objeto,
criam-se classes ou interfaces que desempenhem esse papel. Por exemplo,
onde fica a responsabilidade de conversão de moedas em um sistema de e-
commerce?

Para resolver esse problema, cria-se uma nova classe ou interface;

• Protected Variations: tem como impedir que os elementos sejam
modificados por outros. É feito o uso do conceito de polimorfismo para a criação
de implementações diferentes de uma interface.
O controle das responsabilidades no desenvolvimento de um sistema é o ponto
chave para o uso de uma boa arquitetura.
A combinação dos padrões deve existir para que as boas práticas sejam
implementadas e para que os novos sistemas apoiem as novas funcionalidades. Em
outras palavras, que aceitem as mudanças e não sejam resistivas a elas.
REFERÊNCIAS

BARNES, D. J.; KOLLING, M. Programação orientada a objetos com Java. 4. ed. São
Paulo: Pearson, 2009.
GALLOTTI, G. M. A. Arquitetura de Software. São Paulo: Pearson, 2016.
GUERRERO, C. A.; SUÁREZ, J. M.; GUTIÉRREZ, L. E. Patrones de Diseño GOF
(The Gang of Four) en el contexto de Procesos de Desarrollo de Aplicaciones
Orientadas a la Web. Información tecnológica, v. 24, n. 3, p. 103-114, 2013.
MARTIN, R. C. Design Principles and Design Pattern. Object Mentor, v. 1, n. 34, p.
597, 2000.