015 – Padrão de Projeto FAÇADE – Padrão GoF Estrutural – Aprenda Design Patterns

Playlist do Curso de Padrão de Projeto de Software (Design Patterns)

O Padrão de projeto Façade é um padrão de design de software usado comumente com programação orientada a objetos. Este nome é uma analogia para uma fachada arquitetural. Um Façade é um objeto que provê uma interface simplificada para um corpo de código maior, como por exemplo, uma biblioteca de classes.

O Padrão Façade é do tipo estrutural . É usado quando um sistema é muito complexo ou difícil de entender, já que possui um grande número de classes independentes ou se trechos de código fonte estão indisponíveis. Este padrão esconde as complexidades de um sistema maior e provê uma interface simplificada ao cliente. Tipicamente envolve uma única classe responsável por englobar uma série de membros requeridos pelo cliente. Estes membros acessam o sistema em nome do Façade e escondem os detalhes de implementação.

Motivação
Estruturar um sistema em subsistemas ajuda a reduzir sua complexidade. A dependência existente entre os subsistemas pode ser minimizada através do uso de um objeto Façade, que fornece uma interface única e uniforme para as diversas funcionalidades de um subsistema.

Quando existir um sistema complexo, na qual o cliente não precisa entender todo o sistema, o Façade possibilita um uso simplificado do sistema, apenas um subconjunto dele, ou utilizá-lo de uma maneira particular. Dispomos então de um sistema complicado, do qual precisamos utilizar somente uma parte, para um sistema simplificado, customizado para nossas necessidades.

Finalidade
Tem como propósito promover uma interface unificada para um conjunto de interfaces de um subsistema. Dessa forma, é definida uma interface de alto nível que torna um subsistema mais fácil de ser utilizado.

Seu objetivo é implementar uma forma de interagir com um sistema que seja mais fácil do que a atual, com a intenção de usar um subconjunto do sistema em questão. Ou seja, busca simplificar o uso de um sistema existente a partir de uma interface própria definida.

Diagrama UML da estrutura do padrão de projeto Façade.
Participantes
Classe Façade (Agrupadora)
Conhece quais classes dos subsistemas são responsáveis pela chamada.

Delega chamadas do cliente aos objetos de subsistemas corretos.

Classes dos subsistemas
Implementa funcionalidades dos subsistemas.

Lida com o trabalho atribuído pelo objeto façade.

Não tem conhecimento de façade, isso o mantém sem referências com o cliente diretamente.

Conhece quais classes dos subsistemas são responsáveis pela chamada.

Aplicação
O Padrão Façade pode ser usado quando :

Se deseja uma interface simplificada para um subsistema muito complexo. Subsistemas comumente ficam mais complexos a medida que evoluem e a maioria dos padrões, quando aplicados, resultam em muitas classes de pequeno tamanho. Isso torna o subsistema mais reutilizável e simples de se customizar.
São muitas as dependências entre clientes e classes de implementação.
Há o interesse em dividir seus subsistemas em camadas. Use um Façade para definir um ponto de entrada para cada nível de subsistema. Se seus subsistemas são dependentes, essas dependências podem ser simplificadas entre sí ao se comunicarem unica e exclusivamente pelo façade.
Por exemplo um empréstimo em um sistema bancário:

Em um sistema bancário, o cliente precisa realizar diversas consultas a diversas entidades a fim de obter retorno sobre suas condições de realizar um empréstimo junto ao banco. Sem um padrão Façade, o cliente deveria ter acesso, e consequentemente conhecer toda a complexidade por trás das regras de concessão de empréstimo.

Com a aplicação do padrão de projeto, o Façade irá tomar para sí a responsabilidade de colher dados das diferentes classes responsáveis pela decisão sobre a possibilidade de concessão de empréstimo para o cliente, e ao final, entregar a ele apenas a informação pronta.

Consequências
Torna o sistema mais fácil de se usar, protegendo os clientes dos componentes do sistema, reduzindo o número de objetos que terão que lidar.
Promove fraco acoplamento entre os subsistemas e seus clientes.
Não evita que as aplicações possam acessar as subclasses diretamente, pode-se escolher entre a facilidade de uso ou a generalidade.