Padrões

de

Projeto:

Facade & Command

Instituto Federal Fluminense – Campus Campos-Centro

Aluno(a): Yasmmin Côrtes Martins.

Data: 01/10/2012

Análise e desenvolvimento de sistemas. Noite. 5º Período.

Sumário

1. Introdução..............................................................................................................5

2. Objetivo e Problema..............................................................................................5

2.1. Facade.............................................................................................................5

2.2. Command........................................................................................................6

3. Motivação e Aplicação..........................................................................................9

3.1. Facade.............................................................................................................9

3.2. Command........................................................................................................9

4. Solução.................................................................................................................11

4.1. Facade...........................................................................................................11

4.2. Command......................................................................................................13

5. Consequências.....................................................................................................14

5.1. Facade...........................................................................................................14

5.2. Command......................................................................................................15

6. Participantes.........................................................................................................15

6.1. Facade...........................................................................................................16

6.2. Command......................................................................................................16

7. Colaborações........................................................................................................17

7.1. Facade...........................................................................................................17

7.2. Command......................................................................................................17

8. Exemplos de código.............................................................................................18

8.1. Facade...........................................................................................................18

8.2. Command......................................................................................................21

9. Conclusões...........................................................................................................23

10. Referências...........................................................................................................23

Índice de figura

Figura 1 - Exemplo de diagrama de classes para mostrar um dos problemas

solucionados pelo padrão Facade......................................................................................6

Figura 2 - Classe Lanchonete do sistema de exemplo usado para apresentar o problema

solucionado pelo padrão Command..................................................................................7

Figura 3 - Classe Conta do sistema de exemplo usado para apresentar o problema

solucionado pelo padrão Command..................................................................................8

Figura 4 - Modo de resolver o problema só que de forma não muito eficiente, com

várias condicionais aninhadas...........................................................................................9

Figura 5 - Ilustração do princípio de organização do sistema com o padrão Facade......10

Figura 6 - Ilustração de uma classe abstrata Command com os possíveis métodos

assinados..........................................................................................................................11

Figura 7 - Exemplo de uma classe fachada para o problema da seção 2.........................12

Figura 8 - Imagem do código da interface criada para implementação da solução

prevista no padrão............................................................................................................13

Figura 9 - Ilustração da nova versão do método executar_pagConta()...........................13

Figura 10 - Ilustração da implementação do método que foi assinado na interface para o

caso de pagamento à vista...............................................................................................14

Figura 11 - Ilustração de como chamar o método que invocará a ação desejada............14

Figura 12 - Estrutura do padrão Facade...........................................................................16

Figura 13 - Estrutura em diagrama de classes do padrão Command...............................16

Figura 14 - Ilustração das interações entre os objetos no diagrama de sequência...........18

Figura 15 - Exemplo de código 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 - Ilustração da classe livro do contexto...........................................................22

Figura 22 - Ilustração da classe abstrata e as classes que implementam o método

execute()..........................................................................................................................22

Figura 23 - Ilustração do método com o objeto que invocará o execute()......................23

Figura 24 - Ilustração da chamada do comando..............................................................23

5

1. Introdução

Os padrões de projeto que serão relatados neste trabalho pertencem a dois

grupos diferentes, o Facade aos padrões estruturais e o Command aos comportamentais.

Os padrões estruturais tratam de problemas que podem ocorrer no projeto envolvendo

associações entre classes e objetos, e os comportamentais tratam de problemas que

podem ocorrer que podem ocorrer nas interações e na delegação de responsabilidades

entre as classes ou objetos.

Os componentes básicos de todo padrão de projeto, como o contexto do

problema, a motivação, a aplicabilidade e os participantes, serão explanados nas

próximas seções, mas estes tipos de padrões são bastante comuns e podem utilizados

para várias aplicações de diversos contextos.

O Facade tem como finalidade básica reduzir a complexidade da modelagem do

sistema, usando uma classe “fachada” que ao ser acionada por seus métodos faz

ligações que não são visíveis ao usuário para outras classes dos sub-sistemas, para fazer

a ação requerida, ou seja a intenção é fazer as ações através de classes de alto nível sem

precisar saber o conjunto de procedimentos correspondentes a estas ações.

O Command tem como finalidade evitar a repetição de trechos de códigos

relativo a funcionalidades que são oferecidas em interfaces gráficas diferentes, para

evitar programar uma determinada ação quantas vezes forem as opções de se fazê-la em

lugares diferentes do sistema, este padrão prevê uma solução. Além de permitir

