Aula 17 - GRASP

Prévia do material em texto

GRASP 
Professor: Baldoino Fonseca 
 
Agradecimento dos Slides: Hyggo Almeida 
Instituto de Computação – UFAL 
O que vimos na última aula? 
n  Introdução a padrões 
¨  O que são? 
¨  Por que utilizá-los? 
n  Padrões GRASP 
¨  O que são? 
¨  Quais serão apresentados na disciplina? 
GRASP 2 
Instituto de Computação – UFAL 
O que veremos hoje? 
n  Padrões GRASP 
¨  Expert 
¨  Creator 
¨  Low Coupling 
¨  High Cohesion 
GRASP 3 
Instituto de Computação – UFAL 
Expert 
n  Problema 
¨  Qual o principio geral para associar 
responsabilidades a objetos? 
¨  Centenas ou milhares de classes 
¨  Com milhares de responsabilidades que precisam ser 
implementadas 
¨  As decisões influenciarão fortemente a qualidade do 
design 
n  Solução 
¨  Atribua a responsabilidade a quem possui a 
informação 
GRASP 4 
Instituto de Computação – UFAL 
Expert - Exemplo 
n  Exemplo: Terminal Ponto de Venda (TPDV) 
¨  Responsabilidade: 
n  Quem deveria ser responsável pelo conhecimento do total 
de uma venda? 
¨  Qual a classe de objetos que contém as informações 
necessárias para determinar o total? 
GRASP 5 
Instituto de Computação – UFAL 
Expert 
n  Solução: Padrão Expert 
¨  A classe que possui a informação necessária para determinar o 
total 
GRASP 6 
Venda 
data 
ItemVenda 
quantidade 
EspecificaçãoProduto 
descrição 
preço 
* 
* 
descrito por 
Qual a informação 
necessária para saber 
o total da venda??? 
Precisamos de 
todos os itens! 
Adiciona-se 
método 
total() 
Instituto de Computação – UFAL 
Expert 
GRASP 7 
Venda 
data 
ItemVenda 
quantidade 
EspecificaçãoProduto 
descrição 
preço 
* 
* 
descrito por 
total() 
Algoritmo para o método total() 
 
Para cada ItemVenda... 
 Recupera a EspecificaçãoProduto 
 Recupera preço e quantidade do produto 
 Calcula subtotal 
 Soma ao total 
Fim-Para 
Retorna total 
Especialista 
sobre 
ItemVenda 
Quem é Especialista 
sobre 
EspecificaçãoProduto? 
Adiciona-se 
método subtotal() 
Instituto de Computação – UFAL 
Expert 
GRASP 8 
Venda 
data 
ItemVenda 
quantidade 
EspecificaçãoProduto 
descrição 
preço 
* 
* 
descrito por 
total() 
Algoritmo para o método total() 
 
Para cada ItemVenda... 
 Executa subtotal() 
 Soma ao total 
Fim-Para 
Retorna total 
subtotal() 
Algoritmo para o método subtotal() 
 
Recupera preço do produto 
Multiplica pela quantidade 
Retorna subtotal 
Instituto de Computação – UFAL 
Expert 
n  Simples demais!!! 
n  Imagine que fizéssemos como no primeiro 
algoritmo 
n  Vamos implementar o primeiro algoritmo em 
Java. 
GRASP 9 
exemplo.grasp.expert1
Instituto de Computação – UFAL 
Expert 
 
