Você está na página 1de 24

NOTAS DO PROFESSOR DR.

JACQUES PHILIPPE SAUV COM TEXTO FORMATADO POR JOBSON M.

PADRES DE PROJETOS JAVA

Sumrio
Expert ...................................................................................................................................................... 3 Problema ....................................................................................................................................... 3 Soluo........................................................................................................................................... 3 Exemplo ......................................................................................................................................... 3 Discusso....................................................................................................................................... 4 Consequncias ............................................................................................................................. 5 Tambm conhecido como .......................................................................................................... 5 Creator .................................................................................................................................................... 6 Problema ....................................................................................................................................... 6 Soluo........................................................................................................................................... 6 Exemplo ......................................................................................................................................... 6 Discusso....................................................................................................................................... 7 Consequncias ............................................................................................................................. 7 Baixo Acoplamento ......................................................................................................................... 8 Problema ....................................................................................................................................... 8 Soluo........................................................................................................................................... 8 Exemplo ......................................................................................................................................... 8 Discusso....................................................................................................................................... 9 Consequncias ........................................................................................................................... 13 Alta Coeso............................................................................................................................................ 15 Problema ..................................................................................................................................... 15 Soluo......................................................................................................................................... 15 Exemplo ....................................................................................................................................... 15 Discusso..................................................................................................................................... 16 Consequncias ........................................................................................................................... 19 Controller .............................................................................................................................................. 20 Problema ..................................................................................................................................... 20 Soluo......................................................................................................................................... 20 Exemplo ....................................................................................................................................... 20 Discusso..................................................................................................................................... 21 Consequncias ........................................................................................................................... 23 Responsabilidades, Role Playing e Cartes CRC ...................................................................... 23

Pgina 3 de 24

Expert Problema

Qual o princpio mais fundamental para atribuir responsabilidades?

Soluo

Atribuir uma responsabilidade ao expert de informao - a classe que possui a informao necessria para preencher a responsabilidade

Exemplo

No estudo de caso, alguma classe precisa saber o total de uma venda Podemos dizer isso sobre a forma de uma responsabilidade: Quem deveria ser reponsvel pelo conhecimento do total de uma venda? Pelo padro Expert, escolhemos a classe que possui a informao necessria para determinar o total Considere uma parte do modelo conceitual:

Qual a informao necessria? Precisamos conhecer (ter acesso a) todos os LinhaDetalheVenda Qual information expert? a classe Venda Podemos agora fazer parte do diagrama de colaborao e do diagrama de classes

Ainda no terminamos. Qual informao necessria para determinar o subtotal para um item (uma linha de detalhe)?

Pgina 4 de 24

Precisamos de LinhaDeVenda.quantidade e de EspecificaoDeProduto.preo Quem o information expert? a classe LinhaDeVenda Chegamos aos seguintes diagramas:

Qual o information expert para saber o preo de um produto? EspecificaoDeProduto Chegamos aos seguintes diagramas:

Discusso

o padro mais usado de todos para atribuir responsabilidades A informao necessria frequentemente est espalhada em vrios objetos Portanto, tem muitos experts parciais Exemplo: determinar o total de uma venda requer a colaborao de 3 objetos, em 3 classes diferentes Mensagens so usadas para estabelecer as colaboraes O resultado final diferente do mundo real No mundo real, uma venda no calcula seu prprio total

Pgina 5 de 24

Isso seria feito por uma pessoa (se no houvesse software) Mas no mundo de software, no queremos atribuir essa responsabilidade ao Caixa ou ao TPDV! No mundo de software, coisas inertas (ou at conceitos como uma venda) podem ter responsabilidades: Tudo est vivo!

Consequncias

A encapsulao mantida, j que objetos usam sua prpria informao para cumprir suas responsabilidades Leva a fraco acoplamento entre objetos e sistemas mais robustos e fceis de manter Leva a alta coeso, j que os objetos fazem tudo que relacionado sua prpria informao

Tambm conhecido como


"Colocar as responsabilidades com os dados" "Quem sabe, faz" "Animao" "Eu mesmo fao" "Colocar os servios junto aos atributos que eles manipulam"

Pgina 6 de 24

Creator Problema

Quem deve criar novas instncias de uma classe?

Soluo