armazenar os comandos dados, podendo registrar os logs e permitir desfazer e refazer

operações.

2. Objetivo e problema

Os dois padrões pertencem a classificações diferentes resolvem problemas de

contextos diferentes, portanto cada um será relatado em um tópico distinto.

2.1. Facade

Muitas vezes, quando se tem aplicações com diversas classes na camada de

negócios que dependem de métodos e até de outras classes, para fazer ações mais

detalhadas, e quando não se usa uma classe de “fachada” comum para delegar e

distribuir os métodos às outras classes de uma camada mais inferior, isso acaba trazendo

um forte acoplamento, ou seja, uma forte dependência entre as funções e métodos em

relação às classes.

Por exemplo, supondo um sistema que tenha o seguinte esboço:

6

Figura 1 - Exemplo de diagrama de classes para mostrar um dos problemas solucionados pelo padrão

Facade.

O típico sistema de locadora (na figura 1), numa forma simples, com apenas

quatro classes, supondo que na camada de visualização a pessoa queira fazer o aluguel,

ela escolhe os filmes e quando clica em salvar, é acionado a parte que fica na camada de

negócio, que trata a comunicação com o banco de dados, e neste caso ele precisa fazer

atualizações e inserções em pelo menos três objetos das classes de Cliente (vai ficar na

situação pendente) e vai adicionar em Item_aluguel e Aluguel.

Para um único aluguel ele terá de utilizar os três objetos e vai ter que tratar das

instanciações assim como a validação e, se caso ter algum problema em alguma das

operações no banco, dar rollback (desfazer a ação) nas que conseguiram mas na verdade

dependiam do sucesso das outras.

O problema é que por estar em um jeito distribuído concentrando todas as

operações, pode ser que haja outras regras a serem tratadas e então quanto mais for

adicionada mais operações devem ser feitas podendo tornar o código menos

transparente e difícil.

Logo, na implementação a invés de ter que fazer e tratar os três fazendo três

caminhos para inserir, pelo padrão Facade poderia instanciar um objeto só, que terá um

método e único caminho para fazer a solicitação, a “fachada” teria a missão 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 ação de pagamento porém por enquanto a lanchonete só aceita à vista, neste

caso. Abaixo serão colocados exemplos de códigos para esta situação, as classes

necessárias (como Lanchonete (supondo um sistema única próprio para este

estabelecimento) e Conta) com os métodos. Há outras classes, como bebidas, lanches,

7

funcionários e guloseimas, mas a parte principal será o processo de pagamento por isso

foram omitidas.

Para resolver esta situação sem usar a solução prevista por este padrão seria

necessário usar estes blocos de código, muito simples:

Figura 2 - Classe Lanchonete do sistema de exemplo usado para apresentar o problema solucionado

pelo padrão Command.

Esta classe (da figura 2) pode ter outros atributos como inscrição estadual,

endereço, 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 emissão da nota

fiscal do estabelecimento.

8

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

padrão Command.

Como, a princípio, o estabelecimento não quis usar outra forma de pagamento

senão à vista, não precisamos nos preocupar em processar a compra de acordo com os

diversos tipos de cartões.

Porém se ao longo do crescimento de movimento da lanchonete o dono resolver

adaptar a forma de pagamento, conforme o gosto de seus clientes, será necessário

adaptar também o método “executar_pagConta”.

A forma de fazer isso sem usar a solução prevista no padrão Command seria

acrescentar um parâmetro neste método, referente à forma de pagamento, e ir

verificando através de condicionais.

O parâmetro poderia ser como no exemplo, com um simples objeto da classe

String, ou poderia ser uma instância de um Enumeration, que pode ser uma forma

agregar sub-valores a um atributo de uma classe (por exemplo, supondo uma classe

usuário, existem alguns níveis de privilégio, que são os subtipos do atributo nível, ou

seja, pode ser nível.admin, nível.root, nível.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 nível de privilégios).

9

Figura 4 - Modo de resolver o problema só que de forma não muito eficiente, com várias condicionais

aninhadas.

Esta forma de resolução apesar de funcionar tem problemas como uma alta

dependência das classes participantes, quantidades de condicionais que vão crescendo

conforme novas opções surjam, necessidade de alterações locais, etc.

Este é o principal contexto em que o padrão Command pode entrar como uma

forma eficaz de resolver estes problemas, fazer com que as classes que invocaram este

método não precisem saber das que estão realmente implementando os métodos.

Então, segundo o padrão Command haveria uma interface ou classe abstrata com

