Desenvolvimento

Orientado a
Objetos e Componentes

Nilseu Padilha
npadilha.faqi@gmail.com
Autor: Prof. Federico Delgado

Agenda
Introduo:

Padres de Projeto
GRASP Patterns

Padres de Projeto
Em ingls, Design Patterns
Comeando pelo incio:

O que um padro ?

Maneira testada ou documentada de alcanar

um objetivo qualquer:
Padres so comuns em vrias reas da engenharia
Padres no so invenes originais

Design Patterns, ou Padres de Design/Projeto

Padres para alcanar objetivos na engenharia de

software
Inspirado em "A Pattern Language" de Christopher
Alexander, sobre padres de arquitetura de cidades,
casas e prdios
"Design Patterns" de Erich Gamma, John Vlissides,
Ralph Jonhson e Richard Helm, conhecidos como
"The Gang of Four",ou GoF, descreve 23 padres de
projeto teis.

Padres de Projeto
"Cada

padro descreve um problema que

ocorre repetidas vezes em nosso ambiente,
e ento descreve o ncleo da soluo para
aquele problema, de tal maneira que podese usar essa soluo milhes de vezes sem
nunca faz-la da mesma forma duas
vezes

Christopher Alexander, sobre padres em

Arquitetura

"Os

padres de projeto so descries de

objetos que se comunicam e classes que
so customizadas para resolver um
problema genrico de design em um
contexto especfico

Gamma, Helm, Vlissides & Johnson, sobre

padres em software

Padres de Projeto
Possui

quatro elementos essenciais:

nome do padro: referncia para

descrevermos um problema do projeto,
suas solues... uma ou duas palavras;
vocabulrio; documentao.
problema: em que situao aplicar o
padro; explica o problema e seu contexto.
soluo: descreve os elementos que
compem o padro de projeto, seus
relacionamentos, responsabilidades e
colaboraes; descrio abstrata de
problema de projeto
consequncias: resultados, anlises das
vantagens e desvantagens da aplicao do
padro (espao, tempo, linguagens
flexibilidade e extensibilidade de um
projeto)

Padres de Projeto
E

porque aprender ?

Aprender com a experincia dos outros

Aprender os padres ajudam um novato a agir mais
como um especialista

Programar melhor com orientao a objetos

Desenvolver software de melhor qualidade

Os padres utilizam eficientemente polimorfismo,

herana, modularidade, composio, abstrao
para construir cdigo reutilizvel, eficiente, de alta
coeso e baixo acoplamento

Aprender um vocabulrio comum

Compreender sistemas existentes
Saber a melhor forma de converter um modelo
de anlise em um modelo de implementao
Ter um caminho e um alvo para refatoramento

Padres de Projeto
Como

descrever um padro?

Nome e classificao do padro

Inteno e objetivo: tambm conhecido
como motivao
Aplicabilidade
Estrutura
Participantes
Colaboraes
Conseqncias
Implementao
Exemplo de cdigo
Usos conhecidos
Padres relacionados

Padres de Projeto
Quais

classificaes ?

H vrios catlogos de padres em

software:
Muitos so especficos a uma
determinada rea (padres J2EE, padres
de implementao em Java, em C#,
padres para concorrncia, sistemas
distribudos, etc.)

Veremos os seguintes catlogos de

padres:
MVC: Model-View-Controller (camadas)
GRASP: General Responsibility and

Padres de Projeto :
GRASP

GRASP: General Responsibility

and Assignment Software
Patterns
Introduzidos por Craig Larman em
seu livro Applying UML and
Patterns
Os padres GRASP descrevem os
princpios fundamentais da
atribuio de princpios
fundamentais da atribuio de
responsabilidades a objetos,
expressas na forma de padres
Esses padres exploram os
princpios fundamentais de
sistemas OO

5 padres fundamentais
4 padres avanados

Se voc conhece os padres

GRASP, pode dizer que
compreende o paradigma
orientado a objetos

Padres de Projeto :
GRASP

Tipos:

Bsicos

