Padrões GRASP

Prévia do material em texto

GRASP - Padrões para Atribuições de Responsabilidades 
 
 
Conceitos 
 
 O que são Padrões? 
 Princípios, estilos e regras de programação, codificados em um formato estruturado, 
descrevendo problema/solução 
 Um Padrão é um par nomeado problema/solução, que pode ser utilizado em novos 
contextos, com conselhos sobre como utilizá-lo em novas situações. 
 Uma linguagem de padrões agrega um conjunto de padrões relacionados para um 
contexto em particular . 
 
 Motivação 
Más escolhas de atribuição de responsabilidades geram sistemas e componentes frágeis e de 
difícil manutenção, extensão e reutilização. 
A qualidade de um projeto orientado a objetos está fortemente relacionada com a 
distribuição de responsabilidades. 
 
 Quando utilizar? 
Padrões são utilizados durante a criação dos diagramas de interação. 
A principal característica da atribuição de responsabilidades está em não sobrecarregar os 
objeto com responsabilidades que poderiam ser delegadas – O objeto só deve fazer o que 
está relacionado com a sua abstração. Para isso, delega as demais atribuições para quem 
está mais apto a fazer. 
 
 O que não são Padrões? 
Novos princípios da Engenharia de Software. Ao contrário, padrões tentam codificar o 
conhecimento, idiomas e princípios existentes 
 
 Responsabilidades e Métodos 
 
 Responsabilidade - contrato ou obrigação de uma classe 
 Métodos - utilizados para implementar Responsabilidades 
 
 
 Tipos de Responsabilidades: 
 
 Fazer – ele próprio; iniciar ações em outros objetos; controlar atividades em outros 
objetos 
 Conhecer – dados privados; objetos relacionados; coisas que pode calcular e derivar. 
São dedutíveis do modelo Conceitual 
 
 
 O que são os Padrões GRASP ? 
 
 Princípios fundamentais de atribuição de responsabilidades a objetos. No contexto 
de projeto orientado a objetos foi criada uma linguagem de padrões conhecida como 
GRASP (Larman, G.; 2007) – GRASP – General Responsability Assignment Software 
Patterns 
 Os padrões GRASP descrevem os princípios fundamentais para a atribuição de 
responsabilidades em projetos OO 
 
 
 
 
 Principais Padrões GASP que abordam questões mais comuns: 
 
 Especialista 
 
 Criador 
 
 Coesão Alta 
 
 Controlador 
 
 Acoplamento Fraco 
 
 Polimorfismo 
 
 Indireção 
 
 Invensão Pura 
 
 
1- Padrão Especialista 
 
Problema: Em um sistema com centenas de classes, como selecionamos quais 
responsabilidades devem estar em quais classes? 
 
Solução: atribui a responsabilidade ao especialista da informação. O especialista é a classe 
que tem a informação necessária para satisfazer a responsabilidade. 
 
Exemplo: A partir do diagrama de classe da figura 1 – Qual a classe que deve conhecer o 
total de venda? 
 
 É necessário conhecer todas as instâncias de ítem de venda e a soma de seus 
subtotais 
 
 
 
 Figura 1 
 
 
A Classe VENDA é a especialista para o Total da Venda 
 
 Que informações são necessárias para determinar o total de um ítem de venda? 
 ItemVenda.Quantidade 
 Produto.Preço 
 ÍtemVenda conhece sua quantidade e seus Produtos associados 
 
Ítem Venda é o especialista para determinar o subtotal 
 
 ÍtemVenda deve conhecer o preço do Produto. 
 
 Produto é o especialista informar o seu preço 
 
 
 Conclusão 
 
 A satisfação de uma responsabilidade requer informações espalhadas por diferentes 
classes. 
 Desta forma existem vários especialistas parciais que colaboram com a tarefa. 
 Favorece ao acoplamento fraco uma vez que os objetos usam suas próprias informações 
para executarem as tarefas. 
 As classes ficam “leves” gerando alta coesão. 
 Distribui o comportamento uniformemente entre as classes do sistema, aumentando a 
coesão das mesmas. 
 
 
 
2- Padrão Criador 
 
Problema: Quem deveria ser responsável pela criação de uma nova instância de uma 
classe? 
 
Solução: atribua à classe B a responsabilidade de criar instâncias da classe A se: 
 B agrega objetos de A 
 B contém objetos de A 
 B registra instâncias de objetos A 
 B usa de maneira muito próxima objetos A 
 B tem os dados de inicialização que serão passados para o objeto A, quando de sua 
criação ( B é um especialista com a relação a criação de A) 
 
Exemplo: A partir do diagrama de classe da figura 1. 
 
a) Quem deveria ser responsável pela criação de um ItemVenda referente a uma 
Venda? 
 
 A Classe VENDA é a responsável por criar os ItemVenda 
 
 
b) Quem deveria ser responsável pela criação de uma Venda ? 
 
 A Classe VENDEDOR OU a classe LOJA 
 
a) Quem deveria ser responsável pela criação de uma Parcela ? 
 
 A Classe Venda 
 Conclusão 
 O objetivo do padrão é encontrar um Criador que necessita ser conectado ao objeto 
criado. 
 O criador pode ser encontrado procurando a classe que tem os dados de inicialização 
que serão passados durante a criação. 
 Não aumenta o acoplamento, pois a visibilidade entre as classes envolvidas já existia. 
 
 
 
3- Padrão Acoplamento Fraco 
 
Problema: Como suportar uma dependência baixa e aumentar a reutilização? 
 
 Modificações em uma classe forçam modificações em outras classes. 
 Dificuldade de compreensão de uma classe isoladamente. 
 Dificuldade de reutilização por excesso de dependência entre classes. 
 
Tipos de acoplamento entre as classes: 
 A classe A é subclasse da classe B. 
 A classe A tem um atributo do tipo da classe B. 
 A classe A tem um método que referencia a classe B através de parâmetro, variável 
local. ou retorno de mensagem. 
 
Solução: atribuir a responsabilidade de maneira que o acoplamento permaneça fraco. 
 
 
Conclusão: 
 Corresponde a um padrão de avaliação. 
 Não há uma medida que determine quanto um acoplamento é muito forte. 
 O importante é avaliar o grau atual de acoplamento e julgar se seu aumento trará 
problemas. 
 Se o acoplamento fraco é aplicado em excesso, leva a um projeto fraco, pois conduz a 
poucos objetos ativos, se coesão, inchados e complexos, que efetuam todo o trabalho. 
acoplamento fraco permite entendimento isolado, maior reutilização. 
 
 
 
 
4- Padrão Alta Coesão 
 
Problema: Como manter a complexidade sob controle? 
 
 As classes são difíceis de compreender. 
 As classes são difíceis de reutilizar. 
 As classes são difíceis de manter. 
 As classes são frágeis, sendo afetadas por praticamente todas as modificações. 
 
Solução: atribuir uma responsabilidade de modo que a coesão permaneça alta. Uma classe 
com Alta Coesão é uma classe com responsabilidades altamente relacionadas e que não 
executa um formidável volume de trabalho. 
 
Uma classe com Baixa Coesão é uma classe que faz muitas coisas não relacionadas ou 
executa demasiado trabalho. Gera dificuldades para manter, reutilizar, compreender, e 
constantemente afetadas por mudanças. 
 
Conclusão 
 
 Corresponde a um padrão de avaliação. 
 Como regra uma classe com coesão alta tem um número relativamente pequeno de 
métodos, com funcionalidades relacionadas e não executa muito trabalho. 
 Benefícios: 
 Clareza e facilidade de compreensão do projeto. 
 Simplificação das atividades de manutenção. 
 Favorecimento indireto do baixo acoplamento. 
 Facilidade de reutilização, graças à classe ser muito específica. 
 
 
