Padres de Projeto:

Facade & Command

Instituto Federal Fluminense Campus Campos-Centro Aluno(a): Yasmmin Crtes Martins. Data: 01/10/2012 Anlise e desenvolvimento de sistemas. Noite. 5 Perodo.

Sumrio
1. Introduo..............................................................................................................5 2. Objetivo e Problema..............................................................................................5 2.1. Facade.............................................................................................................5 2.2. Command........................................................................................................6 3. Motivao e Aplicao..........................................................................................9 3.1. Facade.............................................................................................................9 3.2. Command........................................................................................................9 4. Soluo.................................................................................................................11 4.1. Facade...........................................................................................................11 4.2. Command......................................................................................................13 5. Consequncias.....................................................................................................14 5.1. Facade...........................................................................................................14 5.2. Command......................................................................................................15 6. Participantes.........................................................................................................15 6.1. Facade...........................................................................................................16 6.2. Command......................................................................................................16 7. Colaboraes........................................................................................................17 7.1. Facade...........................................................................................................17 7.2. Command......................................................................................................17 8. Exemplos de cdigo.............................................................................................18 8.1. Facade...........................................................................................................18 8.2. Command......................................................................................................21 9. Concluses...........................................................................................................23 10. Referncias...........................................................................................................23

ndice de figura
Figura 1 - Exemplo de diagrama de classes para mostrar um dos problemas solucionados pelo padro Facade......................................................................................6 Figura 2 - Classe Lanchonete do sistema de exemplo usado para apresentar o problema solucionado pelo padro Command..................................................................................7 Figura 3 - Classe Conta do sistema de exemplo usado para apresentar o problema solucionado pelo padro Command..................................................................................8 Figura 4 - Modo de resolver o problema s que de forma no muito eficiente, com vrias condicionais aninhadas...........................................................................................9 Figura 5 - Ilustrao do princpio de organizao do sistema com o padro Facade......10 Figura 6 - Ilustrao de uma classe abstrata Command com os possveis mtodos assinados..........................................................................................................................11 Figura 7 - Exemplo de uma classe fachada para o problema da seo 2.........................12 Figura 8 - Imagem do cdigo da interface criada para implementao da soluo prevista no padro............................................................................................................13 Figura 9 - Ilustrao da nova verso do mtodo executar_pagConta()...........................13 Figura 10 - Ilustrao da implementao do mtodo que foi assinado na interface para o caso de pagamento vista...............................................................................................14 Figura 11 - Ilustrao de como chamar o mtodo que invocar a ao desejada............14 Figura 12 - Estrutura do padro Facade...........................................................................16 Figura 13 - Estrutura em diagrama de classes do padro Command...............................16 Figura 14 - Ilustrao das interaes entre os objetos no diagrama de sequncia...........18 Figura 15 - Exemplo de cdigo da classe Fachada para o sistema de compras virtual...19 Figura 16 - Classe de sistema do sistema de compras virtual do exemplo......................19 Figura 17 - Classe de banco de dados do sistema de compras virtual do exemplo........20 Figura 18 - Classe de cliente do sistema de compras virtual de exemplo.......................20 Figura 19 - Classe de carrinho do sistema de compras virtuais de exemplo...................21 Figura 20 - Classe de produto do sistema de compras virtuais de exemplo....................21 Figura 21 - Ilustrao da classe livro do contexto...........................................................22

Figura 22 - Ilustrao da classe abstrata e as classes que implementam o mtodo execute()..........................................................................................................................22 Figura 23 - Ilustrao do mtodo com o objeto que invocar o execute()......................23 Figura 24 - Ilustrao da chamada do comando..............................................................23

