Padres GRASP

Padres bsicos
Information Expert
Creator
High Cohesion
Low Coupling
Controller
Padres avanados
Polymorphism
Pure Fabrication
Indirection
Protected Variations

Padres GRASP refletem

prticas mais pontuais da
aplicao de tcnicas OO
Padres GoF exploram
solues mais especficas
Padres GRASP ocorrem
na implementao de
vrios padres GoF

179

Expert (especialista de informao)

Problema
Precisa-se de um princpio geral para atribuir
responsabilidades a objetos
Durante o design, quando so definidas interaes entre
objetos, fazemos escolhas sobre a atribuio de
responsabilidades a classes

Soluo
Atribuir uma responsabilidade ao especialista de informao:
classe que possui a informao necessria para cumpri-la
Comece a atribuio de responsabilidades ao declarar
claramente a responsabilidade
180

Expert
No sistema abaixo, uma classe precisa saber o total
geral de uma venda (Sale). Que classe deve ser a
responsvel?
Sale possui informaes sobre
SalesLineItems (knowing)

Fonte: [4]

181

Expert (2)
A nova responsabilidade conduzida por uma
operao no driagrama de interao
Um novo mtodo criado

Fonte: [4]

182

Expert(3)
Mas como a classe Sale vai calcular o valor total?
Somando os subtotais. Mas quem faz isto?
A responsabilidade para cada subtotal atribuda ao
objeto SalesLineItem (item de linha do pedido)

183

Expert (4)
O subtotal depende do preo. O objeto
ProductSpecification o especialista que conhece o
preo, portanto a responsabilidade dele.

184

Creator
Problema: Que classe deve ser responsvel pela
criao de uma nova instncia de uma classe?
Soluo: Atribua a B a responsabilidade de criar
A se:
B agrega A objetos
B contm A objetos
B guarda instncias de A objetos
B faz uso de A objetos
B possui dados para inicializao que ser passado
para A quando ele for criado.
185

Creator
Que classe deve ser responsvel por criar uma
instncia do objeto SalesLineItem abaixo?
Sale agrega muitos
SalesLineItems

186

Creator
A nova responsabilidade conduzida por uma
operao em um diagrama de interaes
Um novo mtodo criado na classe de design para expressar
isto.

Este mtodo precisa

ser definido em Sale

Fonte: [4]

187

High Cohesion
Problema
Como manter a complexidade sob controle?
Classes que fazem muitas tarefas no relacionadas
so mais difceis de entender, de manter e de
reusar, alm de serem mais vulnerveis mudana.

Soluo
Atribuir uma responsabilidade para que a coeso se
mantenha alta.
Voc sabe o que coeso?
188

Coeso
Coeso [Funcional]
Uma medida de quo relacionadas ou focadas
esto as responsabilidades de um elemento.

Exemplo
Uma classe Co coesa se tem operaes
relacionadas ao Co (morder, correr, comer, latir)
e apenas ao Co (no ter por exemplo, validar,
imprimirCao, listarCaes)
Alta coeso promove design modular
189

High Cohesion
Que classe responsvel por criar um pagamento (Payment) e
associ-lo a uma venda (Sale)?

Register assumiu responsabilidade por uma coisa que parte de

Sale (fazer um pagamento no responsabilidade de registrar)
190

High Cohesion
Nesta soluo, Register delega a responsabilidade a
Sale, diminuindo aumentando a coeso de Register
A criao do processo de pagamento agora
responsabilidade da venda e no do registro. Faz mais
sentido pois o pagamento parte de Sale.

191

Low Coupling (baixo acoplamento)

Problema
Como suportar baixa dependncia, baixo impacto devido a
mudanas e reuso constante?

Soluo
Atribuir uma responsabilidade para que o acoplamento
mantenha-se fraco.

Acoplamento
uma medida de quanto um elemento est conectado a, ou
depende de outros elementos
Uma classe com acoplamento forte depende de muitas
outras classes: tais classes podem ser indesejveis
O acoplamento est associado coeso: maior coeso,
menor acoplamento e vice-versa.
192

Low Coupling
Como devemos atribuir uma responsabilidade
para criar Payment e associ-lo com Sale?
Payment

Register

Sale
193

Low Coupling
Qual das opes abaixo suporta o menor
acoplamento?

Opo 1

Opo 2

194

Controller
Problema
Quem deve ser o responsvel por lidar com um evento de
uma interface de entrada?