o método “execute”, podendo ou não ter parâmetros, neste caso o método a ser invocado

e que será implementado por classes diferentes é “processarPag” com o parâmetro do

objeto da classe Conta. E no parâmetro passaria um objeto da interface/classe abstrata

Command, com a instância do objeto da classe que realmente fará a operação.

3. Motivação e aplicação

Estes padrões possuem suas razões para serem usados em alguns momentos do

desenvolvimento do projeto de software. A seguir estão algumas das razões de se usar

os padrões Facade e Command e os possíveis contextos em que elas se inserem.

3.1. Facade

Normalmente um sistema possui diversos blocos funcionais, ou subsistemas,

com diversas classes e suas operações, porém podemos organizar as chamadas e

encapsulá-las em métodos numa classe “Fachada”, o que significa simplificar a quem

usar a classe Fachada e tornar o sistema em si menos complexo.

10

Assim terá funcionalidades gerais que deixam as da camada de subsistema

omitidas, porém estarão lá caso precisem ser alteradas. É só uma forma simples de

organizar o sistema.

Figura 5 - Ilustração do princípio de organização do sistema com o padrão Facade.

Além disso, a Facade tem o papel de diminuir a dependência entre o cliente e os

componentes de subsistema, tornando ele mais portável em diversos casos. Além de, se

for preciso, poder inserir mais funcionalidades gerais na Facade, tornando-se mais

simples este trabalho pois só precisa mexer na classe Facade não nas de subsistema,

pode-se por quantas funcionalidades for preciso.

Outra razão 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 comunicação

ficará simplificada com a ajuda das funcionalidades gerais de suas Facades.

3.2. Command

Há várias ocasiões em que o padrão Command pode ser usado, pois ele tem

vários objetivos. De forma geral, sua motivação e aplicabilidade se resumem em

situações que precisem encapsular invocações/solicitações a objetos, permitindo

parametrizar clientes que possuem diversas solicitações, enfileirar ou fazer o registro do

histórico (log) de solicitações e suportar operações que possam ser desfeitas.

Quanto à parametrização de objetos por uma ação que será executada (como o

método executar_pagConta), isso numa linguagem procedural como Delphi e C,

equivale ao funcionamento das funções de CallBack, ou seja, uma função que é feita em

algum momento do código e que será utilizada em outro lugar em algum momento

posterior. Os commands são os substitutos das CallBacks na orientação a objeto.

Quanto ao fato de poder especificar, enfileirar e executar solicitações em tempos

diferentes, um objeto Command pode ter um tempo de vida diferente independente da

solicitação original (isso significa que o objeto não “morre” logo após realizar a

operação requisitada). Isso é possível pois se o receptor de uma solicitação pode ser

11

representado de uma forma independente do espaço de endereçamento, então é possível

transferir um objeto Command para um processo diferente e lá atender alguma outra

solicitação.

Quanto ao fato de suportar desfazer operações, a operação execute(), assinada na

interface ou classe abstrata Command, pode armazenar estados para reverter seus efeitos

no próprio comando. E a interface de Command pode ter outro método assinado, o

unexecute(), que reverte os efeitos de uma chamada anterior de execute(). Os comandos

executados precisam ser armazenados numa lista que servirá de histórico, permitindo

um nível ilimitado de operações de refazer e desfazer, pois esta lista será percorrida de

para frente (em refazer()) e para trás (em desfazer()), chamando operações unexecute() e

execute(), respectivamente.

Quanto ao fato de enfileirar e manter o histórico (log) de solicitações de forma

que possam ser recarregadas caso haja um problema no sistema, ao acrescentar mais

duas operações assinadas na interface/classe abstrata Command, carregar() e

armazenar(), pode-se manter o registro (log) das mudanças que ocorreram. A

recuperação de uma queda de sistema envolve a invocação dos comandos registrados a

partir do disco e sua nova execução com a operação execute().

Um exemplo de como fica ao final uma classe abstrata com todos estes métodos

abstratos assinados está mostrado na figura abaixo, a diferença é que as que

implementarem usaram extends ao invés de implements.

Figura 6 - Ilustração de uma classe abstrata Command com os possíveis métodos assinados.

Pode-se também usar o padrão para estruturar um sistema em torno de operações

de alto nível construída sobre operações primitivas. Este tipo de estrutura é comum em

sistemas de informação que suportam transações que encapsulam um conjunto de

mudanças nos dados. O padrão Command fornece uma maneira de modelar transações,

