Design Patterns – Factory Method

No post Design Patterns foi feita uma introdução sobre soluções reutilizáveis, propostas pelo Gang Of Four (GoF) [1], para determinados problemas no desenvolvimento de software. Dando continuidade ao post anterior, esse post irá descrever o padrão Factory Method.

Este padrão define uma interface para a criação de um objeto, mas deixa que as subclasses definam qual classe será instanciada. O Factory Method permite adiar a instanciação para subclasses.

Considere que você deva implementar um sistema que trabalhe com diversas categorias de produtos, por exemplo:

  • Eletrônicos
  • Livros
  • MP3

Qual seria a melhor solução para manipular esse conjunto de categorias em diversas operações?

A solução mais simples para esse problema é, para cada categoria de produto, criar uma classe que especialize os métodos definidos por uma superclasse Produto. A Figura 1 ilustra essa solução.

Produto

Figura 1 – Estrutura da classe de produtos

Porém, teremos um problema a ser resolvido com essa solução. Se a classe que trata o produto não tem como prever a qual categoria ele pertence, devemos criar um modelo que permita identificar qual objeto desejamos criar e, além disso, permita que novos tipos de categorias de produtos sejam adicionados ao sistema mais tarde.

O padrão Factory Method resolve esses problemas.

factorymethod

Figura 2 – Estrutura do padrão Factory Method

Com esse modelo, ilustrado na Figura 2, o cliente tem a visão apenas das interfaces ProdutoFactory e Produto, instanciada pelo método criarProduto(), não necessitando saber com qual das subclasses ele está operando. A vantagem deste modelo é não haver necessidade de se alterar o código quando uma nova categoria de produto é criada, pois, nesse caso é necessário apenas criar um novo Factory que estende o ProdutoFactory.

Existem quatro participantes nesse modelo:

  • Produtct (classe Produto): define a interface do objeto que o Factory Method cria;
  • Concrete Product (Eletronico, Livro, Mp3): implementa a interface Product;
  • Creator (ProductFactory): declara o Factory Method, que retorna um objeto do tipo de Product. Também pode definir uma implementação padrão para retornar um Concrete Product;
  • Concrete Creator (EletronicoFactory, LivroFactory, Mp3Factory): sobrescreve o Creator para retornar um tipo específico de Concrete Product.

Esse padrão pode ser utilizado quando:

  • Uma classe não pode antecipar a classe dos objetos que deve criar;
  • Uma classe quer que suas subclasses especifiquem os objetos criados;
  • Uma classe delega responsabilidade para uma entre várias subclasses de apoio e deseja-se localizar num ponto único o conhecimento de qual subclasse está sendo usada.

Referências

[1] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.

Links Externos

[1] Design Patterns

Por MATERA SYSTEMS

Postado em: 13 de junho de 2014

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário