projeto orientado a objetos - inf.puc-rio.brivan/inf1013/apostila/padroesgrasp.pdfprojeto orientado...
TRANSCRIPT
Projeto Orientado a Projeto Orientado a ObjetosObjetos
Ivan Mathias FilhoToacy Cavalcante de Oliveira
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 2
Design Orientado a ObjetosDesign Orientado a Objetos
“Após a identificação dos requisitos e a criação do modelo de domínio, devemos adicionar os métodos às classes de software, e definir o fluxo de mensagens entre os objetos, para os requisitos sejam satisfeitos.”
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 3
Design Orientado a ObjetosDesign Orientado a Objetos
É considerado o cerne do desenvolvimento orientado a objetos.Tem por objetivo definir quais classes irão implementar determinadas tarefas, e como os objetos deverão interagir para que tarefas maiores sejam executadas.Em suma, envolve definir as responsabilidades de cada um dos objeto que compõe um sistema.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 4
O que são Responsabilidades?O que são Responsabilidades?
O termo responsabilidade define algumas características gerais dos objetos de software. Ele inclui três itens principais:
As ações que os objetos executam.O conhecimento encapsulado pelos objetos.As decisões tomadas pelos objetos que afetam os seus pares.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 5
O que são Responsabilidades?O que são Responsabilidades?
As responsabilidades estão relacionadas com as obrigações dos objetos expressas em termos dos seus comportamentos.As responsabilidades podem ser divididas em duas categorias:
FazerConhecer
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 6
O que são Responsabilidades?O que são Responsabilidades?
As responsabilidades que um objeto deve Fazerincluem:
Fazer algo por si, como criar um objeto ou executar algum cálculo.Iniciar ações em outros objetos. Controlar e coordenar atividades em outros objetos.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 7
O que são Responsabilidades?O que são Responsabilidades?
As responsabilidades que um objeto deve Conhecer incluem:
Conhecer os dados encapsulados (privados).Conhecer os objetos com os quais está relacionado.Conhecer as informações que podem ser derivadas ou calculadas.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 8
O que são Responsabilidades?O que são Responsabilidades?
A tradução das responsabilidades em classes e métodos é determinada pela granulação das responsabilidades:
Algumas delas, como prover acesso a uma base de dados relacional, podem envolver dezenas de classes e centenas de métodos, organizados em muitos subsistemasOutras, como criar um objeto que represente a venda de uma mercadoria, podem envolver uma ou duas classes e uns poucos métodos.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 9
Padrões de ResponsabilidadePadrões de Responsabilidade
“Na terminologia da Orientação a Objetos, um Padrão é a descrição nomeada de um problema e de uma solução, que pode ser aplicada em novos contextos.”
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 10
Padrões de ResponsabilidadePadrões de Responsabilidade
“É possível comunicar detalhadamente os princípios e as boas práticas que envolvem um bom design orientado a objetos, e aprender a aplicá-los metodicamente, de maneira que possamos remover muito da imprecisão e do empirismo que envolve o design orientado a objetos.”
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 11
Padrões de ResponsabilidadePadrões de Responsabilidade
Programadores e designers experientes possuem um repertório de princípios gerais e de soluções idiomáticas que os ajudam na construção de sistemas de software.Uma vez descritos e nomeados, os princípios e as soluções idiomáticas tornam-se soluções padronizadas que são reutilizadas por toda uma comunidade de desenvolvedores na solução de problemas recorrentes de design.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 12
Os Padrões GRASPOs Padrões GRASP
“Os padrões GRASP (General ResponsibilityAssignment Software Pattern) descrevem os princípios fundamentais envolvidos no design orientado a objetos e na atribuição de responsabilidade aos objetos de um sistema.”
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 13
Os Padrões GRASPOs Padrões GRASP
A seguir iremos apresentar os seguintes padrões GRASP:
Especialista (Information Expert)Criador (Creator)Baixo AcoplamentoAlta CoesãoControlador
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 14
Os Padrões GRASPOs Padrões GRASP
Modelo parcial do domínio de sistemas de terminais de pontos de venda:
Sale
datetime
SalesLineItem
quantity
ProductSpecification
descriptionpriceitemID
Described-by*
Contains
1..*
1
1
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 15
Os Padrão EspecialistaOs Padrão Especialista
Problema:Qual é o princípio geral de atribuição de responsabilidades aos objetos?
Solução:Atribua a responsabilidade ao Especialista – a classe que possui a informação necessária para executar uma tarefa que lhe foi atribuída.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 16
Os Padrão EspecialistaOs Padrão Especialista
Pergunta:Quem deve ser o responsável por conhecer o total geral de uma venda?
Resposta:Se olharmos para o modelo de domínio do problema, veremos que a classe Sale é o Especialista em relação ao total das vendas, pois ela conhece os itens que compõem uma venda.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 17
Os Padrão EspecialistaOs Padrão Especialista
Sale
datetime
getTotal()
:Salet := getTotal()
Novo Método:Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 18
Os Padrão EspecialistaOs Padrão Especialista
Pergunta:Quem deve ser o responsável por determinar o subtotal de cada item de uma venda?
Resposta:Para calcular o subtotal de um item é necessário conhecer a quantidade vendida e o preço do item. A classe SalesLineItem é o Especialista em relação ao subtotal, pois ela conhece a sua especificação e armazena a quantidade vendida.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 19
Os Padrão EspecialistaOs Padrão Especialista
Sale
datetime
getTotal()
SalesLineItem
quantity
getSubtotal()Novo método
1 *: st := getSubtotal(): Salet := getTotal()
*:SalesLineItem
:SalesLineItem
:Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 20
Os Padrão EspecialistaOs Padrão Especialista
Pergunta:Quem conhece o preço de um item de uma venda?
Resposta:A classe ProductSpecification é o Especialista em relação a essa informação, pois ela armazena o preço de um item.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 21
Os Padrão EspecialistaOs Padrão Especialista
Sale
datetime
getTotal()
SalesLineItem
quantity
getSubtotal()
ProductSpecification
descriptionpriceitemID
getPrice()Novo método
:ProductSpecification
1.1: p := getPrice()
1 *: st := getSubtotal(): Salet := getTotal()
*:SalesLineItem
:SalesLineItem
:Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 22
Os Padrão CriadorOs Padrão Criador
Problema:Quem deve ser o responsável pela criação de novas instâncias de algumas classes?
Solução:Atribua à classe B a responsabilidade de criar instâncias da classe A se uma ou mais sentenças da relação a seguir for verdadeira:
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 23
Os Padrão CriadorOs Padrão Criador
B agrega objetos da classe A.B contém objetos da classe A.B registra objetos da classe A.B usa de maneira muito próxima objetos da classe A.B contém dados que serão usados na criação de objetos da classe A.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 24
Os Padrão CriadorOs Padrão Criador
Pergunta:Quem deve ser o responsável pela criação dos itens de uma venda?
Resposta:A classe Sale, pois ela agrega os objetos da classe SalesLineItem.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 25
Os Padrão CriadorOs Padrão Criador
: Register : Sale
makeLineItem(quantity): SalesLineItemcreate(quantity)
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 26
O Padrão de Baixo AcoplamentoO Padrão de Baixo Acoplamento
Problema:Como projetar uma colaboração de modo a minimizar a dependência entre as classes, minimizar o impacto das mudanças e promover a reutilização?
Solução:Atribua as responsabilidades de modo a manter baixo o acoplamento entre as classes.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 27
O Padrão de Baixo AcoplamentoO Padrão de Baixo Acoplamento
Seja o modelo parcial de domínio visto na figura abaixo:
Payment Register Sale
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 28
O Padrão de Baixo AcoplamentoO Padrão de Baixo Acoplamento
Pergunta:Quem deve ser o responsável pela criação de uma instância de Payment, e pela associação desta à classe Sale?
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 29
O Padrão de Baixo AcoplamentoO Padrão de Baixo Acoplamento
Baseado no padrão Criador, poderíamos pensar na classe Register, pois é ela que registra um pagamento.
: Register p : Payment
:Sale
makePayment() 1: create()
2: addPayment(p):Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 30
O Padrão de Baixo AcoplamentoO Padrão de Baixo Acoplamento
Entretanto, a alternativa abaixo minimiza o acoplamento da classe Register.
: Register :Sale
:Payment
makePayment() 1: makePayment()
1.1. create():Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 31
O Padrão de Alta CoesãoO Padrão de Alta Coesão
Problema:Como projetar uma colaboração de modo a manter a complexidade em um nível aceitável?
Solução:Atribua as responsabilidades de modo que as classes mantenham a coesão em patamares elevados.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 32
O Padrão de Alta CoesãoO Padrão de Alta Coesão
Pergunta:Quem deve ser o responsável pela criação de uma instância de Payment, e pela associação desta à classe Sale?
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 33
O Padrão de Alta CoesãoO Padrão de Alta Coesão
Baseado no padrão Criador, poderíamos pensar na classe Register, pois é ela que registra um pagamento.
: Register : Sale
addPayment( p )
p : Paymentcreate()makePayment()
:Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 34
O Padrão de Alta CoesãoO Padrão de Alta Coesão
Olhando de maneira isolada para o exemplo anterior, a solução é aceitável. Entretanto, se continuarmos com a estratégia de tornar o objeto Register o ponto de recepção de todos os eventos gerados na interface, iremos atribuir um número muito grande de tarefas pouco relacionadas a esta classe. Isso irá torná-la pouco coesa; difícil de compreender, de modificar e de reutilizar.
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 35
O Padrão de Alta CoesãoO Padrão de Alta Coesão
A solução abaixo delega a criação de um pagamento à classe Sale, o que leva a uma solução de maior coesão para a classe Register.
: Register : Sale
makePayment() : Paymentcreate()
makePayment()
:Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 36
O Padrão ControladorO Padrão Controlador
Problema:Quem deve ser o responsável por tratar um evento de input gerado por um ator na interface do sistema?
Solução:Atribua a responsabilidade de tratar os eventos gerados na interface do sistema a uma classe que represente uma das seguintes opções:
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 37
Os Padrão ControladorOs Padrão Controlador
Representa o sistema como um todo, um dispositivo, ou um subsistema (controlador de fachada).Representa um cenário de um caso de uso. Neste caso a classe é normalmente chamada de:
<Nome do Caso de Uso>Handler<Nome do Caso de Uso>Coordinator<Nome do Caso de Uso>Manager
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 38
O Padrão ControladorO Padrão Controlador
Pergunta:Quem deve ser o controlador responsável por tratar um evento de input como enterItem ou endSale?
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 39
O Padrão ControladorO Padrão Controlador
Qual classe de objetos deve ser responsável por receber estamensagem de evento do sistema?
Ela é algumas vezes chamada de controlador ou coordenador.Ela normalmente não executa o trabalho, mas o delega paraoutros objetos.
O controlador é uma espécie de “fachada” entre a camada deapresenatação e a camada de domínio.
actionPerformed( actionEvent )
: ???
: Caixa
:SaleJFrame
pressiona o botão
enterItem(itemID, qty)?
Camada deApresentação
Camada deDomínio
Mensagem de evento do sistema
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 40
O Padrão ControladorO Padrão Controlador
Resposta:Pelo Padrão Controlador as opções seriam:
Register, POSSystem (Dispositivo, sistema com um todo)ProcessSaleHandler, ProcessSaleManager
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 41
O Padrão ControladorO Padrão Controlador
:RegisterenterItem(id, quantity)
:ProcessSaleHandlerenterItem(id, quantity)
: Caixa
: Caixa
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 42
O Padrão ControladorO Padrão Controlador
:Caixa
:SaleJFrame
actionPerformed( actionEvent )
:Sale1: makeLineItem(itemID, qty)
Não é desejável para um objeto dacamada de apresentação, tal comouma janela, estar envolvido na decisãode como um processo do domínio deveser tratado.
A lógica do negócio está embutida nacamada de apresentação, o que não éútil.
SaleJFrame não deveenviar esta mensagem.
pressiona o botão
Camada deApresentação
Camada deDomínio
Copyright © 2004 I. M. Filho, T.C. Oliveira, Parte V / 43
O Padrão ControladorO Padrão Controlador
actionPerformed( actionEvent )
:Register
: Caixa
:SaleJFrame
1: enterItem(itemID, qty)?
:Sale1.1: makeLineItem(itemID, qty)
Mensagem de evento do sistema
controlador
pressiona o botão
Camada deApresentação
Camada deDomínio