1. Introduo
Os padres de projeto que sero relatados neste trabalho pertencem a dois grupos diferentes, o Facade aos padres estruturais e o Command aos comportamentais. Os padres estruturais tratam de problemas que podem ocorrer no projeto envolvendo associaes entre classes e objetos, e os comportamentais tratam de problemas que podem ocorrer que podem ocorrer nas interaes e na delegao de responsabilidades entre as classes ou objetos. Os componentes bsicos de todo padro de projeto, como o contexto do problema, a motivao, a aplicabilidade e os participantes, sero explanados nas prximas sees, mas estes tipos de padres so bastante comuns e podem utilizados para vrias aplicaes de diversos contextos. O Facade tem como finalidade bsica reduzir a complexidade da modelagem do sistema, usando uma classe fachada que ao ser acionada por seus mtodos faz ligaes que no so visveis ao usurio para outras classes dos sub-sistemas, para fazer a ao requerida, ou seja a inteno fazer as aes atravs de classes de alto nvel sem precisar saber o conjunto de procedimentos correspondentes a estas aes. O Command tem como finalidade evitar a repetio de trechos de cdigos relativo a funcionalidades que so oferecidas em interfaces grficas diferentes, para evitar programar uma determinada ao quantas vezes forem as opes de se faz-la em lugares diferentes do sistema, este padro prev uma soluo. Alm de permitir armazenar os comandos dados, podendo registrar os logs e permitir desfazer e refazer operaes.

2. Objetivo e problema
Os dois padres pertencem a classificaes diferentes resolvem problemas de contextos diferentes, portanto cada um ser relatado em um tpico distinto. 2.1. Facade

Muitas vezes, quando se tem aplicaes com diversas classes na camada de negcios que dependem de mtodos e at de outras classes, para fazer aes mais detalhadas, e quando no se usa uma classe de fachada comum para delegar e distribuir os mtodos s outras classes de uma camada mais inferior, isso acaba trazendo um forte acoplamento, ou seja, uma forte dependncia entre as funes e mtodos em relao s classes. Por exemplo, supondo um sistema que tenha o seguinte esboo:

Figura 1 - Exemplo de diagrama de classes para mostrar um dos problemas solucionados pelo padro Facade.

O tpico sistema de locadora (na figura 1), numa forma simples, com apenas quatro classes, supondo que na camada de visualizao a pessoa queira fazer o aluguel, ela escolhe os filmes e quando clica em salvar, acionado a parte que fica na camada de negcio, que trata a comunicao com o banco de dados, e neste caso ele precisa fazer atualizaes e inseres em pelo menos trs objetos das classes de Cliente (vai ficar na situao pendente) e vai adicionar em Item_aluguel e Aluguel. Para um nico aluguel ele ter de utilizar os trs objetos e vai ter que tratar das instanciaes assim como a validao e, se caso ter algum problema em alguma das operaes no banco, dar rollback (desfazer a ao) nas que conseguiram mas na verdade dependiam do sucesso das outras. O problema que por estar em um jeito distribudo concentrando todas as operaes, pode ser que haja outras regras a serem tratadas e ento quanto mais for adicionada mais operaes devem ser feitas podendo tornar o cdigo menos transparente e difcil. Logo, na implementao a invs de ter que fazer e tratar os trs fazendo trs caminhos para inserir, pelo padro Facade poderia instanciar um objeto s, que ter um mtodo e nico caminho para fazer a solicitao, a fachada teria a misso de esconder a complexidade desta funcionalidade Registrar aluguel. 2.2. Command

Em alguns casos de desenvolvimento uma determinada etapa pode ser feita de mais de uma forma diferente, mas a funcionalidade da etapa a mesma para todos os tipos. Por exemplo, supondo o pagamento da conta de uma lanchonete, pode ser a mesma ao de pagamento porm por enquanto a lanchonete s aceita vista, neste caso. Abaixo sero colocados exemplos de cdigos para esta situao, as classes necessrias (como Lanchonete (supondo um sistema nica prprio para este estabelecimento) e Conta) com os mtodos. H outras classes, como bebidas, lanches,
6

funcionrios e guloseimas, mas a parte principal ser o processo de pagamento por isso foram omitidas. Para resolver esta situao sem usar a soluo prevista por este padro seria necessrio usar estes blocos de cdigo, muito simples:

Figura 2 - Classe Lanchonete do sistema de exemplo usado para apresentar o problema solucionado pelo padro Command.

Esta classe (da figura 2) pode ter outros atributos como inscrio estadual, endereo, cep, telefone, e-mail, etc. mas para simplificar s colocamos o principal que o nome do estabelecimento, que ser usado para compor a nota fiscal. E abaixo (na figura 3) est uma outra classe que servir para armazenar dados para emisso da nota fiscal do estabelecimento.

Figura 3 - Classe Conta do sistema de exemplo usado para apresentar o problema solucionado pelo padro Command.