Creator (Criador)
Expert (Especialista da Informao)
Low Coupling (Baixo Acoplamento)
High Cohesion (Alta Coeso)

Avanados

Polymorphism (Polimorfismo)
Pure Fabrication (Fabrio/Inveo Pura)
Indirection (indireo)
Protected Variations (Variaes
Protegidas)

Padres de Projeto :
GRASP

Responsabilidade:

Um contrato ou obrigao de um
tipo ou classe (Booch e Rumbaugh)
Responsabilidades esto
relacionadas s obrigaes de um
objeto em termos de seu
comportamento.

Padres de Projeto :
GRASP

Dois

tipos de responsabilidades
bsicas:
Fazer (doing)
Fazer algo ele prprio(criar um objeto,
executar uma operao, ...)
Iniciar aes em outros
objetos(delegao).
Controlar e coordenar atividades em
outros objetos.

Conhecer (knowing)
Conhecer dados privados encapsulados.
Conhecer objetos relacionados.

Padres de Projeto :
GRASP

Responsabilidade

no a mesma
coisa que um mtodo.
Mtodos so implementados para
satisfazer as responsabilidades
Uma responsabilidade pode ser
cumprida por um nico mtodo ou
uma coleo de mtodos
trabalhando em conjunto
Padres

de projeto so princpios
para guiar a atribuio de
responsabilidades aos objetos.

GRASP : Especialista
Problema:

qual o princpio mais

bsico de atribuio de
responsabilidades a objetos ?
Soluo: Atribuir
responsabilidade ao especialista
da informao.

GRASP : Especialista
Exemplo:

no sistema de venda,
quem seria o responsvel por
calcular o valor total da venda? E
o valor parcial? E por unidade?

Sales

SalesItem

Register

ProductDescript
ion

GRASP : Especialista
O

valor ficar armazenado no

atributo value do objeto
ItemDeVenda (SalesItem)
Mas quem possui conhecimentos
necessrios para calcul-la?

GRASP : Especialista
Pelo

padro especialista, o objeto

Venda deve receber esta
atribuio, pois conhece a todos
os itens e suas quantidades, que
utilizado para calcular o valor
total da venda.

GRASP : Especialista

GRASP : Especialista
Onde

procurar pela classe

especialista?
Comear pelas classes j
estabelecidas durante o projeto
Se no encontrar, utilizar o Modelo
Conceitual

Lembrar

que existem
especialistas parciais que
colaboram numa tarefa
informao espalhada
comunicao via mensagens

GRASP : Especialista
Benefcios:

Mantm encapsulamento, favorece o

acoplamento fraco
O comportamento fica distribudo entre
as classes que tm a informao
necessria (classes leves) , favorece
alta coeso
Favorece o reuso
Contra-indicaes

contra indicado quando aumenta

acoplamento e reduz coeso
Ex: quem responsvel por salvar um
Emprstimo no banco de dados?

GRASP : Criador
Problema:

Quem deveria ser

responsvel pela criao de uma nova
instncia de alguma classe ?
Soluo: Padro Criador

A classe A deve ser criado por outro (classe

B) que o possua como parte (agregao)
ou esteja fortemente associado a ele.
Se uma das seguintes condies for
verdadeira, a classe forte candidata:

Classe B agrega objetos de classe A

Classe B contm objetos de classe A
Classe B registra objetos de classe A
Classe B usa objetos de classe A
Classe B tem os valores iniciais que sero
passados para objetos de classe A, quando de sua
criao

GRASP : Criador
Exemplo:

Ao registrar itens de uma venda,

quem deve ser responsavel pela
criao de objetos da classe
ItensDeVenda (SalesItem) ?
Sales

Register

GRASP : Criador
A

classe Sales (Venda) agrega

muitos SalesItem (ItensDeVenda),
ento ela uma forte candidata

GRASP : Criador

Objetivo

do padro: definir como

