Padres GRASP

Padres bsicos Information Expert Creator High Cohesion Low Coupling ControllerPadres 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 sobreSalesLineItems (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 muitosSalesLineItems

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.

187

Este mtodo precisa ser definido em Sale

Fonte: [4]

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 sistemaassociados com eventos do sistema.

196

Controller: problema

197

Controller: soluo

A primeira soluo representa o sistema inteiroA segunda soluo representa o destinatrio ou

handler de todos os eventos de um caso de uso

198

O diagrama acima no mostra o Controller, mas a transparncia da comunicao (chamada do cliente, objeto que recebe a mensagem)

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 Em vez de

Use

A B

AintefaceInterB B

A depende de BA precisa achar ou criar B

class A {InterB b;A(InterB b) {

this.b = b;}

}A depende de uma interface IBB depende de uma interface IBA recebe implementao de B quando criado

class A {B b = new 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

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.

AintefaceInterB SimulatedBATest

AintefaceInterBATest

205

Dependency Injection

Problema Controle convencional: o prprio objeto cria ou

localiza suas dependncias: acoplamento!

CertificacaoProgramadorJava

ProgramadorJavanome: Stringcertificacao:CertificacaoProgramadorJavainscrever(): Certificado

CertificacaoArquitetoJ2EE

newCertificacaoProgramadorJava()

JNDIlookup(certificacaoSCEA)

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 questoes8: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 questoes8: 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

CertificacaoProgramadorJava

ProgramadorJavanome: Stringcertificacao:CertificacaoProgramadorJavainscrever(): CertificadosetCertificacao(Certificacao);

programador.setCertificacao(this)

programador.setCertificacao(certJ2EE)

CertificacaoArquitetoJ2EE

Certificacao

210

Inverso de controle

public interface Programador {public Object inscrever() throws NaoAprovadoException;

}

211

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:}

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

213

Figuramover()desenhar()

Tringulomover()desenhar()

Crculomover()desenhar()

Retngulomover()desenhar()

validarCoords()// cdigo p/ moverlogarAcao()

// cdigo p/ desenharlogarAcao()

mover()

desenhar()

Aspectos genricosPoderiam ser usados em

outras aplicaes

Caractersticas mover() e desenhar() poderiam serreutilizadas em outros

objetos

Problema: scattering e tangling

214

public class VeiculoAereoextends Veiculo {

public void abastecer() {// cdigoLogger.log(nome() +

" abastecido com " + x + " litros");

// cdigo} ...

}

public class VeiculoPassageiroextends Veiculo {

public void abastecer() {super.abastecer() + gasolina;Logger.log(nome() +

" abastecido com gasolina");} ...

} public class VeiculoCargaextends Veiculo {public void abastecer() {

super.abastecer() + diesel;Logger.log(nome() +

" abastecido com diesel");} ...

}

Scattering: acrescentar umrequerimento causa

espalhamento do cdigoem vrias classes

Tangling: cdigo para implementar o requerimento

se mistura com lgica do cdigo existente

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 VeiculoPassageiroextends Veiculo {

public void abastecer() {...}public void carregar() {...}public Apolice segurar() {

Apolice a = new Apolice(...);

// preenche apolice basicareturn a;

}...

} 215

public class VeiculoCargaextends Veiculo {

public void abastecer() {...}public Apolice segurar() {

Apolice a = new Apolice();// preenche apolice p/// segurar carro e cargareturn a;

}public void carregar() {...}...

}

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 problemaVeiculoCarga v =

VeiculoCarga.create();

mas sua interface precisariaser planejada antes!

216

package veiculos;public class VeiculoCarga

extends Veiculo {public void abastecer() {

super.abastecer()+ diesel;

}}

package veiculos.versao2;public class VeiculoCarga2extends veiculos.VeiculoCarga {public void abastecer() {

super.abastecer() + diesel;Logger.log(nome() + " abastecido com diesel");

}public Apolice segurar() {...}

}

Soluo: Aspect-Oriented Programming

217

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)

Classes

Aspectos

Interesses dodomnio

Weaver

JoinPoints

Aplicao

Soluo: Subject-Oriented Programming

218

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

Para implementar a aplicao, sujeitos so compostos gerando um objeto

Regras definem forma como os sujeitos sero compostos

Pode-se trabalhar com conceitossimples (domain-specific)

Crculomover()

Crculomover()

Crculodesenhar()

valida coor-denadas antes de mover

simples-mente movea figura

Crculocolorir()

Coloridos Desenhveis Mveis Mveis.Vlidos

Crculocolorir()desenhar()mover()

Composio

valida coor-denadas antes de mover

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

219

Hyperslices Encapsulam interesses

Hypermodule Conjunto de hyperslices

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

Neste modelo, aspecto apenas mais uma dimenso de interesse

Validao

Cor Crculocolorir()

Retangulo

colorir()Triangulo

colorir()

Movimento Crculomover()

Retangulo

mover()Triangulo

mover()

Aspecto

Circulo Retngulo Tringulo

Classe

Recurso

Outras dimensesde interesse

...

Crculomover()

Retangulo

mover()Triangulo

mover()

Uso de aspectos

Antes Depois

Cliente

220

Cliente

bm.start()

Isto feito usando wildcards sem introduzir

cdigo no objetointerface

Objeto

ObjetoImpl

mtodo()

interfaceObjeto

Proxy

mtodo() bm.stop()

ObjetoImpl

mtodo() {bm.start();corpo do mtodobm.stop();}

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