Atribuir classe B a responsabilidade de criar instncia da classe A se uma das seguintes condies se aplicar: B agrega objetos da classe A B contm objetos da classe A B registra instncias da classe A B usa muito objetos da classe A B possui os dados usados para inicializar A B um criador (creator) de objetos da classe A Se mais de uma opo se aplica, escolha o B que agregue ou contenha objetos da classe A

Exemplo

No estudo de caso, quem deveria criar uma instncia de LinhaDetalheVenda? Pelo padro Creator, precisamos achar algum que agrega, contm, ... instncias de LinhaDetalheVenda Considere o modelo conceitual parcial abaixo:

Venda agrega instncias de LinhaDetalheVenda e portanto um bom candidato para criar as instncias Chegamos aos seguintes diagramas:

Pgina 7 de 24

Discusso

Escolhemos um criador que deve estar conectado ao objeto criado, de qualquer forma, depois da criao Isso leva a fraco acoplamento Exemplo de criador que possui os valores de inicializao Uma instncia de Pagamento deve ser criada A instncia deve receber o total da venda Quem tem essa informao? Venda Venda um bom candidato para criar objetos da classe Pagamento

Consequncias

Fraco acoplamento, j que o objeto criado deve normalmente ser visvel ao criador, depois da criao.

Pgina 8 de 24

Baixo Acoplamento Problema


Como minimizar dependncias e maximizar o reuso? O acoplamento uma medida de quo fortemente uma classe est conectada, possui conhecimento ou depende de outra classe Com fraco acoplamento, uma classe no dependente de muitas outras classes Com uma classe possuindo forte acoplamento, temos os seguintes problemas: Mudanas a uma classe relacionada fora mudanas locais classe A classe mais difcil de entender isoladamente A classe mais difcil de ser reusada, j que depende da presena de outras classes

Soluo

Atribuir responsabilidades de forma a minimizar o acoplamento

Exemplo

Considere o seguinte diagrama parcial de classes no estudo de caso

Suponha que temos que criar um Pagamento e associ-lo a uma Venda Que classe deveria ter essa responsabilidade? Alternativa 1: No mundo real, um TPDV "registra" um pagamento e o padro Creator sugere que TPDV poderia criar Pagamento TPDV deve ento passar o pagamento para a Venda Veja o resultado abaixo

Alternativa 2: Criar o Pagamento com Venda e associ-lo Venda Veja o resultado abaixo

Pgina 9 de 24

Supondo que a Venda deva ter conhecimento do pagamento (depois da criao) de qualquer jeito, a alternativa 2 tem menos acoplamento (TPDV no est acoplado a Pagamento) Dois padres (Creator e Low Coupling) sugeriram diferentes solues Minimizar acoplamento ganha

Discusso

Minimizar acoplamento um dos princpios de ouro do projeto OO Acoplamento de manifesta de vrias formas: X tem um atributo que referencia uma instncia de Y X tem um mtodo que referencia uma instncia de Y Pode ser parmetro, varivel local, objeto retornado pelo mtodo X uma subclasse direta ou indireta de Y X implementa a interface Y A herana um tipo de acoplamento particularmente forte Uma seo futura esmiua o assunto No se deve minimizar acoplamento criando alguns poucos objetos monstruosos (God classes) Exemplo: todo o comportamento numa classe e outras classes usadas como depsitos passivos de informao Tipos de acoplamentos (do menos ruim at o pior) Acoplamento de dados Acoplamento de controle Acoplamento de dados globais Acoplamento de dados internos Acoplamento de dados Situaes Sada de um objeto entrada de outro Uso de parmetros para passar itens entre mtodos Ocorrncia comum: Objeto a passa objeto x para objeto b Objeto x e b esto acoplados Uma mudana na interface de x pode implicar em mudanas a b Exemplo:

Pgina 10 de 24