Como, a princpio, o estabelecimento no quis usar outra forma de pagamento seno vista, no precisamos nos preocupar em processar a compra de acordo com os diversos tipos de cartes. Porm se ao longo do crescimento de movimento da lanchonete o dono resolver adaptar a forma de pagamento, conforme o gosto de seus clientes, ser necessrio adaptar tambm o mtodo executar_pagConta. A forma de fazer isso sem usar a soluo prevista no padro Command seria acrescentar um parmetro neste mtodo, referente forma de pagamento, e ir verificando atravs de condicionais. O parmetro poderia ser como no exemplo, com um simples objeto da classe String, ou poderia ser uma instncia de um Enumeration, que pode ser uma forma agregar sub-valores a um atributo de uma classe (por exemplo, supondo uma classe usurio, existem alguns nveis de privilgio, que so os subtipos do atributo nvel, ou seja, pode ser nvel.admin, nvel.root, nvel.user, que seriam definidos em public enum Nivel {ADMIN, MOD, USER } e teria um objeto privado do tipo Nivel que seria setado pelos objetos com o nvel de privilgios).

Figura 4 - Modo de resolver o problema s que de forma no muito eficiente, com vrias condicionais aninhadas.

Esta forma de resoluo apesar de funcionar tem problemas como uma alta dependncia das classes participantes, quantidades de condicionais que vo crescendo conforme novas opes surjam, necessidade de alteraes locais, etc. Este o principal contexto em que o padro Command pode entrar como uma forma eficaz de resolver estes problemas, fazer com que as classes que invocaram este mtodo no precisem saber das que esto realmente implementando os mtodos. Ento, segundo o padro Command haveria uma interface ou classe abstrata com o mtodo execute, podendo ou no ter parmetros, neste caso o mtodo a ser invocado e que ser implementado por classes diferentes processarPag com o parmetro do objeto da classe Conta. E no parmetro passaria um objeto da interface/classe abstrata Command, com a instncia do objeto da classe que realmente far a operao.

3. Motivao e aplicao
Estes padres possuem suas razes para serem usados em alguns momentos do desenvolvimento do projeto de software. A seguir esto algumas das razes de se usar os padres Facade e Command e os possveis contextos em que elas se inserem. 3.1. Facade

Normalmente um sistema possui diversos blocos funcionais, ou subsistemas, com diversas classes e suas operaes, porm podemos organizar as chamadas e encapsul-las em mtodos numa classe Fachada, o que significa simplificar a quem usar a classe Fachada e tornar o sistema em si menos complexo.

Assim ter funcionalidades gerais que deixam as da camada de subsistema omitidas, porm estaro l caso precisem ser alteradas. s uma forma simples de organizar o sistema.

Figura 5 - Ilustrao do princpio de organizao do sistema com o padro Facade.

Alm disso, a Facade tem o papel de diminuir a dependncia entre o cliente e os componentes de subsistema, tornando ele mais portvel em diversos casos. Alm de, se for preciso, poder inserir mais funcionalidades gerais na Facade, tornando-se mais simples este trabalho pois s precisa mexer na classe Facade no nas de subsistema, pode-se por quantas funcionalidades for preciso. Outra razo pode ser usar Facades para definir camadas de acesso entre os subsistemas, deixando os pontos de entrada para os mesmos somente nas Facades que representa um conjunto deles. E se eles forem dependentes entre si, a comunicao ficar simplificada com a ajuda das funcionalidades gerais de suas Facades. 3.2. Command

H vrias ocasies em que o padro Command pode ser usado, pois ele tem vrios objetivos. De forma geral, sua motivao e aplicabilidade se resumem em situaes que precisem encapsular invocaes/solicitaes a objetos, permitindo parametrizar clientes que possuem diversas solicitaes, enfileirar ou fazer o registro do histrico (log) de solicitaes e suportar operaes que possam ser desfeitas. Quanto parametrizao de objetos por uma ao que ser executada (como o mtodo executar_pagConta), isso numa linguagem procedural como Delphi e C, equivale ao funcionamento das funes de CallBack, ou seja, uma funo que feita em algum momento do cdigo e que ser utilizada em outro lugar em algum momento posterior. Os commands so os substitutos das CallBacks na orientao a objeto. Quanto ao fato de poder especificar, enfileirar e executar solicitaes em tempos diferentes, um objeto Command pode ter um tempo de vida diferente independente da solicitao original (isso significa que o objeto no morre logo aps realizar a operao requisitada). Isso possvel pois se o receptor de uma solicitao pode ser
10