Soluo
Atribuir responsabilidades para receber ou lidar com um
evento do sistema para uma classe que representa todo o
sistema (controlador de fachada front controller), um
subsistema e um cenrio de caso de uso (controlador de
caso de uso ou de sesso).

Este padro semelhante (ou equivalente) a um

padro GoF. Qual?
195

Controller
Um sistema contendo operaes de sistema
associados com eventos do sistema.

196

Controller: problema

197

Controller: soluo
A primeira soluo representa o sistema inteiro
A segunda soluo representa o destinatrio ou
handler de todos os eventos de um caso de uso

O diagrama acima no mostra o Controller, mas a transparncia da

comunicao (chamada do cliente, objeto que recebe a mensagem)
198

Outros padres
Padres GRASP avanados
Domine primeiro os cinco bsicos antes de explorar
estes quatro:
Polymorphism
Indirection
Pure Fabrication
Protected Variations

Outros padres
Dependency Injection (aplicao de Indirection)
Aspectos
199

GRASP: Polymorphism
Problema:
Como lidar com alternativas baseadas no tipo? Como criar
componentes de software plugveis?
Deseja-se evitar variao condicional (if-then-else): pouco
extensvel.
Deseja-se substituir um componente por outro sem afetar o
cliente.

Soluo
No use lgica condicional para realizar alternativas
diferentes baseadas em tipo. Atribua responsabilidades ao
comportamento usando operaes polimrficas
Refatore!
200

GRASP: Pure Fabrication

Problema
Que objeto deve ter a responsabilidade, quando voc no
quer violar High Cohesion e Low Coupling, mas as solues
oferecidas por Expert no so adequadas?
Atribuir responsabilidades apenas para classes do domnio
conceitual pode levar a situaes de maior acoplamento e
menos coeso.

Soluo
Atribuir um conjunto altamente coesivo de responsabilidades
a uma classe artificial que no representa um conceito do
domnio do problema.

201

GRASP: Protected Variations

Problema
Como projetar objetos, subsistema e sistemas para que as
variaes ou instabilidades nesses elementos no tenha um
impacto indesejvel nos outros elementos?

Soluo
Identificar pontos de variao ou instabilidade potenciais.
Atribuir responsabilidades para criar uma interface estvel
em volta desses pontos.
Encapsulamento, interfaces, polimorfismo, indireo e
padres; mquinas virtuais e brokers so motivados por este
princpio
Evite enviar mensagens a objetos muito distantes.
202

GRASP: Indirection
Problema

Onde atribuir uma responsabilidade para evitar

acoplamento direto entre duas ou mais coisas? Como
desacoplar objetos para que seja possvel suportar baixo
acoplamento e manter elevado o potencial de reuso?

Soluo

Atribua a responsabilidade a um objeto intermedirio para

mediar as mensagens entre outros componentes ou servios
para que no sejam diretamente acoplados.
O objeto intermedirio cria uma camada de indireo entre
os dois componentes que no mais dependem um do outro:
agora ambos dependem da indireo.

Veja uma aplicao em: Dependency Injection

203

Injeo de dependncias
(inverso de controle)

Um dos benefcios de usar interfaces

A depende de B
Em vez de
A

A precisa achar ou criar B

class A {
B b = new B();
}

Use
A

inteface

InterB

A depende de uma interface IB

B depende de uma interface IB
A recebe implementao de B quando criado

class A {
InterB b;
A(InterB b) {
this.b = b;
}
}
204

Injeo de dependncias (2)

Se A depende de InterB, fica fcil testar ou medir A usando uma
implementao/simulao de B para testes
ATest
ATest

A
A

inteface

InterB

SimulatedB

inteface

InterB

Interfaces devem ser pequenas

Um objeto pode implementar vrias interfaces
Facilita evoluo (interfaces grandes publicam um contrato grande que no
pode ser revogado)

Planeje interfaces em todos os objetos

Principalmente objetos que oferecem servios, singletons, etc.
205

Dependency Injection
Problema
Controle convencional: o prprio objeto cria ou
localiza suas dependncias: acoplamento!
ProgramadorJava
nome: String
certificacao:CertificacaoProgramadorJava
inscrever(): Certificado
JNDI
new
CertificacaoProgramadorJava()
CertificacaoProgramadorJava

lookup(certificacaoSCEA)

CertificacaoArquitetoJ2EE
206

Exemplo: controle convencional

