GRASP General Responsibility Assignment Software Patterns

Os padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto

GRASP Qual é a conexão entre Responsabilidades, GRASP e

diagramas UML?

A ocasião para considerar a atribuição de responsabilidades às classes é durante a elaboração dos diagramas de sequência

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

4

O Criador (Creator) Problema: Quem deve ser responsável por criar uma nova instância de uma

classe?

Solução: Atribua à classe B a responsabilidade de criar uma instância de A se

pelo menos um desses for verdadeiro (quanto mais melhor):

• B contém ou agrega A

• B registra a existência de A

• B usa A

• B tem os dados necessários para a inicialização de A que

serão passados ao construtor de A

Exemplo: Jogo de Banco Imobiliário Quem deve criar os objetos correspondentes às peças do tabuleiro?

Exemplo: Jogo de Banco Imobiliário

visão estática

visão dinâmica

Outro exemplo: um ponto de venda

Cuidado com a Criação de

Objetos Complexos

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

10

O padrão Especialista (Information Expert) Problema:

Precisa-se de um princípio geral para atribuir responsabilidades a objetos

Durante o projeto, em que são definidas as interações entre objetos, é preciso fazer escolhas sobre a atribuição de responsabilidades a classes.

Solução

Atribuir uma responsabilidade ao especialista de informação: classe que possui a informação necessária para cumpri-la;

Inicie declarando claramente a responsabilidade

Exemplo: O Banco Imobiliário Quem deve localizar uma posição do tabuleiro dada a sua identidade?

Exemplo: O ponto de venda Quem deve ser responsável por conhecer o total da venda?

Exemplo: O ponto de venda Quem deve ser responsável por conhecer o total da venda?

Exemplo: O ponto de venda Quem deve ser responsável por conhecer os subtotais?

Exemplo: O ponto de venda Quem deve ser responsável por conhecer o preço de cada item

de venda?

Exemplo: O ponto de venda

O padrão Especialista (Information Expert) Benefícios:

O encapsulamento da informação é mantido uma vez que os objetos usam seus próprios dados para realizar as tarefas.

Baixo acoplamento entre as classes.

O comportamento do sistema é distribuído entre as classes que têm as informações, encorajando a definição de classes mais "leves", mais fáceis de entender e de manter.

Contraindicações : Em algumas situações, a solução sugerida pelo especialista pode ser

indesejada. (Quem deve persistir uma venda no banco?)

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

20

Coesão Alta Problema:

Como manter os objetos focados, compreensíveis, gerenciáveis e, em consequência, com Baixo Acoplamento?

Classes que fazem muitas tarefas não relacionadas são mais difíceis de entender, de manter e de reusar, além de mais vulneráveis às mudanças.

Solução:

Atribua responsabilidades de modo que a coesão da classe permaneça alta. Use esse critério para avaliar alternativas

Coesão Medida de quão relacionadas ou focadas estão as

responsabilidades de um elemento.

Exemplo:

Cao é coesa se tem apenas operações relacionadas ao Cão (morder, correr, latir, comer) a apenas ao Cão. ‘~ao terá que imprimir, listar cães, etc...

Alta coesão promove design modular

Coesão Alta

Alta Coesão Que classe é responsável por criar um pagamento

(Payment) e associá-lo a uma venda (Sale) ?

Register assumiu responsabilidade por uma coisa que é parte de Sale (fazer um pagamento não é responsabilidade de registrar)

Alta Coesão Register delega a responsabilidade a Sale, aumentando a

coesão de Register

Coesão Uma classe com baixa coesão sofre dos

seguintes problemas:

difícil de compreender

difícil de reutilizar

difícil de manter

frágil; frequentemente tem de ser alterada

Coesão Como um princípio básico, uma classe com alta

coesão:

tem um número relativamente pequeno de métodos,

a funcionalidade desses métodos é altamente relacionada, e

não faz trabalho de mais.

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

29

Baixo Acoplamento Problema:

Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização?

Solução:

Atribua as responsabilidades de modo que o acoplamento entre classes permaneça baixo. Use este princípio para avaliar alternativas.

Acoplamento Medida de quanto um elemento está conectado a, ou

depende de outros elementos.

Uma classe com acoplamento forte depende de muitas outras classes: tais classes podem ser indesejáveis

