🖥️
Padrões de Projeto
  • Padrões de Projeto
  • Orientação a Objetos
    • Conceitos básicos de orientação a objetos
      • Objetos e classes
      • Encapsulamento
      • Relacionamentos
      • Herança
      • Realização
      • Polimorfismo
      • Imutabilidade
  • Princípios SOLID
    • Introdução
    • SRP - Princípio de Responsabilidade Única
    • OCP - Princípio de Aberto/Fechado
    • LSP - Princípio de Substituição de Liskov
    • ISP - Princípio de Segregação de Interfaces
    • DIP - Princípio de Inversão de Dependência
  • Padrões de Projetos e catálogos
    • Introdução
  • Padrões Comportamentais
    • Padrão Strategy
    • Padrão State
    • Padrão Observer
    • Padrão Chain of Responsibility
    • Padrão Command
    • Padrão Template Method
    • Padrão Null Object
  • Padrões Criacionais
    • Padrão Singleton
    • Padrão Prototype
    • Padrão Builder
    • Padrões Factory
      • Factory Method
      • Abstract Factory
  • Padrões Estruturais
  • Padrão Adapter
  • Padrão Facade
  • Padrão Decorator
  • Padrão Proxy
  • Padrão Bridge
  • Padrão Composite
Powered by GitBook
On this page
  • Problema
  • Solução

Was this helpful?

Padrão Facade

PreviousPadrão AdapterNextPadrão Decorator

Last updated 4 years ago

Was this helpful?

Antes de falar do Padrão Facade, vamos falar um pouco sobre arquitetura de software. Especialmente sobre Camadas físicas e lógicas.

Camada física se refere a parte estrutural dos componentes com foco na infraestrutura (hardware, sistema operacional e serviços/servidores) e suas responsabilidades no sistema. Já a Camada lógica se refere a organização dos componentes do sistema ou aplicação, os módulos, pacotes, etc.

Uma boa prática que se prega no projeto da arquitetura de software é que cada camada lógica só deve interagir com a(s) camada(s) imediatamente adjacente(s), visando a maior separação de atribuições (coesão) e o baixo acoplamento.

Problema

Imagine o uso de um subsistema de compras, onde o uso de várias classes são necessárias para realizar uma compra. Se a classe Cliente depende de várias classes deste subsistema (como na figura abaixo), significa que ele sabe muitos detalhes, e consequentemente, está acoplado.

Como diminuir o acoplamento entre estas camadas?

Solução

A intenção do padrão:

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

Pela intenção é possível notar que o padrão pode ajudar bastante na resolução do nosso problema. O conjunto de interfaces seria exatamente o conjunto de subsistemas. Um subsistema é análogo a uma classe, uma classe encapsula estados e operações, enquanto um subsistema encapsula classes.

Nesse sentido o Facade vai definir operações a serem realizadas com estes subsistemas. Assim, é possível definir uma operação padrão para o subsistema de compras, evitando a necessidade de chamar os métodos separadamente. Nesse cenário, os detalhes do subsistema ficam isolados, podendo ser trocados a qualquer momento.

O Facade desacopla o sistema, favorecendo a separação de responsabilidades. Um sistema bem projetado tem que ser um sistema desacoplado, com suas partes independentes uma das outras. Um sistema com fraco acoplamento possui uma série de benefícios.