Linha 9: dependncia fortemente acoplada
Difcil de testar objeto sem testar dependncia
1:package faculdade;
2:
3:public class ProgramadorJava {
4:
private String nome;
5:
private CertificacaoProgramadorJava certificacao;
6:
7:
public ProgramadorJava(String nome) {
8:
this.nome = nome;
9:
certificacao = new CertificacaoProgramadorJava();
10:
}
11:
12:
public Certificado inscrever() throws NaoAprovadoException {
13:
return certificacao.iniciarTeste();
14:
}
15:}

207

A dependncia
1:package faculdade;
2:
3:public class CertificacaoProgramadorJava {
4:
public CertificacaoProgramadorJava() {}
5:
public Certificado iniciarTeste()
throws NaoAprovadoException {
6:
Certificado certificado = null;
7:
// Realizar questoes
8:
9:
return certificado;
10:
}
11:}

208

Diminuindo o acoplamento
Melhor forma de eliminar acoplamento usar interfaces
Implementao dependente da interface
Cliente depende da interface, e no mais da implementao
3:public interface Certificacao {
4:
public Object iniciarTeste() throws CertificacaoException;
5:}
3:public class CertificacaoProgramadorJava implements Certificacao {
4:
public CertificacaoProgramadorJava() {}
5:
public Object iniciarTeste() throws NaoAprovadoException {
6:
Certificado certificado = new Certificado();
7:
// Realizar questoes
8:
certificado.setNota(90);
9:
10:
return certificado;
11:
}
12:}

209

Soluo
Em vez do programador buscar ou criar sua prpria certificao,
ela atribuda a ele
Para isto, deve haver mtodo para criar a associao
ProgramadorJava
nome: String
certificacao:CertificacaoProgramadorJava
inscrever(): Certificado
setCertificacao(Certificacao);

Certificacao

programador.setCertificacao(this)
CertificacaoArquitetoJ2EE

programador.setCertificacao(certJ2EE)
CertificacaoProgramadorJava
210

Inverso de controle
public interface Programador {
public Object inscrever() throws NaoAprovadoException;
}
3:public class ProgramadorJava implements Programador {
4:
private String nome;
5:
private CertificacaoProgramadorJava certificacao;
6:
7:
public ProgramadorJava(String nome) {
8:
this.nome = nome;
9:
}
10:
11:
public Object inscrever() throws NaoAprovadoException {
12:
return certificacao.iniciarTeste();
13:
}
14:
15:
public void setCertificacao(Certificacao certificacao) {
16:
this.certificacao = certificacao;
17:
}
18:}
211

Aspectos: Separao de interesses

A separao de interesses objetivo essencial do processo de
decomposio da soluo de um problema
Decomposio deve continuar at que cada unidade da soluo possa ser
compreendida e construda
Cada unidade deve lidar com apenas um interesse

Separao de interesses eficiente promove cdigo de melhor

qualidade

Maior modularidade
Facilita atribuio de responsabilidades entre mdulos
Promove o reuso
Facilita a evoluo do software
Viabiliza anlise do problema dentro de domnios especficos

212

Tipos de interesse
Usando uma linguagem orientada a objetos, pode-se representar
de forma eficiente e modular as classes e procedimentos
Outros interesses so implementados como partes de classes e
partes ou composio de procedimentos
Caractersticas mover() e
desenhar() poderiam ser
reutilizadas em outros
objetos

Retngulo
mover()
desenhar()

Aspectos genricos
Poderiam ser usados em
outras aplicaes

Figura
mover()
desenhar()

Crculo
mover()
desenhar()

Tringulo
mover()
desenhar()

mover()
validarCoords()
// cdigo p/ mover
logarAcao()
desenhar()
// cdigo p/ desenhar
logarAcao()
213

Problema: scattering e tangling

Scattering: acrescentar um
public class VeiculoPassageiro
extends Veiculo {
requerimento causa
public void abastecer() {
espalhamento do cdigo
super.abastecer() + gasolina;
em vrias classes
Logger.log(nome() +
" abastecido com gasolina");
} ...
public class VeiculoCarga
}
extends Veiculo {
public void abastecer() {
super.abastecer() + diesel;
Logger.log(nome() +
public class VeiculoAereo
" abastecido com diesel");
extends Veiculo {
} ...
public void abastecer() {
}
// cdigo
Logger.log(nome() +
" abastecido com " +
x + " litros");
// cdigo
} ...
}

Tangling: cdigo para

implementar o requerimento
se mistura com lgica do
cdigo existente
214

Incluso de nova funcionalidade