O acoplamento está associado à coesão: maior coesão, menor acoplamento e vice-versa.

Exemplo: O Banco Imobiliário Pergunta: Por que o Tabuleiro e não um cachorro?

Baixo Acoplamento Ponto Chave:

O Especialista favorece o Baixo Acoplamento

Retornando à motivação do especialista:

conduz a soluções que favorecem o baixo acoplamento. O especialista nos pede que encontremos o objeto que tem a maior parte da informação necessária para assumir a responsabilidade (por exemplo, o tabuleiro)

Se pusermos a responsabilidade em algum outro lugar qualquer (por exemplo, o cachorro) o acoplamento global será maior porque mais informações terão de ser compartilhadas entre os objetos.

Outro Exemplo: O ponto de venda Suponha que temos de criar um objeto pagamento e associá-lo à venda.

Que classe deve ser responsável por isso?

1ª alternativa

2ª alternativa

Acoplamento entre classes a) A ClasseA tem um atributo do tipo ClasseB

Acoplamento entre classes b) A ClasseA tem um método que, de alguma forma,

referencia uma instância de ClasseB. Tipicamente, esta

referência se dá através de um parâmetro ou variável

local do tipo ClasseB ou por um objeto do tipo ClasseB

retornado pela chamada de algum método

Acoplamento entre classes c) A ClasseA é uma subclasse de ClasseB

Acoplamento entre classes d) A ClasseB é uma interface e a ClasseA implementa esta

interface

Acoplamento entre classes Discussão:

Classes que, por natureza, são genéricas e que têm alta probabilidade de reutilização deveriam ter acoplamento baixo

O caso extremo do baixo acoplamento é o não acoplamento: contraria o princípio da orientação a objetos:

objetos conectados, trocando mensagens entre si.

O acoplamento alto não é o problema em si. O problema é o acoplamento a classes que, de alguma forma são instáveis:

sua interface, sua implementação ou sua mera presença.

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

41

O Controlador Problema:

Quem deve ser o responsável por lidar com um evento de uma interface de entrada?

Solução:

Atribuir a responsabilidade de receber ou lidar com um evento do sistema para uma classe que representa todo o sistema (controlador de fachada – front controller), um subsistema e um cenário de casos de uso (controlador de caso de uso ou sessão)

O Controlador Que objeto, fora da camada de apresentação, deve receber e

coordenar a solicitação da execução de uma operação?

O princípio da separação Modelo-Vista

O princípio da separação Modelo-Vista pode ser enunciado em duas

partes:

• Não conecte diretamente objetos pertencentes à

interface com o usuário (a vista) com objetos não

pertencentes à interface com o usuário (IU).

• Não coloque lógica da aplicação (tal como o cálculo

de impostos) nos métodos dos objetos da IU

O princípio da separação Modelo-Vista A motivação para a separação Modelo-Vista inclui:

• Suportar a criação de classes de negócio coesas, com foco

nos processos do domínio ao invés de na interface com o

usuário.

• Permitir o desenvolvimento separado das camadas de

apresentação e negócio.

• Minimizar o impacto na camada de negócio das alterações

nos requisitos da interface com o usuário.

O princípio da separação Modelo-Vista

• Permitir que novas vistas sejam facilmente conectadas

aos objetos de negócio existentes, sem afetar a camada

de negócios.

• Permitir a existência de múltiplas vistas simultâneas para

uma mesma camada de negócios (por exemplo, a

visualização de dados de vendas na forma tabular ou

através de um gráfico de pizzas)

A motivação para a separação Modelo-Vista inclui:

O objeto Controlador O objeto Controlador responde a uma questão básica no

projeto de sistemas OO: Como conectar a camada de

apresentação à camada da lógica do negócio?

O objeto Controlador O controlador é o primeiro objeto fora da camada de interface com o

usuário a receber ou tratar uma mensagem para o sistema.

Existem duas alternativas possíveis para o objeto controlador:

• Um objeto Controlador para todo o sistema

• Um objeto Controlador por Caso de Uso (ou por cenário

de Caso de Uso)

Controlador Um sistema contendo operações “de sistema”

associados com eventos do sistema

Controlador Os benefícios do padrão controlador são:

Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio

Oportunidade para controlar o estado do caso de uso

Exemplo: Ponto de Venda

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

53

Polimorfismo Problema:

Como tratar alternativas baseadas no tipo? Como criar componentes de software "plugáveis"?

Deseja-se evitar variação condicional (if-then-else): pouco extensível

Deseja-se substituir um componente por outro sem afetar o cliente

Solução:

Quando alternativas ou comportamentos relacionados variam com o tipo (classe), atribua as responsabilidades aos tipos usando operações polimórficas.

Exemplo

O Banco Imobiliário Como projetar para acomodar as diferentes ações baseadas

no tipo da posição do tabuleiro?

Um mau projeto:

O Banco Imobiliário O comportamento estático:

O Banco Imobiliário O comportamento dinâmico:

O Banco Imobiliário O comportamento dinâmico:

O Banco Imobiliário

O comportamento dinâmico:

O Banco Imobiliário O comportamento dinâmico:

O Banco Imobiliário

O comportamento dinâmico:

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

64

Pure Fabrication Problema:

Que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento", mas as soluções oferecidas pelo "Especialista" não são apropriadas?

Atribuir responsabilidade apenas para as classes do domínio conceitual pode levar a situações de maior acoplamento e menor coesão.

Solução: Atribua um conjunto coeso de responsabilidades a uma classe

artificial que não representa um conceito no domínio da aplicação, uma classe fictícia que possibilite alta coesão, baixo acoplamento e o reuso.

Ponto de Venda: Salvar uma Venda no Banco de Dados O especialista nos diz para atribuir a responsabilidade à classe Venda, uma vez que ela conhece os dados da venda. Considere no entanto as seguintes implicações:

Salvar um objeto no Banco de Dados implica em uma série de operações não relacionadas ao conceito de venda

A classe venda tem de ser associada à interface do banco de dados relacional (JDBC, por exemplo)

Várias outras classes no projeto terão de fazer a mesma coisa.

Pure Fabrication

O Banco de Dados

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

70

Indireção Problema:

Onde colocar uma responsabilidade de modo a evitar o acoplamento direto entre duas ou mais classes?

Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso?

Solução: Atribua a responsabilidade a um objeto intermediário que faça a

mediação entre componentes ou serviços de modo que eles não sejam diretamente acoplados

O objeto intermediário cria uma camada de indireção entre os dois componentes que não mais dependem um do outro: ambos dependem da indireção

Indireção Exemplo: Indireção através de um adaptador

Indireção "A maior parte dos problemas em Ciência da Computação

pode ser resolvida por um nível adicional de indireção"

Velho provérbio com especial relevância para

sistemas orientados a objetos

"A maior parte dos problemas de desempenho pode ser resolvida removendo-se algumas

camadas de indireção"

INVERSÃO DE CONTROLE

Inversão de Controle – IoC Princípio de Hollywood:

“Não nos ligue, nós ligaremos”.

Dependência de componentes.

também conhecida como colaboradores de objetos.

O objeto que exige dependência é conhecido como objeto dependente.

Frameworks é responsável pela execução da operação.

Ocorre em tempo de execução.

76

Inversão de Controle: Motivação – Cenário 1 Classe A precisa de uma referência para a Classe B.

Classe B é uma classe concreta que tem um construtor padrão.

Classe A possui uma instância de B.

Nenhuma outra classe pode acessar uma instância da Classe B [Mal06].

77

public class A{

private B b;

public A(){

b=new B();

}

}

Inversão de Controle: Motivação – Cenário 2 Objeto a possui referência para os objetos c e b.

78

public class A{

private B b;

public A(){

C c = new C();

b = new B(c);

}

}

Inversão de Controle: Motivação – Cenário 3 A precisa de uma referência para B, e não precisa saber

como B é instanciado.

B pode ser uma interface, uma classe abstrata ou concreta.

Antes de instanciar a classe A, precisa de uma referência para a classe B.

79

public class A{

private B b;

public A(){ }

public setB(B b){

this.b=b;

}

}

Tipos de Inversão de Controle

Inversão de Controle (IoC) possui dois tipos [Har05]:

Injeção de Dependência (Dependency Injection)

Procura por Dependência (Dependency Lookup)

Injeção de Dependência sempre diz respeito a IoC, mas IoC nem sempre referencia Injeção de Dependência

80

81

Tipos de Inversão de Controle

Inversão de

Controle

Procura por

Dependência

Injeção de

Dependência

Contextualized

Dependency