criador o objeto que precise ser
conectado ao objeto criado em
algum evento
Escolha adequada favorece
acoplamento fraco
Objetos agregados, contineres e
registradores so bons candidatos
responsabilidade de criar outros
objetos
Algumas vezes o candidato a
criador o objeto que conhece os
dados iniciais do objeto a ser criado

GRASP : Acoplamento
Baixo

Problema:

Como suportar baixa

dependncia, baixo impacto devido a
mudanas e reuso constante?
Soluo: Padro Acoplamento Baixo
uma medida de quo fortemente um
elemento est conectado a, tem
conhecimento de, ou depende de outros
uma medida de quo fortemente um
elemento est conectado a, tem
conhecimento de, ou depende de outros
elementos
um elemento com acoplamento baixo
(fraco) no dependente de muitos outros
elementos
elementos incluem classes, subsistemas,
sistemas, etc

GRASP : Acoplamento
Baixo

ClasseA tem um atributo do

tipo ClasseB

GRASP : Acoplamento
Baixo

A ClasseA tem um mtodo que, de alguma forma,

referencia uma instncia de ClasseB. Tipicamente, esta
referncia se d atravs de um parmetro ou varivel local
do tipo ClasseB ou por um objeto do tipo ClasseB retornado
pela chamada de algum mtodo

GRASP : Acoplamento
Baixo

A ClasseA uma subclasse da

ClasseB

GRASP : Acoplamento
Baixo

A ClasseB uma interface e a

ClasseA implementa esta
interface

GRASP : Acoplamento
Baixo
Uma classe com acoplamento
forte (ou alto) depende de muitas
outras classes
Tais classes podem ser
indesejveis, algumas sofrem dos
seguintes problemas:
modificaes locais foradas
decorrentes de modificaes em
classes relacionadas
so mais difceis de entender
isoladamente
so mais difceis de reutilizar, pois

GRASP : Acoplamento
Baixo

Exemplo:

atribuir responsabilidade de modo que o

acoplamento permanea baixo. Use esse
princpio para avaliar alternativas.
considere o seguinte diagrama de classes
parcial do estudo de caso
Sales

Payment

Register

precisamos criar uma instncia de

Pagamento (Payment) e associ-la a
Venda (Sale). Que classe deve ser
responsvel por isto?
como Registradora (Register) registra um
Pagamento no domnio do mundo real,

GRASP : Acoplamento
Baixo

Soluo

1:

A instncia de Registradora pode ento enviar uma

mensagem addPayment (adicionarPagamento) para
a Venda, passando junto o novo Pagamento como
parmetro
esta atribuio acopla a classe Registradora ao
conhecimento da classe Pagamento

GRASP : Acoplamento
Baixo

Soluo

2:

GRASP : Acoplamento
Baixo

Qual dos projetos, baseado na

atribuio de responsabilidades,
apia o Acoplamento Baixo?

GRASP : Acoplamento
Baixo

Em

ambos os casos consideramos que

Venda deve ser acoplada ao conhecimento
de Pagamento
A soluo 1, no qual Registradora cria
Pagamento adiciona acoplamento de
Registradora a Pagamento; o soluo 2 no
qual Venda faz a criao de um
Pagamento, no aumenta o acoplamento
Pensando em acoplamento o soluo2
mantm um acoplamento global mais
baixo
Este exemplo nos mostra como dois
padres de projetos distintos (Criador e
Baixo Acoplamento) podem sugerir
solues diferentes

GRASP : Acoplamento
Baixo

Na

prtica o nvel de acoplamento no

pode ser considerado isolado de outros
princpios, tais como Especialista e
Coeso Alta. No entanto, um fator a
considerar no aperfeioamento de um
projeto.
Acoplamento Baixo um princpio a se
ter em mente durante todas as
decises de projeto, uma meta
subjacente a ser considerada
continuamente. UM PRINCPIO DE
AVALIAO que voc aplica ao avaliar
todas as decises de projeto

GRASP : Acoplamento
Baixo

Consideraes:

Favorece o projeto de classes independentes,

