Aula 09 - Padrões GRASP básicos

Prévia do material em texto

Padrões de projeto de software
Aula 9: Padrões GRASP básicos
Apresentação
Nesta aula, veri�caremos três padrões de projeto do tipo General Responsibility and Assignment Software Patterns
(GRASP): Information Expert (em português, especialista na informação), Creator (criador) e Low Coupling (acoplamento
fraco).
O GRASP é composto de nove padrões amplamente aplicados de forma intuitiva pelos projetistas de software por eles
estarem altamente relacionados ao bom senso da concepção de objetos. Os três abordados nesta aula, portanto,
descrevem os princípios fundamentais da atribuição de responsabilidades a objetos.
Objetivos
Descrever as características do Information Expert;
Esclarecer a natureza do Creator;
Classi�car as qualidades do Low Coupling.
Primeiras palavras
Os padrões Information Expert, Creator e Low Coupling foram desenvolvidos para explorar princípios da teoria de orientação a
objetos. O principal objetivo de um padrão de design é guiar o desenvolvedor na construção de componentes robustos,
extensíveis e reutilizáveis.
Para conseguir isso, ele endossa a luta contra os riscos presentes nas atividades de desenvolvimento de software orientados a
objetos.
 Autor: TippaPatt (Fonte: Shutterstock).