class Servidor { public void mensagem(MeuTipo x) { // cdigo aqui x.faaAlgo(Object dados); // dados e x esto acoplados // (se interface de dados mudar x ter que mudar) // mais cdigo } }
o

Exemplo pior: Objeto a passa objeto x para objeto b x um objeto composto ou agregado (contm outro(s) objeto(s)) Objeto b deve extrair objeto y de dentro de x H acoplamento entre b, x, representao interna de x, y Exemplo: ordenao de registros de alunos por matrcula e nome

class Aluno { String nome; long matrcula; public String getNome() { return nome; } public long getMatrcula() { return matrcula; } } // etc.

ListaOrdenada listaDeAlunos = new ListaOrdenada(); Aluno novoAluno = new Aluno(...); //etc. listaDeAlunos.add(novoAluno);

Agora, vamos ver os problemas

class ListaOrdenada { Object[] elementosOrdenados = new Object[tamanhoAdequado]; public void add(Aluno x) { // cdigo no mostrado long matrcula1 = x.getMatrcula(); long matrcula2 = elementosOrdenados[k].getMatrcula(); if(matrcula1 < matrcula2) { // faa algo } else { // faa outra coisa } }

O problema da soluo anterior que h forte acoplamento

Pgina 11 de 24

ListaOrdenada sabe muita coisa de Aluno O fato de que a comparao de alunos feito com a matrcula O fato de que a matrcula obtida com getMatrcula() O fato de que matrculas so long (representao de dados) Como comparar matrculas (com <) O que ocorre se mudarmos qualquer uma dessas coisas? Soluo 2: mande uma mensagem para o prprio objeto se comparar com outro

class ListaOrdenada { Object[] elementosOrdenados = new Object[tamanhoAdequado]; public void add(Aluno x) { // cdigo no mostrado if(x.lessThan(elementosOrdenados[K])) { // faa algo } else { // faa outra coisa } }

Reduzimos o acoplamento escondendo informao atrs de um mtodo Problema: ListaOrdenada s funciona com Aluno Soluo 3: use interfaces para desacoplar mais ainda

Interface Comparable { public boolean lessThan(Object outro); public boolean greaterThan(Object outro); public boolean equal(Object outro); } class Aluno implements Comparable { public boolean lessThan(Object outro) { // compare registro de aluno com outro } } class ListaOrdenada { Object[] elementosOrdenados = new Object[tamanhoAdequado]; public void add(Comparable x) { // cdigo no mostrado if(x.lessThan(elementosOrdenados[K])) { // faa algo } else { // faa outra coisa } }

Pgina 12 de 24

Em C++, teria outras solues Apontador de funo Apontador de funo com tipos genricos (templates) Acoplamento de controle Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto Ocorrncia comum: Objeto a manda uma mensagem para objeto b b usa um parmetro da mensagem para decidir o que fazer
o

class Lampada { public static final ON = 0; public void setLampada(int valor) { if(valor == ON) { // liga lampada } else if(valor == 1) { // desliga lampada } else if(valor == 2) { // pisca } }

Lampada lampapa = new Lampada(); lampada.setLampada(Lampada.ON); lampada.setLampada(2);


o

Soluo: decompor a operao em mltiplas operaes primitivas

class Lampada { public void on() { // liga lampada } public void off() { // desliga lampada } public void pisca() { // pisca } } Lampada lampada = new Lampada(); lampada.on(); lampada.pisca();
o

Ocorrncia comum: Objeto a manda mensagem para objeto b b retorna informao de controle para a Exemplo: retorno de cdigo de erro

class Teste { public int printFile(File toPrint) {

Pgina 13 de 24

if(toPrint est corrompido ) { return CORRUPTFLAG; } // etc. etc. } }

Teste umTeste = new Teste(); int resultado = umTese.printFile(miniTeste); if(resultado == CORRUPTFLAG) { // oh! oh! } else if(resultado == -243) { // etc. etc.
o

Soluo: use excees

class Teste { public int printFile(File toPrint) throws PrintExeception { if(toPrint est corrompido ) { throw new PrintExeception(); } // etc. etc. } } try { Teste umTeste = new Teste(); umTeste.printFile(miniTeste); } catch(PrintException printError) { // faa algo }

Acoplamento de dados globais Dois ou mais objetos compartilham estruturas de dados globais um acoplamento muito ruim pois est escondido Uma chamada de mtodo pode mudar um valor global e o cdigo no deixa isso aparente Um tipo de acoplamento muito ruim Acoplamento de dados internos Um objeto altera os dados locais de um outro objeto Ocorrncia comum: Friends em C++ Dados protected ou pblicos de java Use com cuidado!

Consequncias

Pgina 14 de 24

Uma classefracamente acoplada no afetada (ou pouco afetada) por mudanas em outras classes Simples de entender isoladamente Reuso mais fcil

Pgina 15 de 24

Alta Coeso Problema


Como gerenciar a complexidade? A coeso mede quo relacionados ou focados esto as responsabilidades da classe Tambm chamado coeso funcional (ver frente) Uma classe com baixa coeso faz muitas coisas no relacionadas e leva aos seguintes problemas: Difcil de entender Difcil de reusar Difcil de manter "Delicada": constantemente sendo afetada por outras mudanas Uma classe com baixa coeso assumiu responsabilidades que pertencem a outras classes e deveriam ser delagadas

Soluo

Atribuir responsabilidades que mantenham alta coeso

Exemplo

Mesmo exemplo usado para Low Coupling Na primeira alternativa, TPDV assumiu uma responsabilidade de efetuar um pagamento (mtodo faaPagamento())

At agora, no h problema Mas suponha que o mesmo ocorra com vrias outras operaes de sistema TPDV vai acumular um monte de mtodos no muito focados Resultado: baixa coeso A segunda alternativa delega faaPagamento() para a classe Venda Mantm maior coeso em TPDV

Pgina 16 de 24

Discusso

Alta coeso outro princpio de ouro que deve ser sempre mantido em mente durante o projeto Tipos de coeso entre mdulos Coincidental (pior) Lgico Temporal Procedural De comunicao Sequencial Funcional (melhor) Coeso coincidental H nenhuma (ou pouca) relao construtiva entre os elementos de um mdulo No linguajar OO: Um objeto no representa nenhum conceito OO Uma coleo de cdigo comumente usado e herdado atravs de herana (provavelmente mltipla)

class Angu { public static int acharPadro(String texto, String padro) { // ... } public static int mdia(Vector nmeros) { // ... } public static outputStream abreArquivo(string nomeArquivo) { // ... } } class Xpto extends Angu { // quer aproveitar cdigo de Angu ... }

Coeso lgica Mdulo faz um conjunto de funes relacionadas, uma das quais escolhida atravs de um parmetro ao chamar o mdulo Semelhante a acoplamento de controle Cura: quebrar em mtodos diferentes

public void faa(int flag) { switch(flag) { case ON: // coisas para tratar de ON break; case OFF:

Pgina 17 de 24

// coisas para tratar de OFF break; case FECHAR: // coisas para tratar de FECHAR break; case COR: // coisas para tratar de COR break; }

Coeso temporal Elementos esto agrupados no mesmo mdulo porque so processados no mesmo intervalo de tempo Exemplos comuns: Mtodo de inicializao que prov valores defaults para um monte de coisas diferentes Mtodo de finalizao que limpa as coisas antes de terminar

procedure inicializaDados() { font = "times"; windowSize = "200,400"; xpto.nome = "desligado"; xpto.tamanho = 12; xpto.localizao = "/usr/local/lib/java"; }
o

Cura: depender de construtores e destrutores

class Xpto { public Xpto() { this.nome = "desligado"; this.tamanho = 12; this.localizao = "/usr/local/lib/java"; } }
o

Outro exemplo: arquivo de configurao tpico

[Macintosh] EquationWindow=146,171,406,661 SpacingWindow=0,0,0,0 [Spacing] LineSpacing=150% MatrixRowSpacing=150% MatrixColSpacing=100% SuperscriptHeight=45%

Pgina 18 de 24

SubscriptDepth=25% LimHeight=25% LimDepth=100% LimLineSpacing=100% NumerHeight=35% DenomDepth=100% FractBarOver=1pt FractBarThick=0.5pt SubFractBarThick=0.25pt FenceOver=1pt SpacingFactor=100% MinGap=8% RadicalGap=2pt EmbellGap=1.5pt PrimeHeight=45% [General] Zoom=200 CustomZoom=150 ShowAll=0 Version=2.01 OptimalPrinter=1 MinRect=0 ForceOpen=0 ToolbarDocked=1 ToolbarShown=1 ToolbarDockPos=1 [Fonts] Text=Times Function=Times Variable=Times,I LCGreek=Symbol,I UCGreek=Symbol Symbol=Symbol Vector=Times,B Number=Times [Sizes] Full=12pt Script=7pt ScriptScript=5pt Symbol=18pt SubSymbol=12pt

Coeso procedural Associa elementos de acordo com seus relacionamentos procedurais ou algortmicos Um mdulo procedural depende muito da aplicao sendo tratada

Pgina 19 de 24

Junto com a aplicao, o mdulo parece razovel Sem este contexto, o mdulo parece estranho e muito difcil de entender "O que est acontecendo aqui!!!????!!" No pode entender o mdulo sem entender o programa e as condies que existem quando o mdulo chamado Cura: reprojete o sistema Coeso de comunicao Todas as operaes de um mdulo operam no mesmo conjunto de dados e/ou produzem o mesmo tipo de dado de sada Cura: isole cada elemento num mdulo separado "No deveria" ocorrer em sistemas OO usando polimorfismo (classes diferentes para fazer tratamentos diferentes nos dados) Coeso sequencial A sada de um elemento de um mdulo serve de entrada para o prximo elemento Cura: decompor em mdulos menores Coeso funcional (a melhor) Um mdulo tem coeso funcional se as operaes do mdulo puderem ser descritas numa nica frase de forma coerente Num sistema OO: Cada operao na interface pblica do objeto deve ser funcionalmente coesa Cada objeto deve representar um nico conceito coeso Exemplo: um objeto que esconde algum conceito ou estrutura de dados ou recurso e onde todos os mtodos so relacionados por um conceito ou estrutura de dados ou recurso Meyer chama isso de "information-strength module"

Consequncias

Melhor claridade e facilidade de compreenso do projeto Simplificao da manuteno Frequentemente vai mo na mo com acoplamento fraco Com granularidade baixa e funcionalidade bem focada, aumenta o reuso

Pgina 20 de 24

Controller Problema

Quem deveria receber a responsabilidade de tratar eventos do sistema? Um evento do sistema um evento de alto nvel gerado por um ator externo Esto associados a operaes do sistema que j vimos nos Diagramas de Sequncia do Sistema Exemplo do estudo de caso: Caixa pressiona "Fim de venda"

Soluo

Use um controlador Um controlador um objeto que no de interface GUI responsvel pelo tratamento de eventos do sistema Um controlador define mtodos para as operaes do sistema Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo: Representa o "sistema" como um todo (facade controller) Representa o negcio ou organizao como um todo (facade controller) Representa algo no mundo real que ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller) Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "<NomeDoUseCase>Handler" (use case controller)

Exemplo

No estudo de caso, h vrias operaes de sistema:

Quem deveria ser o controlador para os eventos do sistema?

Pelo padro Controller, temos as seguintes alternativas:

Pgina 21 de 24

Representa o "sistema": TPDV Representa o negcio ou organizao: Loja Representa algo no mundo real ...: Caixa Representa um handler artificial ...: CompraItemHandler A escolha particular depende de fatores discutidos na seo Discusso Por exemplo, se fosse TPDV, teramos:

Discusso

De forma geral, o mesmo controlador deve ser usado para todas as operaes de um mesmo Use Case de forma a manter a informao de estado do Use Case A informao de estado pode ser til para detectar sequncias erradas de eventos de sistema Exemplo: faaPagamento() antes de fimDeVenda() No coloque toda a inteligncia no controlador Delegue para outros objetos,para manter coeso Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coeso baixa Quando est surgindo um "God class" Usado em sistemas mais complexos Observe que classes "Window", "Applet", "Application", "View", "Document" no devem ser controladores Tais classes podem receber o evento e deleg-lo ao controlador No se deve colocar business logic num objeto de interface com o usurio Um design correto seria:

Pgina 22 de 24

Um design incorreto seria:

Pgina 23 de 24

O Role Controller pode levar a um mau projeto O fato de algo ser feito por uma pessoa no mundo real no necessariamente significa que isso uma boa alternativa em software mais comum "dar vida aos objetos" (no animados)

Consequncias

Maior possibilidade de reuso, j que o business logic no est nos objetos de interface Exemplo: embutir o business logic num objeto de interface no permitiria fazer EAI (Enterprise Application Integration) Ajuda a verificar o sequenciamento das operaes do sistema, atravs do estado do controlador

Responsabilidades, Role Playing e Cartes CRC


Embora no faa parte de UML, uma tcnica chamada Cartes CRC muito usada para atribuir responsabilidades durante o projeto; CRC = Class-Responsibility-Collaborations CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix) Carto CRC um carto pequeno (para s escrever o essencial) para cada classe Escreve-se o nome da classe, suas responsabilidades e colaboraes S pense nas responsabilidades de alto nvel

So desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes Mais detalhes aqui: Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990. Algumas pessoas acham que melhor usar ferramentas grficas em vez de CRC

Pgina 24 de 24

Você também pode gostar