[Delphi] Design Patterns GoF – Façade

Saudações, pessoal!
Em algum momento, enquanto você codificava alguma funcionalidade, já identificou a necessidade de “envelopar” uma rotina complexa em apenas uma classe? Esse procedimento, também conhecido como wrapper, é basicamente o propósito do padrão de projeto que apresentarei neste artigo: o Façade. Você verá que o seu uso é relativamente comum na programação. Acompanhe!

Introdução

Em primeiro lugar, é Facade ou Façade?

Cada um fala de um jeito, não é? Bom, os dois termos estão corretos. “Facade” é mais popular no idioma inglês. “Façade”, com cedilha, leva um aspecto francês na palavra e é mais comum na Europa. No Brasil, geralmente usamos a segunda opção pela facilidade da pronúncia.

A proposta do Façade é encapsular um procedimento complexo, que geralmente envolve uma biblioteca de classes, e disponibilizar ao cliente apenas um método simplificado para executá-lo. Vale ressaltar que quando mencionamos “cliente”, no contexto de Design Patterns, nos referimos à classe que consumirá o padrão, e não ao usuário que utiliza o sistema, ok?

Pois bem, o Façade não recebe este nome por acaso. A tradução, “fachada”, é uma analogia para indicar o que o cliente pode acessar externamente, poupando-o de conhecer detalhes complexos internos.

Analogia

Tome, como exemplo, um televisor. Do lado de fora, como clientes, apenas vemos a fachada da TV (composta por uma tela e vários botões) e não conhecemos o que existe do lado de dentro. Para ter acesso às suas operações internas, usamos o botão de ligar. Ao pressioná-lo, aguardamos que a TV seja acionada e exiba as imagens adequadamente. O modo como a inicialização é feita – ligar os componentes, sintonizar no último canal visto, carregar as configurações de imagem e volume, etc. – não é do nosso conhecimento, já que envolve uma série de operações. O Façade, neste caso, é o botão de liga/desliga, que atua como intermediário entre o cliente (telespectador) e o sistema técnico da TV. Podemos afirmar, então, que o Façade facilita a utilização de um objeto, transformando operações internas complexas em chamadas únicas e simples.

Traduzindo a analogia em código, o Façade teria a seguinte codificação:

O cliente, por sua vez, teria apenas essa chamada:

Acho que já deu para captar a mensagem, não é? 🙂

No contexto do Façade, as classes que realizam essas operações complexas são chamadas de Subsystem Classes. Recebem este nome por formar um “subsistema” dentro da aplicação para executar uma rotina de negócio específica. Lembram-se do artigo sobre Separation of Concerns? O Façade constitui um “conceito” dentro do sistema, já que executa ações de forma desacoplada, geralmente envolvendo uma regra de negócio especial.

Viram como é algo relativamente comum? Tenho certeza que vocês, em algumas situações, já criaram Façades involuntariamente, haha.

Exemplo de codificação do Façade

Pessoal, vou abrir o jogo. A parte mais difícil de escrever os artigos sobre Design Patterns é pensar em bons exemplos do “mundo real” para apresentar a vantagem da empregabilidade de cada um. Sempre procuro encontrar exemplos simples e básicos, mas, ao mesmo tempo, suficientes para demonstrar os padrões em produção.

Dessa vez, pensei em um cenário de cálculo de valor de venda a partir da cotação do Dólar do dia atual. A ideia é simples: para evitar que o cliente faça a consulta da cotação do Dólar, aplicação de descontos e aplicação de margem de venda (que pode ser considerado um procedimento complexo), criaremos um Façade que disponibilizará um único método – CalcularValorDeVenda – responsável por realizar todo este processo. Em outras palavras, faremos um wrapper do cálculo do valor de venda.

Para que este exemplo seja factível, consumiremos um WebService do Banco Central do Brasil para consulta do valor do Dólar no dia atual, disponível no endereço WSDL abaixo:

https://www3.bcb.gov.br/sgspub/JSP/sgsgeral/FachadaWSSGS.wsdl

Obervação: viram que o nome do WSDL começa com “Fachada”? Pois é, esse WebService é um Façade. 🙂

Caso você decida acompanhar o artigo, utilize o WSDL Importer do Delphi para criar a biblioteca de funções disponibilizadas pelo WebService.

Subsystem Classes

A primeira etapa é criar as Subsystem Classes, ou seja, as classes que fazem parte do subsistema. No nosso exemplo, teremos 3:

  • A classe TSubSystemCotacaoDolar para buscar a cotação do Dólar no dia atual:

  • A classe TSubsystemClasseLoja, encarregada de aplicar o desconto e a margem de venda:

  • Por fim, a classe TSubsystemHistorico para armazenar os dados do cálculo em um arquivo texto:

Classe Façade

A próxima etapa é… yes, criar o Façade! Observe que a classe terá apenas um método de visibilidade pública, e este utilizará as 3 Subsystem Classes de uma só vez:

Em ação!

O terceiro e último passo é colocar o Façade em prática, utilizando-o em um Client que, no nosso exemplo, é uma tela simples que possui os dados do cliente e o preço do produto (em Dólares), nos quais serão passados por parâmetros para o Façade:

Que moleza para o Client, hein? Apenas solicita o cálculo do valor de venda, sem conhecer a “trabalheira” que ocorre por trás. 🙂

Conclusão

Na equipe em que faço parte, utilizamos o Façade sempre que necessário, principalmente pelo motivo que, no módulo em que trabalhamos, há várias regras de negócio específicas que exigem processamentos complexos, como cálculos periódicos, atualização de valores monetários e emissão de relatórios extensos. Com este padrão de projeto, mantemos estes subsistemas encapsulados, acessando-os somente pelo método que é exposto. Não precisamos nos preocupar com a complexidade interna.

Leitores, disponibilizei este projeto de exemplo no link abaixo, com breves modificações. Ao executá-lo no seu Delphi, observe que adicionei dois componentes TDBGrid: um para os dados dos clientes e outro para os dados dos produtos. Intercale a seleção de registros entre eles e clique em “Calcular Valor de Venda” para obter diferentes resultados.

 

Ah, e sabe por que usei um prisma na imagem do artigo?
É uma analogia bem abstrata. Considere que o feixe de luz branca é a requisição do Client, o prisma é o Façade, e as luzes coloridas são as Subsystem Classes. Será que prismas dispersivos são Façades?

Um grande abraço e até a próxima!


André Celestino