Information Expert
Os padrões GRASP são muito úteis na construção de três tipos de diagrama:
1
De classes;
2
De sequência;
3
De colaboração.
>
Padrões GRASP
Padrões básicos Padrões avançados
Information Expert Polymorphism
Creator Pure Fabrication
High Cohesion Indirection
Low Coupling Protected Variations
Controller
As responsabilidades de um objeto estão relacionadas às obrigações que ele tem quanto a seu comportamento.
Exemplo
Fazer um cálculo;
criar um objeto; iniciar ações, controlar e coordenar ações em outros objetos; e responsabilidade de conhecer alguma coisa, como
objetos relacionados a ele, dados privados e encapsulados e dados e/ou atributos que podem ser derivados ou calculados.
As responsabilidades da classe não devem ser confundidas com os métodos dela, que são construídos para satisfazer às
responsabilidades, as quais, por sua vez, são implementadas usando um ou vários métodos para realizar alguma função útil no
sistema.
1. Objetivo
A ideia principal deste padrão é atribuir uma responsabilidade para a classe que tem a informação necessária para satisfazê-la.
Há uma grande complexidade nas especi�cações dos produtos de software graças às responsabilidades das classes nos
sistemas orientados a objetos. Isso ocorre devido à grande quantidade de classes (centenas ou milhares) que deve receber tais
responsabilidades.
Em outras palavras, “os objetos fazem coisas relacionadas com as informações que possuem g”. (LARMAN, 2004)
2. Problema
Qual é o princípio geral para a atribuição de responsabilidades aos objetos?
Qual classe deve ter a responsabilidade de implementar um determinado método?
Durante o design, quando são de�nidas as interações entre objetos, fazemos escolhas sobre a atribuição de responsabilidades
às classes. Nesse momento, temos de escolher qual delas deverá implementar um método. Se boas escolhas forem feitas, os
sistemas se tornarão mais fáceis de compreender, manter e estender, além de haver a possibilidade de reutilização de
componentes em futuras aplicações.
O princípio deste padrão é atribuir essa responsabilidade à classe que possui a informação necessária para cumprir a tarefa.
Tal classe é considerada a especialista na informação (information expert).
3. Estrutura
Para implementar o padrão Information Expert, é necessário identi�car a que classes devemos atribuir determinadas
responsabilidades do sistema.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Exemplo
Um sistema de vendas possui as seguintes classes com os respectivos atributos: venda: código da venda, data da venda,
impostos e descontos; item de venda: código do item de produto vendido, quantidade e valor; e produto: código e descrição do
produto. Qual classe deve ter a responsabilidade de saber o total da venda? Ou seja, qual dessas classes deve armazenar o
atributo contendo a informação desse total? Nesse caso, a classe Venda deve assumir a responsabilidade, pois Item de venda
conhece apenas o valor de cada item vendido, mas não possui as informações sobre descontos ou impostos da venda. Ela deve
informar o somatório dos valores dos itens vendidos para a classe Venda calcular o valor total da venda com impostos e
descontos possíveis.
Os benefícios de Information Expert são os seguintes:
O padrão possui baixo acoplamento entre os objetos na medida em que mantém o encapsulamento de
informações dentro das classes que têm a responsabilidade de utilizá-las, pois os objetos usam a própria
informação para cumprir suas responsabilidades ou enviam mensagens para as outras classes colaboradoras a
�m de obter as informações de que necessitam;
Caso seja necessário que várias classes trabalhem em conjunto para cumprir uma determinada responsabilidade
devido à tarefa ser complexa, esse esforço �cará distribuído entre elas, favorecendo a alta coesão.
4. Dicas
Este princípio personi�ca objetos. Entidades como produtos ou até conceitos como vendas podem ter responsabilidades. A
atribuição de uma responsabilidade aos objetos muitas vezes não tem similaridade com aquela realizada no mundo real.
Exemplo
No mundo real, uma venda não calcula o próprio total. Isso é feito por uma pessoa.
5. Exemplo
Em um sistema de biblioteca, qual classe deve ter a responsabilidade de realizar o cálculo da devolução da cópia de um livro
que será emprestado?
Classes do modelo OO do sistema com seus respectivos atributos:
Reserva: Período e situação da reserva;
Atendente: Nome do atendente;
Leitor: Nome e tipo do leitor (aluno de graduação, pós-graduação);
Empréstimo: Data e situação do empréstimo;
Livro: Atributos de título, autor, nome do livro, ISBN, editora e ano;
Bibliotecária: Nome da bibliotecária;
Cópia do Livro: Situação do livro e status de liberação para empréstimo;
Devolução: Data da devolução do livro e prevista da devolução.
Atividade
Em um sistema de biblioteca, qual classe deve ter a responsabilidade de realizar o cálculo da devolução da cópia de um livro
que será emprestado?
Classes do modelo OO do sistema com seus respectivos atributos:
Reserva: Período e situação da reserva;
Atendente: Nome do atendente;
Leitor: Nome e tipo do leitor (aluno de graduação, pós-graduação);
Empréstimo: Data e situação do empréstimo;
Livro: Atributos de título, autor, nome do livro, ISBN, editora e ano;
Bibliotecária: Nome da bibliotecária;
Cópia do Livro: Situação do livro e status de liberação para empréstimo;
Devolução: Data da devolução do livro e prevista da devolução.
Padrões e princípios relacionados:
Low Coupling;
High Cohesion.
Creator
1. Objetivos
Identi�car as situações em que uma classe deve criar objetos de outra. O padrão Criador organiza a atribuição de
responsabilidades relacionadas com a criação de objetos de software.
Seu objetivo é de�nir um objeto criador que deva ser conectado ao objeto criado em qualquer momento da execução. A seleção
do objeto criador deve garantir um fraco acoplamento e uma alta coesão entre os objetos do sistema.
2. Problema
Qual classe deve ser responsável pela criação de uma nova instância de outra classe?
Em um sistema OO, a tarefa de criar objetos é umas das mais comuns. Dessa forma, a existência de um padrão que de�ne
regras para a atribuição de responsabilidades de criação é bastante útil. Os benefícios esperados para o sistema são:
Acoplamento fraco; Mais clareza; Encapsulamento; Reutilização;
Existem algumas condições para uma classe poder criar instâncias (objetos) em outra a �m de cumprir responsabilidades
relacionadas a uma classe ou um grupo delas. A classe criadora:
A de�nição de um princípio para a atribuição de responsabilidades de criação de objetos em um sistema orientado a objetos é
muito útil, pois o processo de criação de objetos é uma atividade bastante comum. Sendo bem realizada,ela possibilitará ao
sistema apresentar os benefícios descritos anteriormente (acoplamento fraco, mais clareza, encapsulamento e reutilização).
Contém ou agrega objetos
da outra classe;
Registra
instâncias da
outra;
Usa muitos
objetos da outra;
Possui dados que serão usados na iniciação e
repassados ao construtor da outra.
3. Estrutura
A seguir, descrevemos o procedimento de investigação necessário para descobrir qual classe seria a candidata a ser a classe
criadora de um objeto A em outra relacionada:
Verificamos se o objeto A faz parte de um relacionamento todo-parte. Nesse
caso, normalmente o todo é o responsável pela criação de A quando outro
objeto tem uma associação de um-para-muitos, em que A é o lado muitos;
Investigamos se o
objeto A está
associado ao objeto
de controle;
Vemos se alguma classe
tem dados necessários
para a iniciação do
objeto A.
5. Contraindicações
Em alguns casos, o processo de criação de objetos é uma tarefa complexa. Isso ocorre quando ele:
Outra situação em que não se deve usar o Creator é quando o processo de criação de objetos torna-se uma tarefa complexa,
exigindo otimizações para a melhoria do desempenho do sistema e, eventualmente, criando uma instância de uma família de
classes similares com base no valor de alguma propriedade externa – e assim por diante.
Nesses casos, é aconselhável delegar a criação para uma classe auxiliar chamada Fábrica (Factory Method) em vez de usar o
padrão Creator.
Exige o uso de instâncias recicladas por
motivos de desempenho;
Cria uma instância de uma família de classes similares com base no valor de
alguma propriedade externa.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
6. Exemplo
Vamos apresentar agora um exemplo das funções de um sistema de PDV: 
Pedido de um estabelecimento que registra as vendas;
Cada venda é de um ou mais itens de um ou mais tipos de produto, acontecendo em uma determinada data;
Um produto tem uma especi�cação, incluindo descrição, preço unitário e identi�cador;
O aplicativo também registra pagamentos (digamos, em dinheiro) associados a vendas;
O pagamento é para um determinado valor igual ou maior que o total da venda.
Nesse caso, quem deve ser o responsável pela criação de uma instância da classe ItemVenda? Utilizando os princípios do
padrão Creator, devemos procurar pela classe que agrega, contém ou usa os objetos ItemVenda.
Como a classe Venda contém (de fato, agrega) muitos objetos ItemVenda, ela, pelo padrão Creator, é uma boa candidata para
receber a responsabilidade de criar as instâncias de ItemVenda. Exemplo de codi�cação em Java:
class Sale {
List< SalesLineItem > salesLineItem
= new ArrayList< SalesLineItem >();
public void addLineItem(ProductSpeci�cation prodSpec,int quantity) {
salesLineItem.add(new SalesLineItem(prodSpec, quantity);
return salesLineItem;
}
}
Padrões e princípios relacionados:
Low Coupling;
Factory Method.
Atividade
2 - Em um sistema de Ponto de Venda (PDV), qual classe deve ter a responsabilidade de criar objetos de itens de venda?
Alternativas:
A classe Venda;
A classe Itens de Venda;
A classe Produtos.
Classes do modelo OO do sistema com seus respectivos atributos:
Classe Venda: Data da venda, Hora da venda;
Classe Itens da Venda: Quantidade vendida, código do produto vendido;
Classe Produtos: Código do item, descrição do item, preço.
Low Coupling
Esta classe é mais:
O acoplamento é uma medida sobre quão fortemente uma classe está
conectada a outras, tem conhecimento ou depende delas. Uma classe com
baixo (fraco) acoplamento não depende de muitas outras. Ao contrário, uma
com forte acoplamento apresenta alguns problemas.
Difícil de compreender; Complicada de utilizar; Influenciada por mudanças nas classes que se relacionam com ela.
1. Objetivos
Atribuir uma responsabilidade às classes do sistema de maneira que o acoplamento entre elas permaneça fraco.
Projetos de sistemas OO (orientados a objetos) devem seguir os princípios para que suas classes tenham alta reusabilidade,
baixa dependência e pouco impacto a mudanças. Low Coupling propõe a atribuição de responsabilidade de maneira que o
acoplamento permaneça fraco.
2. Problema
Como suportar baixa dependência, pouco impacto devido a mudanças e reuso constante? A solução proposta para este
problema pelo padrão Low Coupling é atribuir uma responsabilidade para que o acoplamento se mantenha fraco.
a) Formas de acoplamento
As formas de acoplamento são descritas a seguir:
O objeto tem um atributo que referencia outro de outra classe;
O objeto possui um método que referencia outro de outra classe;
A classe é subclasse de outra direta ou indiretamente.
b) Tipos de acoplamento
Os tipos de acoplamento entre classes de um sistema OO são os seguintes:
b.1) Acoplamento de dados
Nesse caso, a saída de um objeto A é entrada para outro B.
Exemplo
O objeto A passa objeto X para B. Portanto, X e B �cam acoplados.
class Servidor {
public void mensagem(MeuTipo ObjetoX) {
  
// código aqui
   
 ObjetoX.façaAlgo(Object dados);
// dados e ObjetoX estão acoplados (se interface de dados
// mudar, ObjetoX terá de mudar)
   
 // mais código
 
}
class Lampada {
public �nal 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 lampada = new Lampada();
lampada.setLampada(Lampada.ON);
lampada.setLampada(2);
Resposta: Decompor a operação em múltiplas operações primitivas.
class Lampada {
public void on() { // liga lampada }
public void off() { // desliga lampada }
public void pisca() { // pisca }
}
Lampada lampada = new Lampada();
lampada.on();
lampada.pisca();
b.2) Acoplamento de dados globais
Ocorre quando dois ou mais objetos compartilham uma estrutura de dados pública.
Atenção
Este é um tipo de acoplamento que esconde o compartilhamento. Por isso, ele deve ser evitado.
b.3) Acoplamento de dados internos
Ocorre quando um objeto altera dados locais de outro.
Atenção
Dados públicos, visibilidade de pacotes e uso do tipo de atributo protected em Java.
3. Dicas
Uma classe com acoplamento forte (ou alto) depende de muitas outras. Tal classe pode ser indesejável. Classes com
acoplamento forte têm os seguintes problemas:
As mudanças em classes relacionadas forçam mudanças locais;
Estas classes são difíceis de serem compreendidas isoladamente;
Estas classes são de difícil reutilização por causa da exigência da presença de outras das quais ela depende.
Eis benefícios do padrão Low Coupling:
Não é afetado por mudanças em outros componentes;
É simples de ser entendido isoladamente;
É conveniente para reutilização.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Atividade
3 - Em um sistema de biblioteca, qual classe deve ter a responsabilidade de realizar a devolução da cópia do livro e executar o
método devolver copia()?
Alternativas:
A classe Leitor;
A classe Livro;
A classe Empréstimo.
Classes do modelo OO do sistema com seus respectivos atributos:
Reserva: Período e situação da reserva;
Atendente: Nome do atendente;
Leitor: Nome do leitor;
Empréstimo: Data e situação do empréstimo;
Livro: Possui atributos de título, autor, nome do livro, ISBN, editora e ano;
Bibliotecária: Nome da bibliotecária;
Cópia do Livro: Situação do livro e status de liberação para empréstimo;
Devolução: Data da devolução do livro e a data prevista da devolução.
4 - Quais são as duas responsabilidades dos objetos de um sistema orientado a objetos? 
a) Conhecer e fazer alguma coisa.
b) Saber criar outros objetos e conhecer outras classes relacionadas.
c) Conhecer o estado dos outros objetos e dados privados.
d) Criar métodos e criar atributos.
e) Possuir as mesmas responsabilidades das classes
5 - Atribuir uma responsabilidade para a classe com a informação necessária para satisfazê-la é um objetivo de qual padrão
GRASP? 
a) Controller (controlador)
b) Low Coupling (acoplamento fraco)
c) Information Expert(especialista na informação)
d) High Cohesion (coesão alta)
e) Protected Variations (variações protegidas)
6 - No padrão Creator, todas as opções a seguir – exceto uma – são condições válidas para uma classe ter a responsabilidade de
criar instâncias (objetos) em outra a �m de cumprir responsabilidades relacionadas a uma classe ou um grupo de classes.
Diga qual das opções não apresenta essa condição. 
a) A classe criadora registra instâncias da outra classe.
b) A classe criadora possui dados que serão usados na iniciação e repassados ao construtor da outra classe.
c) A classe criadora registra instâncias da outros objetos.
d) A classe criadora usa muitos objetos da outra classe.
e) A classe criadora contém ou agrega objetos da outra classe.
7 - Medida de quão fortemente uma classe está conectada a outras classes, tem conhecimento delas ou depende delas. Estamos
nos referindo a:
a) Acoplamento
b) Herança
c) Polimorfismo
d) Responsabilidade
e) Dependência
Notas
Título modal 1
Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente
uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da
indústria tipográ�ca e de impressos.
Título modal 1
Lorem Ipsum é simplesmente uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente
uma simulação de texto da indústria tipográ�ca e de impressos. Lorem Ipsum é simplesmente uma simulação de texto da
indústria tipográ�ca e de impressos.
Referências
FRIEMAN, E. Use a cabeça! Padrões de projeto. 2. ed. Rio de Janeiro: Elsevier, 2007.
LARMAN, C. Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. 3. ed.
New Jersey: Prentice-Hall, 2004.
LEÃO, L. Padrões de projeto de software. Rio de Janeiro: SESES, 2018.
Próxima aula
Próxima aula
Apresentação dos padrões High Cohesion, Controller e Polymorphism.
Explore mais
Entendendo os conceitos dos padrões de projetos em Java.
javascript:void(0);