Design Pattern: Façade

Salve todos

Resolvi escrever este artigo depois de perceber alguns misconceptions, neste caso, sobre o design pattern Façade (é em francês com cedilha mesmo, significando fachada).

Definições da literatura

GOF Design Patterns by ... (ah, todo mundo sabe, o quarteto aquele):

Fornecer uma interface unificada para um conjunto de interfaces em um subsistema. Façade define uma interface de nível mais alto que torna o subsistema mais fácil de ser usado.

http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html

Core J2EE Patterns by Deepak Alur:

O Session Façade remove as interações de objeto de negócios subjacentes e proporciona uma camada de serviços que expõe apenas as interfaces necessárias, uniforme e de granulação grossa para os clientes.

http://www.corej2eepatterns.com/Patterns2ndEd/SessionFacade.htm

Patterns Of Enterprise Application Architecture by Martin Fowler:

A Remote Facade is a coarse-grained facade [Gang of Four] over a web of fine-grained objects. None of the fine-grained objects have a remote interface, and the Remote Facade contains no domain logic. All the Remote Facade does is translate coarse-grained methods onto the underlying fine-grained objects.

Tradução livre: Um Façade Remoto é um façade de granulação grossa (coarse grained) acima de uma rede de objetos de granulação fina (fine grained). Nenhum dos objetos de granulação fina tem uma interface remota, e a interface remota não contém a lógica do domínio. Tudo que o Façade Remoto faz é traduzir métodos de granulação grossa para os objetos de granulação fina sob ele. 

http://martinfowler.com/eaaCatalog/remoteFacade.html

Obs.: Existem várias discussões sobre a granulação de interfaces, como http://articles.techrepublic.com.com/5100-10878_11-5064520.html, sendo um aspecto importante do design. Não o li todo ainda, mas achei este muito interessante: http://www.ibm.com/developerworks/webservices/library/ws-soa-granularity/

Ilustrando (literalmente)

Acho que as ilustrações abaixo permitirão uma visão melhor:

from http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html (GOF):

from http://www.corej2eepatterns.com/Patterns2ndEd/SessionFacade.htm (Core J2EE Patterns):

Parece claro que um Façade simplifica as chamadas utilizando uma interface uniforme e a frente de outros objetos que representam a lógica do domínio. Subentendido fica que os objetos do domínio compartilham informações entre si, e mesmo o façade pode "coreografar" (no mesmo sentido do SOA, mas não com a mesma implementação), obtendo a informação e entregando um resultado íntegro, construído de várias partes do negócio, para o cliente.

Estas mesmas partes, a granulação fina, podem depender de outras, penso afinal, se os objetos do meu domínio não trocam mensagens, o projeto não é orientado a objetos, é procedural*.

*Obs.: Há um code smell para isto http://c2.com/cgi/wiki?ShotgunSurgery e geralmente carece de grande refatoração, dificultando futuras manutenções.

Papel do Façade em uma aplicação distribuída

É custoso em vários sentidos um frontend utilizar chamadas remotas, especialmente síncronas. Não tenho explicação melhor que esta, do Fowler:

Within a single address space fine-grained interaction works well, but this happy state does not exist when you make calls between processes. Remote calls are much more expensive because there's a lot more to do: Data may have to be marshaled, security may need to be checked, packets may need to be routed through switches. If the two processes are running on machines on opposite sides of the globe, the speed of light may be a factor. The brutal truth is that any inter-process call is orders of magnitude more expensive than an in-process call - even if both processes are on the same machine. 

Tradução livre: Dentro de um simples espaço de endereço a interação com granulação fina funciona bem (i.e. mesma JVM, mesmo Host), mas este estadofeliz não existe quando você faz chamadas entre processos. Chamadas remotas são muito mais custosas por que há muito o que fazer: Dados podem precisar de serialização, talvez tenha-se que checar a  segurança, pacotes podem necessitar de roteamento através de switches, etc. Se os dois processos estão rodando em máquinas dispostas em lados opostos do globo, a velocidade da luz pode ser um fator significante. A verdade brutal é que qualquer chamada inter-processos é, em ordem de magnitude, mais custoso que uma chamada dentro do mesmo processo - mesmo se os dois processos estiverem na mesma máquina. 

Então ...

Patterns são assim mesmo, tem uma pitada de subjetividade e, obviamente, nem todo mundo tem o mesmo entendimento.

Se alguém quer acrescentar (ou subtrair) algo, fique a vontade, este tópico neste espaço é para todos juntos chegarmos a um consenso, com um pouco de cada, aproveitando a inteligência coletiva.

Márcio Torres