representado de uma forma independente do espao de endereamento, ento possvel transferir um objeto Command para um processo diferente e l atender alguma outra solicitao. Quanto ao fato de suportar desfazer operaes, a operao execute(), assinada na interface ou classe abstrata Command, pode armazenar estados para reverter seus efeitos no prprio comando. E a interface de Command pode ter outro mtodo assinado, o unexecute(), que reverte os efeitos de uma chamada anterior de execute(). Os comandos executados precisam ser armazenados numa lista que servir de histrico, permitindo um nvel ilimitado de operaes de refazer e desfazer, pois esta lista ser percorrida de para frente (em refazer()) e para trs (em desfazer()), chamando operaes unexecute() e execute(), respectivamente. Quanto ao fato de enfileirar e manter o histrico (log) de solicitaes de forma que possam ser recarregadas caso haja um problema no sistema, ao acrescentar mais duas operaes assinadas na interface/classe abstrata Command, carregar() e armazenar(), pode-se manter o registro (log) das mudanas que ocorreram. A recuperao de uma queda de sistema envolve a invocao dos comandos registrados a partir do disco e sua nova execuo com a operao execute(). Um exemplo de como fica ao final uma classe abstrata com todos estes mtodos abstratos assinados est mostrado na figura abaixo, a diferena que as que implementarem usaram extends ao invs de implements.

Figura 6 - Ilustrao de uma classe abstrata Command com os possveis mtodos assinados.

Pode-se tambm usar o padro para estruturar um sistema em torno de operaes de alto nvel construda sobre operaes primitivas. Este tipo de estrutura comum em sistemas de informao que suportam transaes que encapsulam um conjunto de mudanas nos dados. O padro Command fornece uma maneira de modelar transaes, os Commands, por terem interface comum, permitem invocar todas as transaes da mesma maneira.

4. Soluo
Bom, foram propostos dois problemas na seo 2, um envolvendo cada padro, ento abaixo sero apresentadas possveis solues para eles, em trechos de cdigos e algumas linhas de explicao.
11

4.1.

Facade

Para resolver a questo do registro de aluguel, que precisava atualizar 4 classes, e para evitar instanciar objetos diretamente no cdigo principal da aplicao, pode-se usar uma classe Facade que ter mtodos de alto nvel, e neles ficaram encapsuladas as chamadas para as classes necessrias. Uma soluo seria a da figura abaixo.

Figura 7 - Exemplo de uma classe fachada para o problema da seo 2.

12

Ento na classe Fachada s teve um mtodo registrar com os parmetros necessrios para cadastrar o aluguel, o cdigo de identificao do cliente, o valor total do aluguel e a lista com os cdigos de identificao dos filmes alugados, vindas da camada de viso do sistema, por exemplo. Alm deste mtodo podem ser agregados os outros, como atualizar, excluir e consultar. Mas para exemplo s foi colocado o caso de cadastro. Pode-se perceber, que simplificou bastante a chamada, encapsular as validaes e as aes a serem tomadas caso alguma das operaes no banco envolvendo as entidades no d certo. No caso os mtodos so de exemplo, e a mensagem de erro pode estar num JOptionPane ou na funo alert() do Javascript, caso o sistema seja feita no ambiente java para web. 4.2. Command

Para resolver o problema levantado na continuao do processo de pagamento da conta usando trs formas possveis, usa-se o que est previsto no padro que a criao de uma interface Command que ter o mtodo em questo que ser implementado de acordo com os procedimentos de cada classe responsvel pelos tipos diferentes de pagamento. Abaixo est a interface usada.

Figura 8 - Imagem do cdigo da interface criada para implementao da soluo prevista no padro.

Alm disso, houve uma modificao na no parmetro do mtodo usado pela classe Lanchonete para invocar a ao processarPag, agora o parmetro um objeto da interface Command_pag e este objeto usado para chamar o mtodo assinado na interface e que foi implementado nas classes das formas de pagamento. Abaixo encontra-se o cdigo da nova verso do mtodo executar_pagConta.