os Commands, por terem interface comum, permitem invocar todas as transações da

mesma maneira.

4. Solução

Bom, foram propostos dois problemas na seção 2, um envolvendo cada padrão,

então abaixo serão apresentadas possíveis soluções para eles, em trechos de códigos e

algumas linhas de explicação.

12

4.1. Facade

Para resolver a questão do registro de aluguel, que precisava atualizar 4 classes,

e para evitar instanciar objetos diretamente no código principal da aplicação, pode-se

usar uma classe Facade que terá métodos de alto nível, e neles ficaram encapsuladas as

chamadas para as classes necessárias. Uma solução seria a da figura abaixo.

Figura 7 - Exemplo de uma classe fachada para o problema da seção 2.

13

Então na classe “Fachada” só teve um método registrar com os parâmetros

necessários para cadastrar o aluguel, o código de identificação do cliente, o valor total

do aluguel e a lista com os códigos de identificação dos filmes alugados, vindas da

camada de visão do sistema, por exemplo. Além deste método 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 validações

e as ações a serem tomadas caso alguma das operações no banco envolvendo as

entidades não dê certo.

No caso os métodos são de exemplo, e a mensagem de erro pode estar num

JOptionPane ou na função alert() do Javascript, caso o sistema seja feita no ambiente

java para web.

4.2. Command

Para resolver o problema levantado na continuação do processo de pagamento da

conta usando três formas possíveis, usa-se o que está previsto no padrão que é a criação

de uma interface Command que terá o método em questão que será implementado de

acordo com os procedimentos de cada classe responsável pelos tipos diferentes de

pagamento. Abaixo está a interface usada.

Figura 8 - Imagem do código da interface criada para implementação da solução prevista no padrão.

Além disso, houve uma modificação na no parâmetro do método usado pela

classe Lanchonete para invocar a ação “processarPag”, agora o parâmetro é um objeto

da interface Command_pag e este objeto é usado para chamar o método assinado na

interface e que foi implementado nas classes das formas de pagamento. Abaixo

encontra-se o código da nova versão do método “executar_pagConta”.

Figura 9 - Ilustração da nova versão do método executar_pagConta().

14

E por fim, as classes responsáveis por implementar o método da interface, na

figura abaixo é mostrado o método completo para o caso de pagamento à vista e a

ligação da classe com a interface através do implements. As outras classes de

pagamento também seguirão a mesma ideia porém o conteúdo do método será adaptado

a cada tipo.

Figura 10 - Ilustração da implementação do método que foi assinado na interface para o caso de

pagamento à vista.

Na hora de chamar este método, após criar o objeto de Lanchonete, é só passar o

valor da conta e o objeto da classe responsável pelo pagamento, como na figura abaixo.

Figura 11 - Ilustração de como chamar o método que invocará a ação desejada.

Como visto, é simples implementar o padrão, o método da interface ao ser

implementado pode chamar outros métodos de outras classes se precisar, os invocadores

que o chamam podem ser também itens de menu, os receptores podem ser quaisquer

classes que saibam fazer as operações requisitadas.

5. Consequências

Os dois padrões trazem efeitos para o sistema quando implementados, a seguir

estão descritos alguns possíveis efeitos que poderão ser percebidos após a utilização dos

padrões.

5.1. Facade

O padrão Facade separa a classe cliente das dos componentes de sub-sistema (o

cliente pode ser as classes do setor de visão do sistema diretamente ou outras classes

que possam acessar os métodos gerais previstos na “Fachada”), assim reduzindo o

número de objetos que o cliente precisará usar e fazer com que os componentes de

subsistema sejam mais fáceis de usar.

15

Ele promove um baixo acoplamento (ligação/dependência) entre o subsistema e

os clientes. Frequentemente os componentes num subsistema são fortemente acoplados.

O baixo acoplamento permite a variação das classes de subsistema sem afetar os

clientes.

Fachadas ajudam a dispor em camadas um sistema e as dependências entre

objetos. Elas podem eliminar dependências complexas ou circulares. Essa pode ser uma

consequência muito importante quando os clientes e o subsistema são implementados e

forma independente.

Reduzir as dependências de compilação é essencial em sistemas de software

grandes. Usar Fachadas permite que o tempo diminua na recompilação de classes de

subsistemas alteradas, pois elas reduzem as dependências e então limitam a

recompilação necessária para uma mudança pequena em um importante subsistema.

Uma fachada pode também simplificar a migração de sistemas para outras

