Perguntas Frequentes sobre Padrões de Projeto 🔗

Neste artigo, respondemos perguntas sobre temas relacionados com padrões de projeto, isto é, sobre o Capítulo 6 do livro.

Segue a lista atual de perguntas:

1. Qual a diferença entre um Proxy e um Decorador?
2. Qual a diferença entre um Proxy e um Adaptador?
3. Qual a diferença entre Strategy e Template Method?
4. O que é uma especificação (specification)?
5. ´Qual a diferença entre uma Fachada e um API Gateway?

1. Qual a diferença entre um Proxy e um Decorador? 🔗

A diferença principal é a seguinte:

• No padrão Proxy, temos um objeto intermediário (o proxy) que dá acesso a um objeto base.

• No padrão Decorador, temos uma cadeia de objetos (os decoradores) que adicionam funcionalidades a um objeto base.

2. Qual a diferença entre um Proxy e um Adaptador? 🔗

Suponha um objeto que tenha uma interface I.

• Um proxy implementa a interfaceI, isto é, implementa todos os seus métodos. Normalmente, um proxy é usado para implementar requisitos não-funcionais, tais como segurança, persistência, distribuição, etc.

• Já um adaptador implementa uma outra interface, digamos que J e fica responsável por adaptá-la para a interface I. Para ilustrar, lembre-se de um adaptador de tomadas do padrão novo para o antigo ou vice-versa.

3. Qual a diferença entre Strategy e Template Method? 🔗

Suponha uma classe X:

• Suponha que a implementação de X precisa usar um serviço Y, o qual possui implementações alternativas Y1, Y2, Y3, etc. Porém, X não quer se comprometer com nenhuma dessas implementações. Nesse caso, podemos usar o padrão de projeto Strategy para encapsular a implementação de Y em uma hierarquia separada de classes e para permitir que sejam criadas instâncias de X que usam determinadas classes de tal hierarquia.

• Suponha agora que ao implementar X queremos definir o esqueleto de um algoritmo Y. Ou seja, X vai implementar Y, porém de forma parcial. Isso significa que as implementações de Y serão completadas em subclasses de X. Nesse caso, podemos usar o padrão de projeto Template Method para implementar esse esqueleto de Y na classe X.

4. O que é uma especificação (specification)? 🔗

Uma especificação é um padrão proposto por Eric Evans e Martin Fowler no seguinte artigo. Ele é também comentado no livro sobre Domain-Driven Design do Evans.

Conceitualmente, uma especificação é um predicado lógico – isto é, uma função que retorna verdadeiro ou falso – e que encapsula uma regra de negócio importante e complexa.

Uma especificação testa se um objeto está em um certo estado. Seja, por exemplo, uma fábrica que recebe pedidos de clientes para produção de certos itens. Suponha ainda que a regra para determinar se um Pedido está atrasado, em relação ao seu prazo planejado de entrega, é complicada. Por exemplo, ela pode depender dos itens que foram pedidos, da capacidade de produção da fábrica, do tempo que leva para entregar o pedido para o cliente, etc. Veja ainda que essas condições são dinâmicas, pois o estoque da fábrica muda diariamente.

Logo, podemos criar uma classe para encapsular a verificação de pedidos atrasados:

class EspecificacaoPedidosAtrasados {
   boolean pedidoEstaAtrasado(Pedido p) {
     // regra que verifica se "p" está atrasado  
   }    
}

Ou seja, a regra para determinar se um pedido está atrasado é complexa a ponto de justificar sua especificação em uma classe a parte. E, então, Pedido referencia essa nova classe:

class Pedido {
  ...
  EspecificacaoPedidoAtrasado espec = new EspecificacaoPedidoAtrasado();
  ...
}

Resumindo, especificação é o nome que se dá para classes que apenas implementam métodos booleanos que testam se um dado objeto atende a uma regra de negócio mais complexa. Logo, uma especificação torna a classe que usa a regra de negócio (no nosso exemplo, Pedido) mais simples e mais leve, isto é, com menos dependências. Fica também mais fácil criar regras de negócio alternativas. Por exemplo, uma segunda regra pode verificar se pedidos expressos estão atrasados.

5. Qual a diferença entre uma Fachada e um API Gateway? 🔗

Na verdade, essa diferença é pequena e sutil. Para explicá-la, vamos primeiro reproduzir a definição de Fachada, que usamos no Capítulo 6:

Uma Fachada é uma classe que oferece uma interface mais simples para um sistema. O objetivo é evitar que os usuários tenham que conhecer classes internas desse sistema; em vez disso, eles precisam interagir apenas com a classe de Fachada. As classes internas ficam encapsuladas por trás dessa Fachada.

Já API Gateway é um conceito parecido, porém mais usado no contexto de arquiteturas de software, particularmente arquiteturas baseadas em microsserviços. Segue uma definição adaptada do seguinte artigo:

Um API Gateway é um ponto de entrada único de um sistema e responsável por rotear as requisições dos clientes para os microsserviços apropriados, podendo interagir com múltiplos microsserviços e também combinar os resultados de tais interações. Um API Gateway pode ser também responsável por converter protocolos e implementar lógica relacionada com autenticação, limites de taxas de requisições e balanceamento de carga.

Veja então que essas últimas funcionalidades – conversão de protocolos, autenticação, balanceamento de cargas, etc – não são comuns em Fachadas.

Voltar para a página principal.