5- Padrão Controlador 
 
Problema: Quem deveria ser responsável por tratar um evento de sistema? 
– Os eventos de sistema estão associados às mensagens de sistema, quesão geradas a 
partir dos passos dos casos de uso. 
 
O que é um Controlador? 
Um objeto de interface responsável por tratar um evento do sistema. Um controlador define 
um método para a operação do sistema. 
 
Solução: atribui a responsabilidade do tratamento de uma mensagem de um evento do 
sistema a uma classe que representa uma das escolhas: 
 
 Controlador Fachada - representa o sistema todo ou todo o negócio ou organização. 
Adequado quando existem poucos eventos do sistema. 
 
 Controlador de Papel - representa algo no mundo real que é ativo ( por exemplo o 
papel de uma pessoa) e que pode estar envolvido na tarefa. 
 
 Controlador de Caso de Uso - representa um tratador artificial de todos os eventos de 
sistema de um caso de uso. Adequado quando existem muitos eventos do sistema em 
diferentes processos. 
 
Observações: 
 Deve ser usada a mesma classe controladora para todos os eventos do sistema de um 
mesmo caso de uso. 
 Classes como interfaces externas ( janelas, applet, etc.) não devem executar eventos do 
sistema. Apenas são responsáveis por receberem estes eventos e delegarem a um 
controlador. 
 Operações do sistema que refletem processos de negócio devem ser tratadas na camada 
de objetos de domínio. 
 Os controladores devem somente coordenar a tarefa, delegando a sua execução para os 
outros objetos do sistema. 
 
 
 
6- Padrão Polimorfismo 
 
Problema: Se um programa for projetado com lógica condicional da estrutura if-then-else, 
sempre que surgir uma nova variação, uma alteração será necessária muitas vezes em um 
ponto central da solução. 
 
Solução: Aplicação de estruturas polimórficas para tratar novas variações. 
 
Vantagens: As variações são fáceis de adicionar sem necessidade de alterações no código 
existente e sem afetar os clientes. 
 
Exemplo(figura 2) : Empresa possui método diferenciado para cálculo do salário dos seus 
funcionários. Os funcionários administrativos possuem um salário fixo, já o salário dos 
vendedores depende das vendas realizadas. 
 
 
 
 Figura 2 
 
 
Padrão Indireção 
 
Problema: Como atribuir a responsabilidade para evitar o acoplamento direto entre dois ou 
mais objetos. Caso uma classe seja acoplada a serviços, será impossível reutilizar esses 
serviços. 
 
Solução: Atribui a responsabilidade a um objeto intermediário para ser o mediador 
evitando que os objetos sejam diretamente acoplados. 
 
Exemplo: (figura 3) 
 
 
:
 
Figura 3 
 
8- Invensão Pura 
 
Problema: Qual o objeto deve ter a responsabilidade quando não se quer violar a Coesão 
Alta e o Acoplamento Baixo, mas as soluções do padrão Especialista não são apropriadas. 
 
Solução: Atribui um conjunto de responsabilidade altamente coeso a uma classe artificial 
que não seja do domínio do problema. 
 
Exemplo: Em uma necessidade de salvar instâncias de uma classe Venda em um banco de 
dados relacional. Pelo padrão Especialista, as operações de salvamento deveriam ser de 
responsabilidade da classe Venda. 
 
Implicações: A tarefa exige um número grande de operações e não relacionadas ao 
conceito de venda, o que diminuiria a sua Coesão. Ainda salvar objetos é uma tarefa 
genérica que poderia ser compartilhada com outras classes. 
 
Solução para o Exemplo: Criar uma nova classe que seja responsável unicamente por 
salvar objetos em algum tipo de armazenamento persistente. 
 
Benefícios: Remove as características não coesas das classes do domínio de negócio e cria 
classes muito coesas com essas características específicas.