Design Orientado a Objetos Design Orientado a Objetos

(1)

Projeto Orientado a Projeto Orientado a

Objetos Objetos

Ivan Mathias Filho

Toacy Cavalcante de Oliveira

Design Orientado a Objetos Design 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.”

(2)

Design Orientado a Objetos Design 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 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.

(3)

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:

)Fazer

)Conhecer

O que são Responsabilidades?

)

As responsabilidades que um objeto deve Fazer incluem:

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

(4)

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.

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 subsistemas

)Outras, como criar um objeto que represente a venda de uma mercadoria, podem envolver uma ou duas classes e uns poucos métodos.

(5)

Padrões de Responsabilidade Padrõ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.”

Padrões de Responsabilidade Padrõ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.”

(6)

Padrões de Responsabilidade Padrõ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.

Os Padrões GRASP Os Padrões GRASP

“Os padrões GRASP (General Responsibility

Assignment Software Pattern) descrevem os

princípios fundamentais envolvidos no design

orientado a objetos e na atribuição de

responsabilidade aos objetos de um sistema.”

(7)

Os Padrões GRASP Os Padrões GRASP

)

A seguir iremos apresentar os seguintes padrões GRASP:

)Especialista (Information Expert)

)Criador (Creator)

)Baixo Acoplamento

)Alta Coesão

)Controlador

Os Padrões GRASP Os Padrões GRASP

Modelo parcial do domínio de sistemas de terminais de pontos de venda:

Sale date time

Sales LineItem quantity

Product Specification description price itemID Described-by

*

Contains 1..* 1

1

(8)

Os Padrão Especialista Os 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.

Os Padrão Especialista Os 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 Especialistaem relação ao total das vendas, pois ela conhece os itens que compõem uma venda.

(9)

Os Padrão Especialista Os Padrão Especialista

Sale date time getTotal() :Sale

t := getTotal()

Novo Método :Caixa

Os Padrão Especialista Os 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 Especialistaem relação ao subtotal, pois ela conhece a sua especificação e armazena a quantidade vendida.

(10)

Os Padrão Especialista Os Padrão Especialista

Sale date time getTotal()

SalesLineItem quantity getSubtotal() Novo método

1 *: st := getSubtotal() : Sale

t := getTotal()

*

:SalesLineItem :SalesLineItem

:Caixa

Os Padrão Especialista Os Padrão Especialista

)

Pergunta:

)Quem conhece o preço de um item de uma venda?

)

Resposta:

)A classe ProductSpecificationé o Especialistaem relação a essa informação, pois ela armazena o preço de um item.

(11)

Os Padrão Especialista Os Padrão Especialista

Sale date time getTotal()

SalesLineItem quantity getSubtotal()

Product Specification description price itemID getPrice() Novo método

:Product Specification 1.1: p := getPrice() 1 *: st := getSubtotal() : Sale

t := getTotal()

*

:SalesLineItem :SalesLineItem

:Caixa

Os Padrão Criador Os 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:

(12)

Os Padrão Criador Os 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.

Os Padrão Criador Os 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.

(13)

Os Padrão Criador Os Padrão Criador

: Register : Sale

makeLineItem(quantity)

: SalesLineItem create(quantity)

O Padrão de Baixo Acoplamento O 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.

(14)

O Padrão de Baixo Acoplamento O Padrão de Baixo Acoplamento

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

Payment Register Sale

O Padrão de Baixo Acoplamento O 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?

(15)

O Padrão de Baixo Acoplamento O 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

O Padrão de Baixo Acoplamento O 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

(16)

O Padrão de Alta Coesão O 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.

O Padrão de Alta Coesão O 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?

(17)

O Padrão de Alta Coesão O 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 : Payment create()

makePayment()

:Caixa

O Padrão de Alta Coesão O 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.

(18)

O Padrão de Alta Coesão O 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()

: Payment create()

makePayment()

:Caixa

O Padrão Controlador O 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:

(19)

Os Padrão Controlador Os 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

O Padrão Controlador O Padrão Controlador

)

Pergunta:

)Quem deve ser o controlador responsável por tratar um evento de input como enterItemou endSale?

(20)

O Padrão Controlador O Padrão Controlador

Qual classe de objetos deve ser responsável por receber esta mensagem de evento do sistema?

Ela é algumas vezes chamada de controlador ou coordenador.

Ela normalmente não executa o trabalho, mas o delega para outros objetos.

O controlador é uma espécie de “fachada” entre a camada de apresenatação e a camada de domínio.

actionPerformed( actionEvent )

: ???

: Caixa

:SaleJFrame pressiona o botão

enterItem(itemID, qty)?

Camada de Apresentação

Camada de Domínio

Mensagem de evento do sistema

O Padrão Controlador O Padrão Controlador

)

Resposta:

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

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

)ProcessSaleHandler, ProcessSaleManager

(21)

O Padrão Controlador O Padrão Controlador

:Register enterItem(id, quantity)

:ProcessSaleHandler enterItem(id, quantity)

: Caixa

O Padrão Controlador O Padrão Controlador

:Caixa

:SaleJFrame

:Sale 1: makeLineItem(itemID, qty)

Não é desejável para um objeto da camada de apresentação, tal como uma janela, estar envolvido na decisão de como um processo do domínio deve ser tratado.

A lógica do negócio está embutida na camada de apresentação, o que não é útil.

SaleJFrame não deve enviar esta mensagem.

pressiona o botão

(22)

O Padrão Controlador O Padrão Controlador

:Register : Caixa

:SaleJFrame

1: enterItem(itemID, qty)?

:Sale 1.1: makeLineItem(itemID, qty)

Mensagem de evento do sistema

controlador pressiona o botão