Salve pessoal. Tudo bem?

Continuando nossa viagem através dos 23 portais interdimensionais… Ops, filme errado… Digo, através dos 23 Design Patterns definidos pelo GoF, vamos abordar o próximo da lista, Factory Method.

Factory Method

Também conhecido como construtor virtual, este pattern permite às classes delegar para subclasses decidirem, sendo feito através da criação de objetos que chamam o método fabrica especificado numa interface e implementado por um classe filha ou implementado numa classe abstrata e opcionalmente sobrescrito por classes derivadas.

Calma, vamos detalhar isso para que possamos entender…

Criar um objeto geralmente exige processos complexos, não apropriados para incluir dentro da composição do objeto. A criação do objeto talvez necessite de uma duplicação de código significativa, talvez necessite informações não acessíveis para a composição do objeto, ou então não faça parte da composição do objeto. O pattern Factory Method trata esses problemas definindo um método separado para criação dos objetos, no qual as subclasses possam sobrescrever para especificar o “tipo derivado” do produto que vai ser criado. Daí o nome construtor virtual, pois este pode ser sobrescrito pelas classes de especialização.

Abaixo, podemos ver o exemplo em UML citado no livro do GoF, onde temos 4 participantes:

  • Creator: Declara o Factory Method que retorna o objeto da classe Product (abstrata);
  • ConcreteCreator: Sobrescreve o Factory Method e retorna um objeto da classe ConcreteProduct;
  • Product: Define uma interface para os objetos criados pelo Factory Method;
  • ConcreteProduct: Uma implementação para a interface Product.
Diagrama UML da estrutura de exemplo do pattern no livro do GoF

Este padrão é muito utilizado em frameworks para definir e manter relacionamentos entre objetos. O framework Spring, dependendo da configuração, pode utilizar um Factory Method para criar os seus Beans.

O objetivo do Factory Method está em diversas classes que implementam a mesma operação, retornarem o mesmo tipo abstrato, mas internamente instanciam diferentes classes que o implementam. Com o Factory Method o criador do objeto faz uma escolha de qual classe instanciar para o cliente. Para ser um Factory Method o método precisa retornar uma interface ou uma classe abstrata e, dependendo das necessidades do cliente, criar um objeto determinado como retorno. Um exemplo clássico do Factory Method são os iteradores tanto em Java como em .NET.

Vamos a outro exemplo: Uma aplicação, que é construída através de um framework baseado no padrão Factory Method, suporta a criação de documentos do tipo MeuDocumento. O framework é constituído pelas classes abstratas Aplicacao e Documento. A aplicação disponibiliza as classes concretas MinhaAplicacao e MeuDocumento. A classe MinhaAplicacao é uma implementação da abstração definida pela classe Aplicacao.

Diagrama UML do exemplo Documento / Meu Documento

Ficha resumo

Vamos a “ficha” de definição deste pattern.

  • Nome: Factory Method;
  • Objetivo / intenção: Criar um objeto geralmente requere processos complexos não apropriados para incluir dentro da composição do objeto; Também é conhecido como construtor virtual;
  • Motivação: A criação do objeto talvez necessite de uma duplicação de código significativa, talvez necessite informações não acessíveis para a composição do objeto, talvez não providencie um grau de abstração suficiente, ou então não faça parte da composição das preocupações do objeto. O Factory Method trata esses problemas definindo um método separado para criação dos objetos, no qual as subclasses possam sobrescrever para especificar o “tipo derivado” do produto que vai ser criado.
  • Aplicabilidade: Este padrão é muito utilizado em frameworks para definir e manter relacionamentos entre objetos. O framework Spring, dependendo da configuração, pode utilizar um Factory Method para criar os seus Beans. Normalmente cenários que precisamos de um construtor para um objeto padrão (abstrato) onde queremos implementar especializações mantendo uma base comum;
  • Estrutura: Abaixo temos um exemplo de estrutura onde temos duas classes abstratas, o Creator e o Product, e suas especializações, ConcreteCreator e ConcreteProduct. O ConcreteCreator é capaz de criar um Product especializado, no caso o ConcreteProduct, mantendo a base do Product (abstrato);
Estrutura UML para exemplificação do pattern
  • Consequências: Ganhamos com o baixo acoplamento, maior flexibilidade e eliminação da necessidade de acoplar classes específicas para aplicação em nível de código, mas temos alguns problemas que surgem, como o alto número de classes, que podem sobrecarregar o sistema, aumentando a quantidade de código a ser mantido;
  • Implementações: Conforme o exemplo no artigo, temos abaixo o código em C# que demonstra a implementação do pattern para o exemplo da criação de objetos que venham da classe abstrata Documento, o MeuDocumento;
  • Usos conhecidos: Esse patten é utilizado quando a classe não antecipa a classe do objeto que quer criar, uma classe quer suas subclasses para especificar os objetos que cria, quando você não quer que o usuário tenha que saber de cada subclasse ou quando você quer encapsular a criação de objetos. O framework Spring usa amplamente este pattern, normalmente associado com a injeção de dependência, onde temos métodos construtores de Beans, sendo que estes definem detalhes da instanciação destes Beans, retornando normalmente um tipo abstrato entre eles.
  • Padrões relacionados: Abstract Factory, Prototype e Template Method;

Concluindo

Este foi o padrão Factory Method. O mesmo facilita bastante quando trabalhamos com aplicações que devem instanciar objetos, onde temos especializações de suas instanciações, mas trabalhamos com um retorno comum entre estas especializações.

Na próxima parte desta série, vamos abordar o padrão Builder.

Não deixem de postar dúvidas e feedbacks sobre a série. Até breve!