Aula 10 Padrões GRASP básicos e avançados

Prévia do material em texto

Padrões de projeto de software
Aula 10: Padrões GRASP básicos e avançados
Apresentação
Nesta aula, concluiremos o estudo dos padrões de projeto GRASP para sistemas orientados a objetos. Essa é uma área de
estudo que contribui fortemente para a construção de softwares com maior qualidade, segurança e e�ciência.
No entanto, à medida que surgiam novos dispositivos de hardware e novas linguagens de software, os padrões de projetos
também tiveram de evoluir para se adaptar a essas mudanças. Veri�caremos nesta aula as principais características de
High Cohesion, Controller e Polymorphism, enfatizando o que representa essa evolução.
Objetivos
Discutir as propriedades do padrão High Cohesion;
Expressar os aspectos do padrão Controller;
Descrever as características do padrão Polymorphism.
Primeiras palavras
Criado por Craig Largman, o termo General Responsibility and Assignment Software Patterns (GRASP) pode ser traduzido para
o português como padrões de software de atribuição geral de responsabilidades.
O signi�cado de cada letra da sigla GRASP será mostrado a seguir:
Geral: Resumo. É amplamente aplicável para uma variedade de situações;
Responsabilidade: Trata-se de obrigações e deveres. Os objetos de informação e computacional executam,
respectivamente, deveres de segurar informação e de computação;
Atribuição (de tarefa): Atribuir responsabilidade a um módulo. Capacidade de executar estrutura e métodos de
responsabilidade;
Software: Código de computador;
Padrões: Regularidades, modelos e abstração.
Nos projetos de software orientado a objetos, os padrões GRASP apresentados nesta aula enfatizam a importância de:
Coesão (High Cohesion);
Controle (Controller);
Polimor�smo (Polymorphism).
High Cohesion (coesão alta)
A coesão é uma medida de quão fortemente relacionadas e focadas são as responsabilidades de uma classe. Quando a
coesão entre as classes é baixa, muitas tarefas não relacionadas são realizadas, sobrecarregando-as de trabalho. Isso torna o
sistema mais difícil de compreender, reutilizar e até manter. Qualquer mudança pode desestabilizar o seu funcionamento.
Uma classe, portanto, não deve assumir responsabilidades distintas daquela para a qual foi criada. Se esse princípio não for
respeitado, há grande chance de haver problemas nos sistemas.
1
Exemplo
Di�culdades de manutenção e reuso. 
http://estacio.webaula.com.br/cursos/gon273/aula10.html
1. Objetivo
A ideia principal do padrão High Cohesion é controlar a complexidade das classes.
Um grave problema do projeto de objetos é manter a complexidade deles sobre controle. Caso contrário, os objetos serão
difíceis de manter, tornando-se inconvenientes para o reuso. Na prática, eles tendem a �car bastante sobrecarregados com as
responsabilidades de diferentes domínios; assim, para evitar esse problema, este padrão foi proposto.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Em termos de projeto, a coesão mede o quanto as responsabilidades
de um elemento estão fortemente relacionadas com os seus
objetivos.
2. Problema
Como manter a complexidade sob controle? As classes com coesão baixa possuem muitas responsabilidades ou fazem
muitas tarefas. Por isso, elas são:
Mais difíceis de entender;
Mais complicadas de manter e reusar;
Mais afetadas pelas mudanças do sistema.
A solução para esse problema é manter a coesão alta por meio da atribuição de uma responsabilidade à classe. Devemos
assegurar que as classes, porém, não �quem sobrecarregadas de trabalho. Em um bom projeto orientado a objeto, cada uma
delas não deve fazer muito trabalho, possuindo poucas responsabilidades.
3. Estrutura
Para implementar este padrão, é necessário selecionar poucas responsabilidades para as classes, pois uma classe com
coesão alta tem um número relativamente pequeno de métodos, possuindo funcionalidades relacionadas, além de não
executar muito trabalho.
Os benefícios do High Cohesion são os seguintes:
Aumento da simplicidade do código, tornando mais fácil sua compreensão;
Simpli�cação das manutenções no sistema;
Favorecimento da ocorrência de acoplamento fraco entre as classes;
Aumento do potencial de reutilização das classes do sistema devido ao pequeno número de funcionalidades daquelas
altamente relacionadas.
4. Dicas
O High Cohesion personi�ca objetos. Entidades como produtos ou até conceitos como vendas podem ter responsabilidades.
Em muitos casos, a atribuição delas aos objetos não possui similaridade com as mesmas responsabilidades realizadas no
mundo real.
Exemplo
No mundo real, uma venda não calcula o próprio total. Isso é feito por uma pessoa.
Alguns casos de coesão moderada trazem benefícios. Ex.: O padrão Facade
5. Exemplo
Neste exemplo, o objetivo da classe Aluno é obter dados do aluno e cadastrá-lo no banco de dados do sistema. A classe
mostra uma baixa coesão por estar assumindo várias responsabilidades de controle do banco de dados.
Aplicando o padrão High Cohesion, devemos transferir as responsabilidades de controle desse banco para outra classe,
deixando a classe Aluno apenas com duas responsabilidades:
Obter os dados do aluno;
Enviá-los para armazenamento no banco de dados do sistema.
Padrões e princípios relacionados: Facade.
Controller (controle)
O controle dos eventos de um sistema deve ser uma prioridade dos
desenvolvedores de software porque aumenta as possibilidades de
reutilização de código e do uso de interfaces plugáveis.
1. Objetivo
O Controller é responsável por tratar os eventos de um sistema em uma única classe que o representa inteiramente ou
somente um cenário de caso de uso no qual ocorram eles ocorram.
2. Problema
Quem deve ser o responsável por lidar com um evento do sistema de entrada? Gerado por um ator externo, ele está associado
às operações do sistema em resposta aos eventos que também são dele. Isso funciona da mesma forma com as mensagens
e os métodos relacionados.
Exemplo
Quando um escritor, ao usar um processador de texto, pressiona o botão veri�cação ortográ�ca, ele está gerando um evento do
sistema ao indicar a função executar uma veri�cação ortográ�ca.
Um Controller é um objeto de interface responsável por receber ou manipular um evento do sistema. Ele de�ne o método para a
operação dele e deve, por caso de uso, ser utilizado se houver excesso de responsabilidades atribuídas a uma mesma classe
para obter baixa coesão. Nesse caso, a classe que receber a responsabilidade de tratar dos eventos que ocorrerem em caso de
uso deve se concentrar apenas naqueles do seu contexto.
Também há a possibilidade de uma classe ser utilizada em mais de um caso de uso.
Exemplo
Os casos de uso Criar Usuário e Remover Usuário podem utilizar a mesma classe controladora ManterUsuários para consolidar
todas as responsabilidades.
O Controller sabe como interpretar as ações das interfaces do usuário e conectá-las aos comportamentos em seu sistema.
Este padrão separa as interfaces do usuário dos objetos de negócios, permitindo que ambos mudem de maneira independente
3. Regras
Deve-se atribuir a responsabilidade de receber ou manipular uma mensagem de evento do sistema para uma classe que se
enquadra em uma das seguintes opções:
A classe representa o sistema, o dispositivo ou o subsistema geral (controlador de fachada);
A classe representa um cenário de caso de uso no qual o evento do sistema ocorre, sendo geralmente
chamado de < UseCaseName > Manipulador, < UseCaseName > Coordenadorr ou < Use-CaseName > Sessão
(caso de uso ou controlador de sessão);
A mesma classe de controlador é usada para todos os eventos do sistema no mesmo cenário de caso de uso
Comentário
Note que as classes window, applet, widget, view e document não estão nessa lista. Elas, a�nal, não devem cumprir as tarefas
associadas aos eventos do sistema, pois, ao recebê-los, normalmente os delegam a um controlador.
4. Dicas
Em um sistema de tratamento de mensagens, cada uma delas pode ser representada e tratada separadamente por um objeto
Command. Escolher um objeto que representa todoo sistema ou toda a organização para ser um controlador é um tipo de
Facade.
Fonte: (GAMMA et al., 1994)
5. Contraindicações
Há o risco de os controladores �carem inchados. Isso ocorre quando uma classe tem coesão baixa, falta de foco e muitas
responsabilidades diversas.
Os sintomas de inchaço incluem:
Uma única classe controladora recebe todos os eventos – e há muitos deles – de sistema. Às vezes, isso acontece
quando é escolhido um controlador de fachada;
O próprio controlador executa muitas das tarefas obrigatórias em resposta aos eventos do sistema. Isso normalmente
envolve uma violação dos padrões Information Expert e High Cohesion;
Um controlador tem muitos atributos e mantém informações signi�cativas sobre o sistema ou o domínio (que devem ser
distribuídas para outros objetos) ou duplica as informações presentes em algum outro lugar.
As soluções para evitar um controlador inchado no sistema são as seguintes:
Acrescentar mais controladores: o sistema não precisa ter somente um;
Usar controladores de caso de uso;
Projetar o controlador de forma que ele delegue o atendimento da responsabilidade de cada operação de sistema a
outros objetos.
6. Exemplo
Este exemplo assume a responsabilidade de controlar os eventos de um sistema de ponto de venda. A classe instancia objetos
para controlar novas vendas, registrar pagamentos, exibir o total delas e processar novos pagamentos.
Padrões e princípios relacionados:
Command;
Facade.
Polymorphism (polimor�smo)
O padrão Polymorphism expõe um princípio fundamental no projeto da
organização de um sistema para tratar variações de comportamento em
componentes semelhantes.
Dessa forma, um projeto baseado na atribuição de responsabilidades pode ser facilmente estendido para tratar novas
situações com métodos polimór�cos que serão implementados e estendidos de acordo com o comportamento desejado. As
subclasses de uma superclasse são, portanto, capazes de invocar métodos que se comportam de maneira diferente para cada
classe derivada.
1. Objetivos
As responsabilidades devem ser atribuídas a abstrações, e não a objetos concretos, permitindo que eles possam variar
conforme haja necessidade.
2. Problema
Como tratar alternativas com base no tipo da classe?
Como criar componentes de software que possam ser facilmente conectáveis?
O uso de estruturas de controle, como os comandos Se-Então (If-Then, em inglês) aninhados ou o Switch-Case para selecionar
alternativas de comportamento do sistema em função do tipo de classe, pode di�cultar a manutenção dele.
3. Solução
A solução para esses problemas passa pela criação de classes de baixa coesão e alto acoplamento (classes puras).
4. Benefícios
Facilidade de manutenção do código-fonte do sistema;
Simpli�cação da inserção de novos tipos de comportamentos para as classes.
5. Contraindicações
Quando não há uma previsão da ocorrência futura de variações nas responsabilidades da classe, não é necessário utilizar o
padrão Polymorphism. Se houver indícios de que o ponto de variação criado é motivado por uma variabilidade imediata ou
muito provável, então o esforço da adição da �exibilidade por intermédio do polimor�smo será justi�cável.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Sempre será necessário fazer uma avaliação crítica para não haver
dispêndio de recursos em pontos de variação que, na verdade, são
improváveis e nunca surgirão realmente.
6. Exemplo
Apresentaremos um exemplo do uso do padrão Polymorphism em um sistema de pagamento. Considere uma classe
Pagamento com os atributos Valor, Tipo_Pagto_Dinheiro, Tipo_Pagto_Cartao e Tipo_Pagto_Cheque.
Nesse modelo, todas as classes que precisarem obter o tipo do pagamento irão implementar uma condição (Se-Então) com
base nos atributos desse tipo. Para criar uma operação polimór�ca, devemos gerar:
Uma interface Pagamento com o atributo Valor;
Um método Autoriza;
Três classes que implementam esta interface: PagamentoDinheiro, PagamentoCartão e PagamentoCheque.
Cada classe fará a implementação própria da operação Autoriza a �m de que os demais utilizadores não tenham mais de se
preocupar com a regra para obtenção do tipo de pagamento. Um benefício dessa abordagem é que, caso seja necessário
adicionar um quarto tipo (PagamentoCartaoDebito), o impacto seria menor para as classes dependentes, já que a operação
polimór�ca é a mesma (Autoriza).
Padrões e princípios relacionados
Adapter;
Command;
Composite;
State;
Strategy.
Atividade
1. O que representa a medida do quão fortemente relacionadas e focadas são as responsabilidades de uma classe?
a) A integridade
b) O controle
c) A herança
d) A coesão
e) O polimorfismo
2. Quais problemas ocorrem quando as classes de um sistema orientado a objetos apresentam coesão fraca?
a) O sistema fica mais difícil de compreender, manter e reusar.
b) Queda de desempenho na execução do sistema.
c) Ocorrência de erros e cancelamentos na execução do sistema.
d) Dificuldade de usar o sistema devido a problemas de usabilidade.
e) Todas as opções são verdadeiras.
3. São benefícios da alta coesão das classes de um sistema OO todas as opções seguintes, exceto:
a)  Aumento da simplicidade do código, tornando mais fácil sua compreensão.
b) Aumento do potencial de reutilização das classes do sistema devido ao pequeno número de funcionalidades das classes altamente
relacionadas.
c) O acoplamento fraco entre as classes é favorecido.
d) Aumento da complexidade da comunicação entre as classes.
e) Aumento da facilidade de manutenibilidade do sistema.
4. Que padrão trata do problema de atribuição de responsabilidade a uma classe para lidar com um evento do sistema de
entrada?
a) O Padrão Controller
b) O padrão Facade
c) O Padrão Command
d) O Padrão State
e) O Padrão High Cohesion
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
As responsabilidades devem ser atribuídas a abstrações, e não a objetos concretos, permitindo que eles possam variar conforme
haja necessidade. Esta frase é aplicável a qual padrão GRASP?
a) O Padrão Controller
b) O padrão Polymorphism
c) O Padrão Information expert
d) O Padrão Low coupling
e) O Padrão High Cohesion
Notas
Coesão1
O conceito de coesão está vinculado ao princípio da responsabilidade única, que foi introduzido por Robert C. Martin no início
dos anos 2000. Há nele a ideia de que uma classe deve ter uma única responsabilidade para realizá-la de maneira satisfatória.
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
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design patterns: elements of reusable object-oriented software. New York:
Addison-Wesley Professional, 1994.
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
Explore mais
Padrões de projeto: Design Patterns. .
javascript:void(0);