Tambm sujeita a scattering e tangling
Funcionalidade espalhada por vrias classes (funcionalidade
consiste de mtodos contidos em vrias classes)
Funcionalidade misturada com outros recursos (no
representado por uma entidade separada)
public class VeiculoPassageiro
extends Veiculo {
public void abastecer() {...}
public void carregar() {...}
public Apolice segurar() {
Apolice a =
new Apolice(...);
// preenche apolice basica
return a;
}
...
}

public class VeiculoCarga

extends Veiculo {
public void abastecer() {...}
public Apolice segurar() {
Apolice a = new Apolice();
// preenche apolice p/
// segurar carro e carga
return a;
}
public void carregar() {...}
...
}
215

Como reduzir tangling e scattering?

1. Criar subclasse que implemente
recursos, sobreponha mtodos, etc.
Problema: classes cliente tm que ser
alteradas para que saibam como criar a
nova subclasse:
VeiculoCarga v =
// new VeiculoCarga();
new VeiculoCarga2();

2. Design patterns como

factory method resolveriam o
problema
VeiculoCarga v =
VeiculoCarga.create();

mas sua interface precisaria

ser planejada antes!

package veiculos;
public class VeiculoCarga
extends Veiculo {
public void abastecer() {
super.abastecer()
+ diesel;
}
}

package veiculos.versao2;
public class VeiculoCarga2
extends veiculos.VeiculoCarga {
public void abastecer() {
super.abastecer() + diesel;
Logger.log(nome() +
" abastecido com diesel");
}
public Apolice segurar() {...}
}
216

Soluo: Aspect-Oriented Programming

AOP divide interesses em dois grupos
Componentes: quando interesse encapsulvel em unidades
OO (classe, objeto, mtodo, procedimento).
Aspectos: interesses que no so representados como
componentes mas representar propriedades que interferem no
seu funcionamento ou estrutura.

Aspectos so interesses ortogonais

Costurados ao cdigo principal durante compilao ou
execuo (depende da implementao)
Weaver

Aplicao

Classes
Interesses do
domnio
Aspectos

Join
Points
217

Soluo: Subject-Oriented Programming

Sujeitos (subjects) so abstraes diferentes de um mesmo conceito
dentro de um domnio especfico
Coloridos

Crculo
colorir()

Desenhveis

Crculo
desenhar()

Mveis

Crculo
mover()

Mveis.Vlidos
simplesmente move
a figura

Crculo
mover()

valida coordenadas antes

de mover

Para implementar a aplicao, sujeitos so compostos gerando um

objeto
Regras definem forma como os
sujeitos sero compostos

Pode-se trabalhar com conceitos

simples (domain-specific)

Composio

Crculo
colorir()
desenhar()
mover()

valida coordenadas antes

de mover

218

Soluo: MDSoC: HyperSpaces

Representao de unidades de software em mltiplas dimenses de
interesse
Eixos representam dimenses de interesse
Pontos nos eixos representam interesses
Unidades de software so representadas no espao

Hyperslices

Recurso
Cor

Crculo Retangulo Triangulo

colorir() colorir() colorir()

Movimento

Crculo Retangulo Triangulo

mover() mover() mover()
Crculo Retangulo Triangulo
mover() mover() mover()
Circulo

Retngulo Tringulo

Validao

Aspecto

...

Outras dimenses
de interesse

Encapsulam interesses

Hypermodule

Classe

Conjunto de hyperslices
e relacionamentos de
integrao (informam
como hyperslices se
relacionam entre si)

Neste modelo, aspecto

apenas mais uma dimenso de
interesse
219

Uso de aspectos
Antes
Cliente

Depois
Cliente

Isto feito usando

wildcards sem introduzir
cdigo no objeto

interface
Objeto
interface
Objeto
ObjetoImpl
mtodo() {
bm.start();
corpo do mtodo
bm.stop();
}

ObjetoImpl
bm.start()

Proxy
mtodo()

mtodo()
bm.stop()

220

Concluses
Neste minicurso, introduzimos diversos padres
usados em aplicaes OO

Padres clssicos GoF, que descrevem solues para

problemas comuns, elaborados
Padres GRASP, que descrevem aplicao de princpios OO
Padres e prticas emergentes como injeo de
dependncias (aplicao de uma prtica GRASP) e
aspectos (extenso do OO)

Aprenda a usar os padres clssicos e encurte o

tempo para ganhar tornar-se um programador
experiente!
Vrios outros padres existem e sero inventados
Alguns sobrevivero por muito tempo, outros no
Catalogue suas solues e crie seus prprios padres!

221