Figura 9 - Ilustrao da nova verso do mtodo executar_pagConta().

13

E por fim, as classes responsveis por implementar o mtodo da interface, na figura abaixo mostrado o mtodo completo para o caso de pagamento vista e a ligao da classe com a interface atravs do implements. As outras classes de pagamento tambm seguiro a mesma ideia porm o contedo do mtodo ser adaptado a cada tipo.

Figura 10 - Ilustrao da implementao do mtodo que foi assinado na interface para o caso de pagamento vista.

Na hora de chamar este mtodo, aps criar o objeto de Lanchonete, s passar o valor da conta e o objeto da classe responsvel pelo pagamento, como na figura abaixo.

Figura 11 - Ilustrao de como chamar o mtodo que invocar a ao desejada.

Como visto, simples implementar o padro, o mtodo da interface ao ser implementado pode chamar outros mtodos de outras classes se precisar, os invocadores que o chamam podem ser tambm itens de menu, os receptores podem ser quaisquer classes que saibam fazer as operaes requisitadas.

5. Consequncias
Os dois padres trazem efeitos para o sistema quando implementados, a seguir esto descritos alguns possveis efeitos que podero ser percebidos aps a utilizao dos padres. 5.1. Facade

O padro Facade separa a classe cliente das dos componentes de sub-sistema (o cliente pode ser as classes do setor de viso do sistema diretamente ou outras classes que possam acessar os mtodos gerais previstos na Fachada), assim reduzindo o nmero de objetos que o cliente precisar usar e fazer com que os componentes de subsistema sejam mais fceis de usar.
14

Ele promove um baixo acoplamento (ligao/dependncia) entre o subsistema e os clientes. Frequentemente os componentes num subsistema so fortemente acoplados. O baixo acoplamento permite a variao das classes de subsistema sem afetar os clientes. Fachadas ajudam a dispor em camadas um sistema e as dependncias entre objetos. Elas podem eliminar dependncias complexas ou circulares. Essa pode ser uma consequncia muito importante quando os clientes e o subsistema so implementados e forma independente. Reduzir as dependncias de compilao essencial em sistemas de software grandes. Usar Fachadas permite que o tempo diminua na recompilao de classes de subsistemas alteradas, pois elas reduzem as dependncias e ento limitam a recompilao necessria para uma mudana pequena em um importante subsistema. Uma fachada pode tambm simplificar a migrao de sistemas para outras plataformas, pois menos provvel que a construo de um subsistema requeira a construo de todos os outros. Ela no previne aplicaes de usar as classes se elas precisarem, assim pode-se escolher entre facilidade de uso das fachadas e o acesso direto em algum momento aos mtodos das classes de subsistema. 5.2. Command

O padro Command desacopla o objeto que invoca a operao do que sabe como faz-la, ou seja, desliga os que possuem os dados dos que sabem o que fazer com eles. Commands so objetos de 1 classe, ou seja, eles podem ser manipulados e estendidos como quaisquer outros objetos. Um comando pode ser composto por outros comandos. Em geral, comandos compostos so uma instncia do padro Composite. fcil adicionar novos Commands, pois no necessrio mudar classes existentes.

6. Participantes

15

Para cada padro h participantes, ou seja, classes que faro parte da estrutura dele na sua implementao em cdigo. Abaixo se encontram o diagrama de classe e/ou diagrama de sequncia de cada um. 6.1. Facade

Abaixo est a estrutura geral do padro Facade:

Figura 12 - Estrutura do padro Facade.

Seguindo a estrutura acima, os participantes neste padro so basicamente a Facade (Fachada) e as subsystem classes (classes de subsistema). A facade (fachada) o que sabe quais classes de subsistema so responsveis por determinada requisio e delega as requisies do cliente para os objetos de subsistema apropriados. Exemplo: Facade_aluguel. As classes de subsistema implementam as funcionalidades de subsistema; lida com o trabalho atribudo pelo objeto da fachada e no tm conhecimento da fachada, ou seja, eles no mantm referncia a ela. Exemplo: Aluguel, Cliente, Item_aluguel. 6.2. Command

Abaixo est a estrutura geral, em diagrama de classes, do padro Command:

Figura 13 - Estrutura em diagrama de classes do padro Command.

16

