Padrões de Design C #: O Padrão de Fábrica

Morgan Kenyon em codeburst Segue 5 de jul · 4 min ler Foto de Ant Rozetsky no Unsplash

Padrões de Design são importantes! Quando enfrentamos problemas comuns, eles ajudam a orientar nossa solução na direção certa. Eles não são uma bala mágica, mas é sábio aprender com as opiniões de outros desenvolvedores (provavelmente mais inteligentes).

Eu publiquei um artigo falando sobre o Strategy Pattern , que vou referenciar no final deste artigo. Estou resolvendo o mesmo problema com os dois padrões, acho que valeria a pena comparar as duas soluções.

resumo do pedido

Digamos que você seja um desenvolvedor trabalhando em um aplicativo de comércio eletrônico. Toda vez que algo é comprado, um resumo dessa compra é enviado a jusante, para o qual a empresa está vendendo aquele item.

Um resumo bem simples, identificando qual fornecedor vendeu esse item. A única complexidade é que LawnChairCo recebe XML, enquanto MagicCubeInc e BestComputersInc recebem JSON.

Você poderia criar um cliente de API diferente, um que suporte XML, um que suporte JSON.

Você poderia usar o padrão de estratégia.

Mas vamos ver como seria sua solução se você usasse o padrão de fábrica.

Padrão de fábrica

A Wikipedia define o Padrão de Fábrica como "o padrão de método de fábrica é um padrão de criação que usa métodos de fábrica para lidar com o problema de criar objetos sem precisar especificar a classe exata do objeto que será criado".

O padrão de fábrica ajuda a abstrair os detalhes da criação de um objeto que precisamos. Agora, torna-se responsabilidade da fábrica decidir qual objeto criar e como criá-lo.

No nosso caso, precisamos gerar um corpo HTTP em XML ou JSON. Vamos criar uma fábrica para fazer isso.

Nosso OrderSummary tem informações do fornecedor. Isso permite que nosso método BuildContent () construa o HttpContent apropriado para o fornecedor específico de que precisamos. XML para LawnChairCo e JSON para o resto. Se incorporarmos novos fornecedores no futuro com requisitos diferentes, adicionar lógica adicional ao padrão de fábrica é simples.

Em seguida, vamos analisar nosso API Client e como ele usa a fábrica.

Apenas chama com Factory com o objeto orderSummary. Em seguida, envia o que for criado para o uri apropriado.

Nosso ApiClient não sabe que alguns resumos de pedidos estão gerando XML e outros JSON. Isso não é responsabilidade. Sua responsabilidade é criar a conexão Http e enviar a mensagem a jusante. É responsabilidade da Fábrica gerar a mensagem apropriada para o Fornecedor em questão.

Isso mantém nosso ApiClient fino e suas responsabilidades ao mínimo.

Estratégia de Fábrica v

Como mencionado anteriormente, meu artigo sobre o Strategy Pattern resolve o problema quase idêntico. Em um nível alto, o padrão Fábrica e Estratégia pode parecer muito semelhante. Mas existem alguns detalhes que os distinguem:

1. A Fábrica contém a lógica para gerar todas as classes possíveis necessárias. Considerando que, com o padrão de estratégia, a criação é geralmente escondida atrás de uma interface. Cada estratégia diferente é geralmente uma nova classe que implementa a interface.

Se você tivesse 10 cenários diferentes, para o Padrão de Fábrica ainda é 1 classe, mas com o Padrão de Estratégia são 10 classes. Muitas classes dificultam ver e comparar a lógica nos diferentes cenários. Não impossível, mas não tão conveniente quanto tudo em uma aula.

2. Com nosso exemplo de Padrão de Fábrica, os dados determinam a decisão sobre qual classe criar. Mas com o Strategy Pattern, o sistema orienta a decisão sobre qual interface injetar, geralmente através da injeção de dependência (DI). Qual é a vez de dirigir qual classe criar.

E se você estiver trabalhando em um sistema antigo que não tenha a estrutura DI necessária para o funcionamento do padrão de estratégia? E se seus dados não tiverem todas as informações necessárias para sempre tomar uma decisão precisa?

Eu não posso responder a estas perguntas para você. Você precisa tomar a melhor decisão, dada a situação em que se encontra. Talvez esteja usando o Padrão de Fábrica, talvez Estratégia, talvez seja outra coisa.

Takeaways

No final do dia Design Patterns são ferramentas em sua caixa de ferramentas proverbial. Conheça suas diferentes ferramentas, saiba como usá-las e aplique quando necessário. O padrão de fábrica não resolve todos os seus problemas. Mas provavelmente resolverá alguns deles. Quando você encontrar essas situações, fique feliz que o Padrão de Fábrica tenha poupado algum tempo de programação e design.