Noções Básicas sobre Padrões de Design: Fachada usando Pokemon e Dragonball Exemplos!

Carlos Caballero em HackerNoon.com Seguir Abr 5 · 6 min ler

Existem 23 padrões de design clássico, descritos no livro original, Design Patterns: Elements of Reusable Object-Oriented Software . Esses padrões fornecem soluções para problemas específicos, frequentemente repetidos no desenvolvimento de software.

Neste artigo, vou descrever como o padrão da fachada; e como e quando deve ser aplicado.

Padrão de Fachada: Idéia Básica

O padrão de fachada (também soletrado fachada ) é um padrão de design de software comumente usado em programação orientada a objetos . Analogamente a uma fachada na arquitetura, uma fachada é um objeto que serve como uma interface frontal que mascara um código subjacente ou estrutural mais complexo. – Wikipedia

Fornecer uma interface unificada para um conjunto de interfaces em um subsistema. O Facade define uma interface de nível superior que facilita o uso do subsistema.- Padrões de Design: Elementos do Software Orientado a Objetos Reutilizáveis

A principal característica deste padrão é usar uma classe que simplifica a interface de um sistema complexo. Portanto, esses são dois problemas que esse padrão resolve:

  1. Subsistema complexo é mais fácil de usar.
  2. As dependências de um subsistema são minimizadas.

Em suma, o padrão de fachada contém várias instâncias de classes diferentes que devem ser ocultadas para o cliente. É assim que a interface é simplificada. O diagrama da UML desse padrão é o seguinte:

A classe Facade é um middleware entre os módulos e o cliente externo. Na UML existe uma única classe Facade mas o padrão pode ser usado entre diferentes camadas quando a interface é muito complexa.

Padrão de fachada: quando usar

  1. Existe um sistema complexo e você precisa de uma interface simples para se comunicar com ele.
  2. O código é fortemente acoplado porque os clientes precisam de um amplo conhecimento sobre o sistema. O padrão Fachada permite reduzir o acoplamento entre os componentes.
  3. O sistema precisa de um ponto de entrada para cada nível de software em camadas.

O Padrão de Fachada tem várias vantagens, resumidas nos seguintes pontos:

  • O código é mais fácil de usar, entender e testar já que a fachada simplifica a interface.
  • Limpe o código porque o cliente / contexto não usa uma interface complexa e o sistema é mais flexível e reutilizável .

Fachada padrão – Exemplo 1: Um cliente deseja usar várias classes de diferentes sistemas

Agora vou mostrar como você pode implementar esse padrão usando JavaScript / TypeScript. No nosso caso, System1 um problema no qual há uma classe chamada Client que define dois métodos que usam várias classes de diferentes pacotes ( System1 e System2 ). Esses pacotes são compostos por várias classes que possuem vários métodos públicos. O diagrama UML a seguir mostra o cenário que acabei de descrever.

O código do client associado é o seguinte:

O principal problema nesta solução é que o código está acoplado. Isso significa que o cliente precisa saber onde está e como funciona cada classe. A grande lista de importações é o primeiro sintoma de que uma fachada é a solução do nosso problema. Outro sintoma de aviso é que o cliente exigiu um amplo conhecimento sobre a operação de cada classe.

A solução é usar um padrão de fachada que consiste em uma classe ( Facade ) que usa System1 e System2 . Ou seja, o novo diagrama UML usando o padrão de adaptador é mostrado abaixo:

O código associado ao cliente e fachada são os seguintes:

No novo código, o cliente delega a responsabilidade à fachada, mas a fachada está executando a mesma funcionalidade que o cliente. De fato, se o código está aumentando, a fachada pode ser um antipadrão chamado BLOB ( https://sourcemaking.com/antipatterns/the-blob ). Então, uma boa idéia é usar uma fachada em cada pacote, como você pode ver nas seguintes UMLs:

O código associado ao client , facade , facadeSystem1 e facadeSystem2 nesta solução são os seguintes:

O cliente é exatamente o mesmo que na versão anterior.

A fachada usa cada uma das fachadas criadas para cada subsistema. Agora, o mais importante é que a classe Facade só conhece a interface fornecida pelo FacadeSystem1 e pelo FacadeSystem2 .

O FacadeSystem1 e o FacadeSystem2 só conhecem as classes do seu pacote. É muito importante lembrar que cada fachada exporta apenas as classes que devem ser públicas, e esses métodos podem ser a combinação de vários métodos entre classes internas.

Eu criei vários scripts npm que executam os exemplos do código mostrados aqui depois de aplicar o padrão Fachada.

npm run example1-problem
npm run example1-facade-solution-1
npm run example1-facade-solution-2

Padrão de fachadas – Exemplo 2: Pokemon e DragonBall Package juntos!

Outro problema interessante que é resolvido usando o padrão Facade é quando existem vários pacotes com diferentes interfaces, mas eles podem trabalhar juntos. No seguinte diagrama da UML você pode ver esta situação:

Neste caso, o cliente usa os pacotes DragonballFacade e PokemonFacade . Assim, o cliente só precisa conhecer a interface fornecida por essa fachada. Por exemplo, DragonballFacade fornece um método chamado genki que calcula o valor de vários objetos trabalhando juntos. Por outro lado, o PokemonFacade fornece um método chamado calculateDamage que interage com o resto das classes do seu pacote.

O código associado ao cliente é o seguinte:

E o código associado às fachadas são os seguintes:

Eu criei dois scripts npm que executam os dois exemplos mostrados aqui depois de aplicar o padrão Fachada.

npm run example2-problem
npm run example2-facade-solution1

Uma grande vantagem em favor da fachada está desenvolvendo o sistema mais simples de um não tão simples. Por exemplo, no pacote dragon ball existe um padrão de adaptador que não afeta o comportamento correto do cliente. Mas a complexidade do pacote Pokemon é maior, já que existe um padrão de design chamado Template-Method para o método de calculateDamage e um padrão de fábrica para a criação de diferentes pokemons. Toda essa complexidade é ocultada pelas fachadas e qualquer mudança nessas classes não afeta o comportamento do cliente, o que nos permitiu criar um sistema muito mais desacoplado.

Conclusão

O padrão de fachada pode evitar complexidade em seus projetos, quando há vários pacotes se comunicando uns com os outros, ou um cliente que requer o uso de várias classes, o padrão de fachada é perfeitamente adaptado.

O mais importante não implementou o padrão como mostrei, mas é capaz de reconhecer o problema que esse padrão específico pode resolver e quando você pode ou não implementar o padrão. Isso é crucial, pois a implementação irá variar dependendo da linguagem de programação usada.

Mais mais mais…