Obrigado por visitar a devmedia.com.br!

Precisamos de você para divulgar nossos vídeos e cursos gratuitos para a comunidade.

Se você gosta da devmedia.com.br por favor dê-nos o seu clique para o Google+ e ajude outros desenvolvedores ao redor do mundo.



Obrigado por seu apoio!
Equipe DevMedia

sair sem compartilhar (x)
DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:

Padrões de projeto em .NET: Factory Method

Também conhecido como Virtual Constructor, este padrão tem por objetivo definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar...

 

Também conhecido como Virtual Constructor, este padrão tem por objetivo definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O Factory Method permite adiar a instanciação para subclasses.

 

Os frameworks usam classes abstratas para definir e manter relacionamentos entre objetos. Um framework é freqüentemente responsável também pela criação desses objetos.

 

Considere um framework para aplicações que possuem um cadastro de clientes. Duas abstrações-chave nesse framework são as classes Sistema e Cadastro. As duas classes são abstratas, e os clientes devem prover subclasses para realizar suas implementações específicas para a aplicação. Por exemplo, para criar uma aplicação para uma mecânica, definimos as classes SistemaMecanica e CadastroMecanica. A classe Sistema é responsável pela administração de Cadastros e irá criá-los conforme exigido – quando o usuário seleciona Consultar ou Novo, por exemplo, em um menu.

 

Uma vez que a subclasse Cadastro a ser instanciada é própria da aplicação específica, a classe Sistema não pode prever a subclasse de Cadastro a ser instanciada – a classe Sistema somente sabe quando um cadastro e não que tipo de Cadastro criar. Isso cria um dilema: o framework deve instanciar classes, mas ele somente tem conhecimento de classes abstratas, as quais não pode instanciar.

 

O padrão Factory Method oferece uma solução. Ele encapsula o conhecimento sobre a subclasse de Cadastro que deve ser criada e move este conhecimento para fora do framework.

 

As subclasses de Sistema redefinem uma operação abstrata CriarCadastro em Sistema para retornar a subclasse apropriada de Cadastro. Uma vez que uma subclasse de Sistema é instanciada, pode, então, instanciar Cadastros específicos da aplicação sem conhecer suas classes. Chamamos CriarCadastro um factory method porque ele é responsável pela “manufatura” de um objeto.

 

Quando usar Factory Method?

Use o padrão Factory Method quando:

 

  • Uma classe não pode antecipar a classe de objetos que criam;
  • Uma classe quer que suas subclasses especifiquem os objetos que criam;
  • As classes delegam responsabilidade para uma dentre várias subclasses auxiliares, e você quer localizar o conhecimento de qual subclasse auxiliar que é a delegada 

Estrutura

 

padprofactmethfig01.JPG

 

  • Produto (Cadastro): define a interface de objetos que o método fábrica cria.
  • ProdutoConcreto (MeuCadastro): implementa a interface de Produto.
  • Criador (Sistema): declara o método fábrica, o qual retorna um objeto do tipo Produto. Criador também pode definir uma implementação por omissão do método factory que retorna por omissão um objeto ProdutoConcreto.
  • CriadorConcreto (MeuSistema): redefine o método-fábrica para retornar a uma instância de um ProdutoConcreto.

 

Exemplo de código

Existem duas variedades principais para o padrão Factory Method. Na primeira, a classe Criador é uma classe abstrata e não fornece uma implementação para o método-fábrica que ela declara. Na segunda, Criador é uma classe concreta e fornece uma implementação por omissão para o método-fábrica. Também é possível ter uma classe abstrata que define uma implementação por omissão, mas isto é menos comum.

 

O primeiro caso exige subclasses para definir uma implementação porque não existe uma omissão razoável, assim contornando o dilema de ter que instanciar classes imprevisíveis. No segundo caso, o CriadorConcreto usa o método fábrica principalmente por razões de flexibilidade. Está seguindo uma regra que diz: “criar objetos numa operação separada de modo que subclasses possam redefinir a maneira como eles são criados”. Essa regra garante que projetistas de subclasses, caso necessário, possam mudar a classe de objetos que a classe ancestral instancia.

 

Vejamos, então, um exemplo para o segundo caso, em que o CriadorConcreto tem liberdade para definir o método-fábrica.

 

Public Interface Sistema

 

    Function Criar(ByVal CadastroID As String) As Cadastro

 

End Interface

 

Public Class SistemaMecanica

    Implements Sistema

 

 

    Public Function Criar(ByVal CadastroID As String) As Cadastro _  

    Implements Sistema.Criar

 

        If CadastroID.Trim.ToUpper.Equals("MECANICA") Then

            Return New CadastroMecanica

        ElseIf CadastroID.Trim.ToUpper.Equals("PADARIA") Then

            Return New CadastroPadaria

        End If

 

    End Function

 

End Class

 

No próximo artigo estaremos discutindo outro padrão de criação: Prototype





    1 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.



Dino
Muito bem Rafel!!! Finalmente alguem preocupado com a qualidade no desenvolvimento de software. Muito bem feito os artigos; Nivel GOF. Aguardo os outros padrões! Até. PS. Fica como sugestão no fim dos artigo sobre padrões de projetos um artigo, ou uma video aula, com uma aplicação usando todos os padroes juntos.


em 9/1/2007 18:13 - Responder

 



[Este post ainda não foi associado a uma sequência]
Autor
Rafael Nascimento

Rafael Nascimento (rafabirth@hotmail.com), é Microsoft Certified Professional em Visual Basic .NET e líder da competência .NET em uma consultoria multinacional.


Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
1   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]
Este post está disponível para assinantes da .net Magazine ou para quem possui Créditos DevMedia.

  Conheça os planos de créditos DevMedia e visualize esse post agora mesmo!

Plano conveniência – Neste plano este post custa R$ 0,00 (Compre agora)
Esse plano permite que você compre somente um post, pagando por ele seu preço sem desconto.

Plano ocasional: Aqui este post custa: R$ -1,00 (assinante) ou R$ -1,00 (não-assinante)
Este plano é ideal para quem tem interesse em mais de um post. Você compra um mínimo de R$ 50,00 em créditos e ganha, em média, 50% de desconto no preço do post. Compre Créditos agora!

Assinatura de Créditos (Plano econômico) – Aqui este post custa R$ -1,00
Este plano é ideal para quem tem interesse em muitos posts. Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post. Assine este plano agora!

> Saiba mais sobre o Sistema de Créditos DevMedia
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03