Seguindo a estrutura acima, os participantes so Command, ConcreteCommand, Client, Invoker e Receiver. O Command a interface ou classe abstrata que contm a operao e ser executada por quem implementar. Exemplo: Command_pag. O ConcreteCommand implementa o mtodo da interface ou classe abstrata, e caso precise usar mtodos de outras classes dentro do mtodo implementado para fazer alguma ao, define uma ligao entre o objeto da classe receiver (receptora) e uma ao. Exemplo: PagamentoAvista, PagamentoCartaoDebito e PagamentoCartaoCredito. Client (cliente) o que cria um objeto de ConcreteCommand e seta o receiver (receptor). Exemplo: a tela de aplicao onde ser usado o padro, Lanchonete. Invoker (invocador) o que pede o comando para executar a requisio. Exemplo: O objeto passado por parmetro que ativa o mtodo da interface em Executar_pagConta. Receiver (Receptor) o que sabe como realizar as operaes associadas com a execuo de uma requisio. Qualquer classe pode servir como receptora. Exemplo: PagamentoAvista, PagamentoCartaoDebito e PagamentoCartaoCredito. Pois no foi necessrio o uso de outras classes.

7. Colaboraes
Cada padro possui colaboraes que so interaes entre seus participantes, abaixo elas sero descritas. 7.1. Facade

Os clientes se comunicam com o subsistema pelo envio de requisies para a classe Fachada, que acionar as mesmas para os objetos de subsistema apropriados. Embora os objetos de subsistema realizem o trabalho efetivo, a fachada pode ter de fazer o trabalho de traduzir suas interfaces para as interfaces de subsistema. Os clientes que usam a fachada no tem que acessar seus objetos de subsistema diretamente. 7.2. Command

O diagrama de sequencia abaixo mostra as interaes entre os objetos participantes. Alm disso, ele tambm mostra como o Command desacopla o Invoker (invocador) do Receiver (receptor) e a requisio que ele executa.

17

Figura 14 - Ilustrao das interaes entre os objetos no diagrama de sequncia.

Seguindo o diagrama acima as interaes so basicamente essas: O cliente cria um objeto de ConcreteCommand e especifica seu receptor; Um objeto invocador armazena o objeto ConcreteCommand; O invocador emite uma solicitao pela chamada de execute() no Command. Quando o comando pode ser desfeito, ConcreteCommand armazena o estado para desfazer o comando prvio invocao de execute(); O objeto de ConcreteCommand invoca operaes nos receptores para executar a requisio.

8. Exemplos de cdigo
A seguir sero apresentados outros exemplos destes padres em linhas de cdigo, um em java do Facade e um em PHP OO do Command. 8.1. Facade

O exemplo abaixo um cdigo que segue o estilo do que seria um sistema de venda virtual, onde tem-se o carrinho que vai sendo carregado com os produtos que o cliente logado adiciona, e quando termina a compra, finaliza o pedido. Ento seguindo esta ideia foram colocados os mtodos registrar, comprar e finalizar dentro da Facade, pois envolveria vrias classes, como a cliente, produto, a de conexo com o banco, e todas elas, como visto abaixo, esto encapsulados dentro destas trs operaes.

18

Figura 15 - Exemplo de cdigo da classe Fachada para o sistema de compras virtual.

As classes de subsistema envolvidas so BancoDados, Cliente, Produto, Sistema e Carrinho, pode-se ver que h vrias operaes envolvida as trs principais, e que foram escondidas gerando mtodos mais diretos e fceis. Nestas classes de subsistema no h nada alm dos mtodos descritos no exemplo, mas mesmo assim segue abaixo as imagens com seus cdigos.

Figura 16 - Classe de sistema do sistema de compras virtual do exemplo.

19

Figura 17 - Classe de banco de dados do sistema de compras virtual do exemplo.

Figura 18 - Classe de cliente do sistema de compras virtual de exemplo.

20

Figura 19 - Classe de carrinho do sistema de compras virtuais de exemplo.

Figura 20 - Classe de produto do sistema de compras virtuais de exemplo.