reduzindo o impacto de modificaes
No pode ser considerado isoladamente, mas
deve ser considerado ao se atribuir
responsabilidade
Uma subclasse fortemente acoplada sua
superclasse;
No temos uma forma absoluta de medir
acoplamento
Podemos avaliar e ver quais as conseqncias
na prtica
O caso extremo de Acoplamento Baixo
quando no existe acoplamento entre classes,
um sistema OO composto de objetos conectados
que se comunicam por mensagens

GRASP : Acoplamento
Baixo

Vantagens:

No afetado por mudanas em

outros componentes
simples de entender isoladamente
conveniente para reutilizao

GRASP : Alta Coeso

Problema:

Como manter os objetos

focados, inteligveis e gerenciveis e
com efeito colateral apoiar o
acoplamento baixo?
Soluo: Atribuir uma responsabilidade
de forma que a coeso permanea alta.
Uma classe com coeso baixa faz coisas
no relacionadas e trabalha demais, no
queremos isto, elas sofrem dos seguintes
problemas:

so difceis de compreender
so difceis de reutilizar
so difceis de manter
so delicadas, constantemente afetadas por
modificaes

GRASP : Alta Coeso

Como

um princpio bsico, uma

classe com alta coeso:
tem um nmero relativamente
pequeno de mtodos,
a funcionalidade desses mtodos
altamente relacionada, e no faz
trabalho de mais.

GRASP : Alta Coeso

As

classes com baixa coeso geralmente

representam um grau de abstrao muito
alto e de grande granularidade, ou ento
assumiram responsabilidades que deveria
ter sido delegadas a outros objetos
Exemplo:

vamos analisar o exemplo usado no padro

Acoplamento Baixo e analis-lo quanto a
Coeso Alta
Precisamos cria uma instncia de Pagamento e
associ-la a Venda... Que classe deve ser
responsvel por isto?
Soluo 1: Registradora manda uma
mensagem makePayment() para Venda,
passando como um parmetro o novo
Pagamento
A responsabilidade de criar um pagamento fica para
Registradora, assumindo uma parte da

GRASP : Polimorfismo
Problema:

Como tratar diferentes

comportamentos baseado num
mesmo tipo de objeto?
Soluo: Utilizar o polimorfismo
ao objeto que pode apresentar
mais de um tipo de
comportamento.

GRASP : Polimorfismo
O

uso de ifs aninhados ou switchcase para selecionar

comportamento em funo do
tipo de classe espalha-se por
todo o cdigo, dificultando a
manuteno
A necessidade de substituio de
parte de um sistema pode se
tornar um problema caso o
sistema no tenha sido projetado
para isso

GRASP : Polimorfismo
No

nosso exemplo Para evitar a

necessidade de seleo de
comportamento, a classe Pagamento
deve definir o mtodo autoriza()
As subclasses de Pagamento devem
aplicar polimorfismo sobre o mtodo
autoriza()

GRASP : Polimorfismo
Benefcio:

Facilidade de manuteno
Facilidade de insero de um novo
tipo de autorizao

GRASP : Pura Inveo

Problema:

Que objeto deve ter a

responsabilidade quando voc no
quer violar Alta Coeso e Baixo
Acoplamento, mas as solues
oferecidas pelo Especialista no
so apropriadas?
Soluo: Atribua um conjunto coeso
de responsabilidade a uma classe
artificial que no representa um
conceito no domnio da aplicao,
uma classe fictcia que possibilite
alta coeso, baixo acoplamento e o

GRASP : Pura Inveo

O

especialista nos diz para atribuir

a responsabilidade classe Venda,
uma vez que ela conhece os dados
de venda. Considere no entanto as
seguintes implicaes:
Salvar um objeto no Banco de
Dados implica em uma srie de
operaes no relacionadas ao
conceito de venda.
A classe Sales(Venda) tem de ser
associada interface do banco de
dados relacional (JDBC, por
exemplo).
Vrias outras classes no projeto

GRASP : Pura Inveo

Classes de persistncia e autenticao so candidatas

a usar o padro Pura Inveno

GRASP : Pura Inveo