Lookup

Dependency

Pull

Interface Setter Construtor

Tipos de Inversão de Controle Procura por Dependência:

um componente deve obter uma referência para uma dependência;

dois subtipos:

Dependency Pull

Contextualized Dependency Lookup (CDL)

Injeção de Dependência: as dependências são literalmente injetadas (incluídas)

três subtipos:

Interface – Tipo 1

Setter – Tipo 2

Constructor – Tipo 3 82

Contêineres de Inversão de Controle Spring

Avalon

PicoContainer

HiveMind

Excalibur: Fortress

Resin

Copland (Ruby)

Mentawai

83

Procura por Dependência — Dependency Pull As dependências são obtidas através de um registro

assim que necessário;

Mecanismo para encontrar componentes que gerenciam o frameworks.

84

Procura por Dependência com Spring public static void main(String[] args) throws Exception { // get the bean factory BeanFactory factory = getBeanFactory(); MessageRenderer mr = (MessageRenderer) factory.getBean("renderer"); mr.render(); }

Procura por Dependência — Contextualized Dependency Lookup (CDL)

Semelhante ao Dependency Pull;

Procura é executada pelo contêiner que está gerenciando o recurso e não a partir de um registro central;

CDL funciona através da implementação de uma interface.

85

Interface do Componente para CDL com Spring public interface ManagedComponent { public void performLookup(Container container); }

Procura por Dependência — Contextualized Dependency Lookup (CDL)

Executa o método performLookup() implementado pelo componente;

O componente pode procurar sua dependência utilizando a interface Container.

86

Obtendo dependência com o CDL public class ContextualizedDependencyLookup implements ManagedComponent { private Dependency dep; public void performLookup(Container container) { this.dep = (Dependency)container.getDependency ("myDependency"); } }

Dependency Injection Problema

Controle convencional: o próprio objeto cria ou localiza suas dependências: acoplamento

87

Injeção de Dependência — por meio de Construtor Dependência do componente é disponibilizada através

de seu(s) construtor(es); O argumento recebido será sua dependência.

88

Injeção de Dependência pelo Construtor com Spring public class ConstructorInjection { private Dependency dep; public ConstructorInjection(Dependency dep) { this.dep = dep; } }

Injeção de Dependência — por meio de método Setter O contêiner IoC injeta um componente de

dependência através de seu método set (JavaBean); O componente setter permite um conjunto de

dependências que o contêiner de inversão de controle pode gerenciar.

89

Injeção de Dependência através do método Setter com Spring public class SetterInjection { private Dependency dep; public void setMyDependency(Dependency dep) { this.dep = dep; } }

Injeção de Dependência — por meio de Interface [Fow06] Componente de dependência através de uma interface; A interface InjectFinder será definida por

qualquer um que fornecer a interface MovieFinder (no exemplo abaixo).

90

Injeção de Dependência através de Interface. Exemplo no arcabouço Avalon public interface InjectFinder { public void injectFinder(MovieFinder finder); } public class MovieLister implements InjectFinder { public void injectFinder(MovieFinder finder){ this.finder = finder; }

Injeção de Dependência — por meio de Interface Exemplo:

Classe de Teste no Avalon: configura os componentes e os injetores.

91

public class Tester { private Container container; private void configureContainer(){ container = new Container(); registerComponents(); registerInjectors(); container.start(); } }

Injeção de Dependência — por meio de Interface É preciso registrar os injetores que irão injetar os

componentes dependentes; Cada interface de injeção precisa de algum código para

injetar o objeto dependente; No código abaixo, registram-se os objetos injetores no

contêiner:

92

private void registerInjectors(){ container.registerInjector(InjectFinder.class, container.lookup(“MovieFinder”)); }

Injeção versus Procura O tipo de IoC é definido pelo contêiner adotado. Com Dependency Pull, é necessário:

registrar dependências; obter referências das dependências; interagir com as dependências obtidas.

Utilizando CDL, é preciso: que as classes implementem uma interface específica; e procure por todas dependências manualmente.

Com Injeção de Dependência, as classes precisam: permitir que as dependências sejam injetadas por meio

de construtores, métodos setters ou interfaces.

93

Inversão de Controle e Padrão Reactor Reactor: Padrão de Arquitetura [POSA 2]; Conhecido também como

Dispatcher, Notifier

Contexto: Aplicação orientada a eventos que processa as

informações de forma síncrona e serial.

Problema: aplicações devem: atender muitas requisições simultaneamente, demultiplexar e despachar as indicações de eventos às

respectivas implementações de serviço.

94

Inversão de Controle e Padrão Reactor Define uma interface que permite que aplicações:

registrem ou removam tratadores de eventos; sejam executadas no laço de eventos da aplicação.

Reactor utiliza um demultiplexador síncrono de evento para aguardar pela indicação de eventos que se originam de uma ou mais fontes.

Quando ocorre um evento: o demultiplexador síncrono de evento notifica o Reactor; o Reactor aciona o tratador associado, para realização do

serviço solicitado. O Reactor inverte o fluxo de controle, pois é

responsabilidade dele (e não da aplicação) em disparar os tratadores concretos para cada tipo de evento.

95

Desvantagens na Inversão de Controle Dificuldade na integração de arcabouços:

quando dois ou mais frameworks chamam simultaneamente o código da aplicação, cada qual pressupondo seu próprio fluxo de controle;

Dificuldade na depuração do código e

compreensão do fluxo: o controle é alternado entre o código da aplicação e o

código do frameworks.

96

Injeção de Dependências (Inversão de Controle) Um dos benefícios de usar interface

Em vez de

Use

Injeção de Dependências (Inversão de Controle) Se A depende de InterB, fica fácil testar ou media A usando uma

implementação/simulação de B para testes

Interfaces devem ser pequenas

Um objeto pode implementar várias interfaces

Facilita a evolução (interfaces grandes publicam um contrato grande que não pode ser revogado.

Planeje interfaces em todos os objetos Principalmente nos que oferecem serviços, singleton, etc..

Exemplo: controle convencional Linha 9: dependência fortemente acoplada

Difícil de testar objeto sem testar dependência

99

A dependência

100

Diminuindo o acoplamento Melhor forma de eliminar o acoplamento é usar interfaces

Implementação é dependente da interface

Cliente depende da interface, não mais da implementação

101

Solução Em vez do programador buscar ou criar sua própria

certificação, ela é atribuída a ele Para isto, deve haver método para criar a associação

102

Inversão de Controle

103

Padrões GRASP Básicos

Creator

Information Expert

High Cohesion

Low Coupling

Controller

Avançados

Polymorphism

Pure Fabrication

Indirection

Protected Variants

104

Protected Variants Problema:

Como projetar objetos, subsistemas e sistemas para que as variações ou instabilidades nesses elementos não tenha um impacto indesejável nos outros elementos?

Solução: Identificar pontos de variação ou instabilidades potenciais

Atribuir responsabilidades para criar uma interface estável em volta desses pontos.

Encapsulamento, interfaces, polimorfismo, indireção e padrões: máquinas virtuais e brokers são motivados por este princípio

Evite enviar mensagens a objetos muito distantes

Aspectos Adicionais

Aspectos: separação de interesses

A separação de interesses é objetivo essencial do processo de decomposição da solução de um problema Decomposição deve continuar até que cada unidade da solução

possa ser compreendida e construída

Cada unidade deve lidar com apenas um interesse

Separação de interesses eficiente promove o código de melhor qualidade Maior modularidade

Facilita atribuição de responsabilidades entre módulos

Promove o reuso

Facilita a evolução do software

Viabiliza a análise do problema dentro de domínios específicos

107

Tipos de interesse Usando linguagem OO, pode-se representar de forma

eficiente e modular as classes e procedimentos

Outros interesses são implementados como partes de classes e partes ou composição de procedimentos

108

Scattering e tangling

109

Inclusão de nova funcionalidade Também sujeita a scattering e tangling

Funcionalidade espalhada por várias classes (funcionalidade consiste de métodos contidos em várias classes)

Funcionalidades misturadas com outros recursos (não é representado por uma entidade separada)

110

Como reduzir tangling e scattering Criar subclasse que implemente

recursos, sobreponha métodos, etc.

Problema: classes cliente têm que ser alteradas para que saibam como criar a nova subclasse:

VeiculoCarga v =

// new VeiculoCarga();

new VeiculoCarga2();

Design patterns como factory method resolveriam o problema

VeiculoCarga v =

VeiculoCarga.create();

mas sua interface precisaria ser planejada antes.

111