n  Novos Requisitos 
n  Um belo dia, o seu patrão lhe diz que o cálculo 
para cada item de venda foi alterado. 
¨  Quantidade > 100 
¨  Desconto de até 30% no valor do item de venda 
¨  Detalhe: depende do item de venda! 
n  Você acha esse cenário difícil de acontecer??? 
GRASP 10 
Instituto de Computação – UFAL 
Expert 
n  Consideração 
¨  A porcentagem de desconto é um atributo de 
EspecificaçãoProduto. 
n  Vamos modificar o código agora para fazer o 
cálculo de acordo com a alteração dos 
requisitos 
GRASP 11 
exemplo.grasp.expert2
Instituto de Computação – UFAL 
Solução sem expert 
n  E se fosse na solução onde o Expert foi bem aplicado??? 
n  Vamos implementar a solução Expert!!! 
GRASP 12 
exemplo.grasp.expert4
Instituto de Computação – UFAL 
Solução com Expert 
GRASP 13 
Instituto de Computação – UFAL 
Expert 
n  Conseqüências 
¨  Encapsulamento é mantido 
¨  Fraco acoplamento, facilidade de manutenção 
¨  Alta coesão – Objetos fazem tudo relacionado à sua 
própria informação 
GRASP 14 
Instituto de Computação – UFAL 
Expert 
n  Contra indicações 
¨  Quando o expert leva a problemas de coesão e 
acoplamento 
¨  Exemplo: 
n  Quem deve ser responsável por persistir a Venda no banco 
de dados? 
n  Segundo o expert: a própria venda 
n  Problemas: 
¨  Baixa coesão 
¨  Acoplamento com outro subsistema (SQL, JDBC) 
GRASP 15 
Instituto de Computação – UFAL 
Creator 
n  Problema 
¨  Quem deve ser responsável por criar uma nova 
instância de uma classe? 
¨  Criação de objetos é uma das tarefas mais comuns 
¨  Portanto, é bem útil ter um princípio que nos guie 
nessa tarefa 
GRASP 16 
Instituto de Computação – UFAL 
Creator 
n  Solução 
¨  Atribuir a uma classe a responsabilidade de criar a 
classe X se 
n  contém objetos de X 
n  usa bastante os objetos da classe X 
n  possui os dados de inicialização de X 
GRASP 17 
Instituto de Computação – UFAL 
Creator :: Exemplo 
n  Quem deve criar uma instância de ItemVenda 
n  Uma vez que Venda contém ItemVenda’s... 
n  Venda será a classe criadora de ItemVenda 
GRASP 18 
Venda 
data 
ItemVenda 
quantidade 
EspecificaçãoProduto 
descrição 
preço 
* 
* 
descrito por 
Instituto de Computação – UFAL 
GRASP 19 
Instituto de Computação – UFAL 
Discussão 
n  Em muitos casos, é bem natural usar o creator 
¨  Dados de inicialização … 
n  Contra indicações 
¨  Se a criação de um objeto for muito complexa, 
existem padrões de criação mais adequados 
n  Exemplo: 
¨  Abstract Factory, Builder, Factory Method, Prototype, 
Singleton 
¨  Estudaremos esses padrões em detalhes nas aulas de 
padrões de projeto 
GRASP 20 
Instituto de Computação – UFAL 
Low coupling 
n  Problema 
¨  Como minimizar dependências, minimizar o impacto 
de mudanças e maximizar o reúso??? 
¨  Coupling (Acoplamento) – medida de quão 
fortemente um elemento está 
n  Conectado a … 
n  Tem conhecimento de … 
n  Depende de … 
n  … outros elementos 
n  Solução 
¨  Atribuir responsabilidades visando minimizar o 
acoplamento 
GRASP 21 
Instituto de Computação – UFAL 
Low coupling 
n  Exemplo TPDV 
¨  Suponha a criação de um Pagamento associado à Venda 
¨  No mundo real, um TPDV “registra” um pagamento e portanto, 
segundo o padrão Creator, TPDV deveria criar Pagamento e 
repassá-lo a Venda! 
¨  Mas aí temos: 
n  TPDV sabe sobre pagamento (acoplamento: TPDV à Pagamento) 
n  TPDV sabe sobre Venda (acoplamento: TPDV à Venda) 
n  Venda está associada a pagamento (acoplamento: Venda à Pagamento) 
GRASP 22 
:TPDV p:Pagamento 
façaPagamento() 1:criar() 
:Venda 
2:façaPagamento(p) 
Instituto de Computação – UFAL 
Low coupling 
n  Mas podemos fazer assim: 
¨  Então... em nome do baixo acoplamento... ignoramos o 
Creator!!! 
¨  Agora temos acoplamento entre duas classes apenas 
n  TPDV sabe sobre Venda (acoplamento TPDVàVenda) 
n  Venda sabe sobre Pagamento (acomplamento VendaàPagamento) 
GRASP 23 
:TPDV 
p:Pagamento 
façaPagamento() 1:façaPagamento() :Venda 
1.1:criar() 
Instituto de Computação – UFAL 
Low coupling 
n  A maioria dos padrões visa o baixo acoplamento 
n  Conseqüências 
¨  Uma classe fracamente acoplada não é afetada (ou pouco 
afetada) por mudanças em outras classes 
¨  Simples de entender isoladamente 
¨  Reúso mais fácil 
GRASP 24 
Instituto de Computação – UFAL 
Low Coupling - Acoplamento 
n  Sempre existe um trade-off 
n  O exagero também é um problema 
GRASP 25 Alto acoplamento 
Instituto de Computação – UFAL 
Low Coupling - Acoplamento 
n  Lembrem-se 
¨  Um sistema OO é um sistema onde as tarefas são 
realizadas por um conjunto de objetos que cooperam 
¨  Portanto, algum grau de acoplamento é saudável 
GRASP 26 
Instituto de Computação – UFAL 
Low Coupling 
n  Discussões 
¨  Frequentemente não faz mal se acoplar a 
componentes altamente estáveis 
n  Por exemplo, java.util 
GRASP 27 
Instituto de Computação – UFAL 
Low coupling 
Tipos de acoplamento 
n  Acoplamento de dados 
¨  Situações 
n  Saída de um objeto é entrada de outro 
n  Uso de parâmetros para passar itens entre métodos 
¨  Ocorrência comum: 
n  Objeto a passa objeto x para objeto b 
n  Objeto x e b estão acoplados 
n  Umamudança na interface de x pode acarretar mudanças em b 
GRASP 28 
class Servidor { 
 public void mensagem(MeuTipo x) { 
 // código aqui 
 x.façaAlgo(Object dados); // dados e x estão acoplados 
 // (se interface de dados mudar x terá que mudar) 
 // mais código 
 } 
} 
Instituto de Computação – UFAL 
Low coupling 
Tipos de acoplamento 
n  Acoplamento de controle 
¨  Situação 
n  Passar flags de controle entre objetos a fim de controlar as etapas de 
processamento 
GRASP 29 
class Lampada { 
 public final static int ON = 0; 
 public void setLampada(int valor) { 
 if (valor == ON) { // liga lampada 
 } else if (valor == 1) { // desliga lampada 
 } else if (valor == 2) { // pisca } 
 } 
} 
Lampada lampapa = new Lampada(); 
lampada.setLampada(Lampada.ON); 
lampada.setLampada(2); 
Instituto de Computação – UFAL 
Low coupling 
Tipos de acoplamento 
n  Acoplamento de controle 
¨  Solução: decompor em operações primitivas 
¨  Outra ocorrência comum: 
n  Objeto a manda mensagem para objeto b 
n  b retorna informação de controle para a 
n  Exemplo: retorno de código de erro 
¨  Solução: utilize exceções!!! 
GRASP 30 
class Lampada { 
 public void on() { // liga lampada } 
 public void off() { // desliga lampada } 
 public void pisca() { // pisca } 
} 
Instituto de Computação – UFAL 
Low coupling 
Tipos de acoplamento 
n  Acoplamento de dados globais 
¨  Dois ou mais objetos compartilham estruturas de dados globais 
¨  É um acoplamento muito ruim pois está escondido 
n  Uma chamada de método pode mudar um valor global e o código não deixa isso 
aparente 
GRASP 31 
Instituto de Computação – UFAL 
Low coupling 
Tipos de acoplamento 
n  Acoplamento de dados internos 
¨  Um objeto altera os dados locais de um outro objeto 
¨  Ocorrência comum: 
n  Dados públicos, package ou mesmo protected em java 
¨  Use com cuidado! 
GRASP 32 
Instituto de Computação – UFAL 
High cohesion 
n  Coesão é a medida de quão fortemente relacionadas e focadas 
estão as responsabilidades de um elemento 
n  Problema 
¨  Como gerenciar a complexidade? 
n  Responsabilidades no lugar certo? 
n  Funcionalidades implementadas pelas classes corretas? 
 
n  Solução 
¨  Buscar uma alta coesão no projeto 
GRASP 33 
Instituto de Computação – UFAL 
High cohesion 
n  Mais uma vez... TPDV 
¨  De acordo com o Creator... 
n  TPDV deveria ter a responsabilidade de criar Pagamento 
¨  Suponha que isto ocorra várias vezes (outras classes) 
n  Imagine 50 responsabilidades 
¨  TPDV acumula responsabilidades não relacionadas a ele 
¨  Baixa coesão!!! 
GRASP 34 
:TPDV p:Pagamento 
façaPagamento() 1:criar() 
:Venda 2:façaPagamento(p) 
Instituto de Computação – UFAL 
High cohesion 
n  Mais uma vez... TPDV 
¨  Com a delegação de façaPagamento() 
n  TPDV não tem mais a responsabilidade de criar Pagamento 
¨  Mantém-se a coesão em TPDV!!! 
¨  Mesma solução de low coupling 
GRASP 35 
:TPDV 
p:Pagamento 
façaPagamento() 1:façaPagamento() :Venda 
1.1:criar() 
Instituto de Computação – UFAL 
High cohesion 
n  Conseqüências 
¨  Melhor claridade e facilidade de compreensão do projeto 
¨  Simplificação da manutenção 
¨  Freqüentemente causa baixo acoplamento 
GRASP 36 
Instituto de Computação – UFAL 
High cohesion 
Tipos de coesão Funcionais 
n  Da pior para a melhor 
¨  Muito baixa 
¨  Baixa 
¨  Moderada 
¨  Alta 
n  Existem outras classificações 
GRASP 37 
Instituto de Computação – UFAL 
Coesão Muito Baixa 
n  O elemento é responsável por muitas coisas em 
áreas diferentes 
n  Exemplo: 
¨  Classe 
n  Responsável pela interação entre o banco de dados e 
chamadas remotas 
¨  Duas coisas totalmente diferentes 
n  Banco de Dados 
n  Remote Procedure Call 
¨  Deveríamos ter duas famílias de classes, uma para 
cada preocupação 
GRASP 38 
Instituto de Computação – UFAL 
Coesão Baixa 
n  Elemento responsável por uma tarefa muito 
complexa mesmo que em uma mesma área 
n  Exemplo: 
¨  Classe 
n  Faz tudo que é necessário para interagir com banco de 
dados 
¨  Os métodos são relacionados 
¨  Mas são muitos métodos, muitos provavelmente de 
suporte 
¨  Seria melhor quebrar a classe em classes menores 
GRASP 39 
Instituto de Computação – UFAL 
Coesão Moderada 
n  Responsabilidades definidas em poucas áreas 
n  Responsabilidades não se relacionam umas 
com as outras 
n  Mas as responsabilidades se relacionam com o 
conceito do elemento 
n  Exemplo 
¨  Classe Empresa 
1.  Conhecer os funcionários 
2.  Conhecer as informações financeiras 
¨  1 e 2 não são relacionados entre si 
¨  Mas 1 e 2 são relacionados com Empresa 
GRASP 40 
Instituto de Computação – UFAL 
Alta Coesão 
n  Um elemento possui responsabilidades 
moderadas 
n  Colabora com outros elementos para realizar a 
sua tarefa 
n  Exemplo: 
¨  Classe 
n  Faz tudo que é necessário para interagir com banco de 
dados 
n  Mas interage com outros objetos para prover as 
funcionalidades 
GRASP 41 
Instituto de Computação – UFAL 
Dúvidas??? 
n  Padrões para atribuição de 
responsabilidades??? 
n  Para que servem??? 
n  Por que usar??? 
GRASP 42 
Instituto de Computação – UFAL 
O que vimos hoje? 
n  Padrões GRASP 
¨  Expert 
¨  Creator 
¨  Low Coupling 
¨  High Cohesion 
GRASP 43 
Instituto de Computação – UFAL 
Dúvidas? 
? 
GRASP 44