plataformas, pois é menos provável que a construção de um subsistema requeira a

construção de todos os outros.

Ela não previne aplicações 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

métodos das classes de subsistema.

5.2. Command

O padrão Command desacopla o objeto que invoca a operação do que sabe como

fazê-la, ou seja, desliga os que possuem os dados dos que sabem o que fazer com eles.

Commands são 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 são uma instância do padrão Composite.

É fácil adicionar novos Commands, pois não é necessário mudar classes

existentes.

6. Participantes

16

Para cada padrão há participantes, ou seja, classes que farão parte da estrutura

dele na sua implementação em código. Abaixo se encontram o diagrama de classe e/ou

diagrama de sequência de cada um.

6.1. Facade

Abaixo está a estrutura geral do padrão Facade:

Figura 12 - Estrutura do padrão Facade.

Seguindo a estrutura acima, os participantes neste padrão são basicamente a

Facade (Fachada) e as subsystem classes (classes de subsistema).

A facade (fachada) é o que sabe quais classes de subsistema são responsáveis

por determinada requisição e delega as requisições do cliente para os objetos de

subsistema apropriados. Exemplo: Facade_aluguel.

As classes de subsistema implementam as funcionalidades de subsistema; lida

com o trabalho atribuído pelo objeto da fachada e não têm conhecimento da fachada, ou

seja, eles não mantêm referência a ela. Exemplo: Aluguel, Cliente, Item_aluguel.

6.2. Command

Abaixo está a estrutura geral, em diagrama de classes, do padrão Command:

Figura 13 - Estrutura em diagrama de classes do padrão Command.

17

Seguindo a estrutura acima, os participantes são Command, ConcreteCommand,

Client, Invoker e Receiver.

O Command é a interface ou classe abstrata que contém a operação e ser

executada por quem implementar. Exemplo: Command_pag.

O ConcreteCommand implementa o método da interface ou classe abstrata, e

caso precise usar métodos de outras classes dentro do método implementado para fazer

alguma ação, define uma ligação entre o objeto da classe receiver (receptora) e uma

ação. Exemplo: PagamentoAvista, PagamentoCartaoDebito e PagamentoCartaoCredito.

Client (cliente) é o que cria um objeto de ConcreteCommand e seta o receiver

(receptor). Exemplo: a tela de aplicação onde será usado o padrão, Lanchonete.

Invoker (invocador) é o que pede o comando para executar a requisição.

Exemplo: O objeto passado por parâmetro que ativa o método da interface em

“Executar_pagConta”.

Receiver (Receptor) é o que sabe como realizar as operações associadas com a

execução de uma requisição. Qualquer classe pode servir como receptora. Exemplo:

PagamentoAvista, PagamentoCartaoDebito e PagamentoCartaoCredito. Pois não foi

necessário o uso de outras classes.

7. Colaborações

Cada padrão possui colaborações que são interações entre seus participantes,

abaixo elas serão descritas.

7.1. Facade

Os clientes se comunicam com o subsistema pelo envio de requisições 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 não tem que acessar seus objetos de subsistema

diretamente.

7.2. Command

O diagrama de sequencia abaixo mostra as interações entre os objetos

participantes. Além disso, ele também mostra como o Command desacopla o Invoker

(invocador) do Receiver (receptor) e a requisição que ele executa.

18

Figura 14 - Ilustração das interações entre os objetos no diagrama de sequência.

Seguindo o diagrama acima as interações são basicamente essas:

O cliente cria um objeto de ConcreteCommand e especifica seu receptor;

Um objeto invocador armazena o objeto ConcreteCommand;

O invocador emite uma solicitação pela chamada de execute() no Command.

Quando o comando pode ser desfeito, ConcreteCommand armazena o estado para

desfazer o comando prévio à invocação de execute();

O objeto de ConcreteCommand invoca operações nos receptores para executar a

requisição.

8. Exemplos de código

A seguir serão apresentados outros exemplos destes padrões em linhas de

código, um em java do Facade e um em PHP OO do Command.

8.1. Facade

O exemplo abaixo é um código 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.

Então seguindo esta ideia foram colocados os métodos registrar, comprar e

finalizar dentro da Facade, pois envolveria várias classes, como a cliente, produto, a de

conexão com o banco, e todas elas, como visto abaixo, estão encapsulados dentro destas

três operações.

19

Figura 15 - Exemplo de código da classe Fachada para o sistema de compras virtual.

As classes de subsistema envolvidas são BancoDados, Cliente, Produto, Sistema