Como visto, a implementao do padro Facade em linhas de cdigo bastante simples e traz muita facilidade e organizao no acessa a determinados blocos de funcionalidades, como os subsistemas, quando estes esto representados por fachadas. 8.2. Command Neste caso de exemplo de implementao do padro Command em linhas de cdigo em PHP OO, um caso em que o mtodo geral ser execute(), e ter uma funo responsvel por chamar o Command com este mtodo assinado numa classe abstrata, com o objto desta passado via parmetro. Quando o mtodo for chamado ser passado o objeto da classe que realmente saber fazer a operao. O contexto a ativao ou no da quantidade de estrelas de um livro que possui um autor e ttulo. Abaixo est a classe do livro, com os mtodos construtor, getters e setters dos atributos e os mtodos para por ou no as estrelas no autor e no ttulo.

21

Figura 21 - Ilustrao da classe livro do contexto.

Abaixo esto representadas as classes receptoras que estendero a classe abstrata e implementaram o mtodo execute().

Figura 22 - Ilustrao da classe abstrata e as classes que implementam o mtodo execute().

Abaixo est a funo que ir invocar, atravs do objeto da classe abstrata passado por parmetro, o mtodo execute(), que redirecionar de acordo com o objeto passado para a classe receptora correspondente.

22

Figura 23 - Ilustrao do mtodo com o objeto que invocar o execute().

Para testar, foram necessrios criar um objeto BookComandee, neste caso tambm foi criado um objeto da classe receptora para tornar as estrelas visveis (BookStarsOnCommand) e depois foi usada a funo para invocar o execute(). Como visto na figura abaixo.

Figura 24 - Ilustrao da chamada do comando.

Como visto, o padro Command pode ser tambm aplicado em outras linguagens em contextos diferentes, ele torna o cdigo mais limpo e no gera dependncia entre quem chama e quem executa de fato a operao.

9. Concluses
Pode-se concluir que os padres Facade e Command apesar de resolver problemas de tipos diferentes entre si, eles auxiliam muito quando implementados trazendo diversos benefcios.

10. Referncias
Livros

GAMMA, Erich et al. Design Patterns: Elements of Reusable Object-Oriented Software. Massachusetts: Addison-wesley Professional Computing Series, 1995. 431p. ISBN - 0201633612. Deitel, Paul J. Java: Como Programar. Pearson/Prentice Hall, 2005. 6 edio. 1152p. Apndice M. ISBN 85756050196. Sites

About Design Pattern. Disponvel em: <http://www.javacamp.org/designPattern/>. Acesso em 22 set. 2012. Aline de Sousa Pereira. Padres de projeto: Uma compilao dos mais utilizados em projetos de software. 2008. Disponvel em: <http://www.ricardoterra.com.br/publications/students/2008_pereira.pdf>. Acesso em: 22 set. 2012.
23

Cleilson Gurgel de Brito. Padro Command. Abr. 2010. Disponvel em: <http://di.uern.br/sebastiao/wp-content/uploads/2010/04/Command.pdf>. Acesso em 22 set. 2012. Command in PHP. Disponvel em: <http://sourcemaking.com/design_patterns/command/php>. Acesso em: 22 set. 2012. Command. Disponvel <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/command.htm>. em: 22 set. 2012. em: Acesso

Giovana Weihermann e Slvia Anglica de Oliveira. Design Patterns Command. Disponvel em: <http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=619>. Acesso em: 22 set. 2012. Luis Francisco Thomazini Neto. Padres de projetos. 2006. Disponvel em: <http://bibdig.poliseducacional.com.br/document/?down=92>. Acesso em: 22 set. 2012. Maikon Portela. Padres GOF (Padro Command): Aulas 22 e 23. 21 jun. 2008. Disponvel em: <http://mykportela.blogspot.com.br/2008/06/aulas-22-e-23.html>. Acesso em 22 set. 2012. Marcos Brizeno. Dez. 2011. Disponvel em: <https://github.com/MarcosX/Padr-es-deProjeto/tree/master/src/br/padroes/>. Acesso em: 22 set. 2012. Marcos Brizeno. Mo na massa: Command. 4 nov. 2011. Disponvel em: <http://brizeno.wordpress.com/category/padroes-de-projeto/command/>. Acesso em: 22 set. 2012. Viviane Torres da Silva. Design Patterns. Disponvel em: <http://www.ic.uff.br/~viviane.silva/2012.1/es1/.../aula12.pdf>. Acesso em 22 set. 2012.

24