Projeto Orientado a Objetos - inf.puc-rio.brivan/INF1013/Apostila/PadroesGrasp.pdfProjeto Orientado...

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.”


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.


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.



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



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.



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.



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.


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.”



“É 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.”



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.


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.”



A seguir iremos apresentar os seguintes padrões GRASP:

Especialista (Information Expert)Criador (Creator)Baixo AcoplamentoAlta CoesãoControlador



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


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.



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.



Sale

datetime

getTotal()

:Salet := getTotal()

Novo Método:Caixa



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.



Sale

datetime

getTotal()

SalesLineItem

quantity

getSubtotal()Novo método

1 *: st := getSubtotal(): Salet := getTotal()

*:SalesLineItem

:SalesLineItem

:Caixa



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.



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


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:



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.



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.



: Register : Sale

makeLineItem(quantity): SalesLineItemcreate(quantity)


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.



Seja o modelo parcial de domínio visto na figura abaixo:

Payment Register Sale



Pergunta:Quem deve ser o responsável pela criação de uma instância de Payment, e pela associação desta à classe Sale?



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



Entretanto, a alternativa abaixo minimiza o acoplamento da classe Register.

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create():Caixa


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.



Pergunta:Quem deve ser o responsável pela criação de uma instância de Payment, e pela associação desta à classe Sale?



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



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.



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


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:


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



Pergunta:Quem deve ser o controlador responsável por tratar um evento de input como enterItem ou endSale?



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



Resposta:Pelo Padrão Controlador as opções seriam:

Register, POSSystem (Dispositivo, sistema com um todo)ProcessSaleHandler, ProcessSaleManager



:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

: Caixa

: Caixa



:Caixa

:SaleJFrame


: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 deDomínio




:Register

: Caixa

:SaleJFrame

1: enterItem(itemID, qty)?

:Sale1.1: makeLineItem(itemID, qty)

Mensagem de evento do sistema

controlador

pressiona o botão


Camada deDomínio

Projeto Orientado a Objetos - inf.puc-rio.brivan/INF1013/Apostila/PadroesGrasp.pdfProjeto Orientado...

Documents

Transcript of Projeto Orientado a Objetos - inf.puc-rio.brivan/INF1013/Apostila/PadroesGrasp.pdfProjeto Orientado...