e Carrinho, pode-se ver que há várias operações envolvida as três principais, e que

foram escondidas gerando métodos mais diretos e fáceis.

Nestas classes de subsistema não há nada além dos métodos descritos no

exemplo, mas mesmo assim segue abaixo as imagens com seus códigos.

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

20

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.

21

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 implementação do padrão Facade em linhas de código é bastante

simples e traz muita facilidade e organização no acessa a determinados blocos de

funcionalidades, como os subsistemas, quando estes estão representados por fachadas.

8.2. Command

Neste caso de exemplo de implementação do padrão Command em linhas de código

em PHP OO, é um caso em que o método geral será execute(), e terá uma função responsável

por chamar o Command com este método assinado numa classe abstrata, com o objto desta

passado via parâmetro. Quando o método for chamado será passado o objeto da classe que

realmente saberá fazer a operação.

O contexto é a ativação ou não da quantidade de estrelas de um livro que possui um

autor e título. Abaixo está a classe do livro, com os métodos construtor, getters e setters dos

atributos e os métodos para por ou não as estrelas no autor e no título.

22

Figura 21 - Ilustração da classe livro do contexto.

Abaixo estão representadas as classes receptoras que estenderão a classe abstrata

e implementaram o método execute().

Figura 22 - Ilustração da classe abstrata e as classes que implementam o método execute().

Abaixo está a função que irá invocar, através do objeto da classe abstrata

passado por parâmetro, o método execute(), que redirecionará de acordo com o objeto

passado para a classe receptora correspondente.

23

Figura 23 - Ilustração do método com o objeto que invocará o execute().

Para testar, foram necessários criar um objeto BookComandee, neste caso

também foi criado um objeto da classe receptora para tornar as estrelas visíveis

(BookStarsOnCommand) e depois foi usada a função para invocar o execute(). Como

visto na figura abaixo.

Figura 24 - Ilustração da chamada do comando.

Como visto, o padrão Command pode ser também aplicado em outras

linguagens em contextos diferentes, ele torna o código mais limpo e não gera

dependência entre quem chama e quem executa de fato a operação.

9. Conclusões

Pode-se concluir que os padrões Facade e Command apesar de resolver

problemas de tipos diferentes entre si, eles auxiliam muito quando implementados

trazendo diversos benefícios.

10. Referências

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ª edição. 1152p.

Apêndice M. ISBN – 85756050196.

Sites

About Design Pattern. Disponível em: <http://www.javacamp.org/designPattern/>.

Acesso em 22 set. 2012.

Aline de Sousa Pereira. Padrões de projeto: Uma compilação dos mais utilizados em

projetos de software. 2008. Disponível em:

<http://www.ricardoterra.com.br/publications/students/2008_pereira.pdf>. Acesso em:

22 set. 2012.

24

Cleilson Gurgel de Brito. Padrão Command. Abr. 2010. Disponível em:

<http://di.uern.br/sebastiao/wp-content/uploads/2010/04/Command.pdf>. Acesso em 22

set. 2012.

Command in PHP. Disponível em:

<http://sourcemaking.com/design_patterns/command/php>. Acesso em: 22 set. 2012.

Command. Disponível em:

<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/pat/command.htm>. Acesso

em: 22 set. 2012.

Giovana Weihermann e Sílvia Angélica de Oliveira. Design Patterns – Command.

Disponível em:

<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=619>.

Acesso em: 22 set. 2012.

Luis Francisco Thomazini Neto. Padrões de projetos. 2006. Disponível em:

<http://bibdig.poliseducacional.com.br/document/?down=92>. Acesso em: 22 set. 2012.

Maikon Portela. Padrões GOF (Padrão Command): Aulas 22 e 23. 21 jun. 2008.

Disponível em: <http://mykportela.blogspot.com.br/2008/06/aulas-22-e-23.html>.

Acesso em 22 set. 2012.

Marcos Brizeno. Dez. 2011. Disponível em: <https://github.com/MarcosX/Padr-es-de-

Projeto/tree/master/src/br/padroes/>. Acesso em: 22 set. 2012.

Marcos Brizeno. Mão na massa: Command. 4 nov. 2011. Disponível em:

<http://brizeno.wordpress.com/category/padroes-de-projeto/command/>. Acesso em: 22

set. 2012.

Viviane Torres da Silva. Design Patterns. Disponível em:

<http://www.ic.uff.br/~viviane.silva/2012.1/es1/.../aula12.pdf>. Acesso em 22 set.

2012.