No

nosso exemplo As classes de

pagamento continuariam aplicando o
padro Polimorfismo, aliado a um
mecanismo de delegao s classes
artificiais

GRASP : Pura Inveo

Benefcios:

Remove as caractersticas no coesas

das classes do domnio de negcio
Cria classes muito coesas com essas
caractersticas
Problemas:

Cria classes altamente funcionais, que

no fazem parte da realidade
Se utilizado em excesso, poder
transformar um sistema OO em um
sistema orientado a eventos

GRASP : Indireo
Problema:

Como posso evitar o

acoplamento direto? Caso uma
classe seja acoplada a servios,
ser impossvel reutilizar esses
servios...
Soluo: Criar um objeto
intermedirio, fazendo indireo
para o servio. So criados um ou
mais nveis de indireo, para
possibilitar a reutilizao e
substituio de cdigo

GRASP : Indireo
Exemplo:

Para que o pagamento

via carto ou cheque funcione,
devem existir chamadas ao driver
de modem

GRASP : Indireo
Criar

um objeto intermedirio,
fazendo indireo para o servio;
So criados um ou mais nveis de
indireo, para possibilitar a
reutilizao e substituio de
cdigo;

GRASP : Indireo
Exemplo:

Uma classe deve ser criada para

representar (fazer indireo para) o
modem
Uma classe deve ser criada para
representar (fazer indireo para) o
leitor de moeda

GRASP : Variao
Protegida

Problema:

Como atribuir
responsabilidades a objetos,
subsistemas e sistemas, de modo
que as variaes ou a
instabilidade nesses elementos
no tenham um impacto
indesejvel sobre outros
elementos?
Soluo: Identifique pontos de
variao ou instabilidade
prevista; atribua

GRASP : Variao
Protegida

Toda

aplicao tem pontos de

variao, identifique os pontos de
variao ou instabilidade
prevista, atribuindo
responsabilidades para criar uma
interface estvel em torno deles.
Na variao protegida temos as
variaes evolutivas e as
variaes corretivas.

GRASP : Variao
Protegida

Mecanismos

de Variaes Protegidas

Agentes (Brokers) encarregado de levar as

requisies que recebe, localiza qual local de
destino e entrega ao local correto.
Mquinas Virtuais simulam vrios sistemas em um
nico meio fsico, d maior portabilidade aos
sistemas em ambientes instveis.
Projetos dirigidos por dados (dataDriver design)
troca de informaes entre aplicaes atravs de
arquivos configurados por exemplo XML, framework
Spring, TomCat, etc.
Pesquisa de servios ter algum que fornea
servios, e ter algum que consome os servios
disponibilizados, podemos citar como exemplo o
novo paradigma SOA.
Projetos dirigidos por interpretadores so
aplicaes que interpretam ambientes ou sistemas
diferentes, por exemplo JVM, Engine Regras.

GRASP : Variao
Protegida

Mecanismos de Variaes Protegidas

Projetos reflexivos ou de meta-dados nesse caso reflete o que tem

dentro da classe, por exemplo: o normal a se fazer em uma consulta
em banco de dados pesquisar pelo catalogo do banco e no a
colunas, se algum vier a mudar a tabela que est consultando,
alterando apenas o nome das colunas, isso ir prejudicar sua
consulta, no caso de uma consulta pelo catalogo do banco o
problema descrito acima no ir acontecer pois sua consulta ir
solicitar ao catalogo que por sua vez possui o ndice da tabela que
est consultando e assim retornar os dados da coluna relacionada a
consulta.
Acesso Uniforme no se preocupa com a estrutura da linguagem,
no se restringe a propriedades, mtodos, procedimentos, etc., tudo
igual seja ele com definies de propriedade, mtodos ou
procedimentos, exemplos de linguagens que no se preocupa com
definies so: linguagem EIFFEL, C#, etc.
Princpios da substituio de Liskov como mecanismo de variao
protegida a substituio de Liskov prev que se declararmos classes
como interface qualquer classe poder implementar a superclasse.