Twitter
RSS
Mostrando postagens com marcador Design Pattern. Mostrar todas as postagens
Mostrando postagens com marcador Design Pattern. Mostrar todas as postagens

Builder

Posted by Hugo Estevam Longo | Posted in | Posted on 15:39
0
Definição: Separa a criação do objeto complexo da sua representação. O mesmo processo de construção pode criar diferentes representações.

As classes e/ou objetos que participam deste padrão são:

• Builder (VeiculoBuilder) o especifica uma abstract interface para a criação das partes do objeto tipo Produto • ConcreteBuilder (MotoBuilder, CarroBuilder, CaminhaoBuilder) o constrói e reúne partes do objeto Produto que implementa a interface Builder o define e marca a criação da representação do objeto o fornece uma interface para devolver um objeto do tipo Produto • Director (Concessionaria) o constrói um objeto usando a interface Builder • Product (Veiculo) o representa o objeto complexo antes da construção. o incluí as classes que definen as partes que constituem o objeto, incluindo interfaces para reunir as partes no resultado final

Builder: Quando e onde usar? O padrão Builder é um padrão de projeto de criação de objetos que permite o cliente contruir um objeto complexo especificando somente seu tipo e conteúdo. Os detalhes da construção são escondidos inteiramente do cliente. A motivação mais comum para usar o padrão Builder é para simplificar o code do cliente que cria objetos complexos. O Cliente pode apenas especificar as etapas que são necessárias para o Builder criar o objeto, sem ter conhecimento de como o trabalho atual é finalizado. Um cenário aonde você deve considerar o uso do padrão de projeto Builder é quando é deselvolvido um gerador de código. Você pode escrever uma aplicação que cria stored procedures para diferentes tipos de banco de dados(SQL Server, Oracle, DB2). A saída real é bastante diferente, mas as etapas para a criação dos procedimentos contidos no CRUD(Create, Read, Update, Delete) são todos muitos similares.

O padrão Builder não é amplamente usado, mas pode ser encontrado em duas classes do .NET Framework. VBCodeProvider e CSharpCodeProvider criam classes Builder através do método CreateGenerator. O método CreateGenerator retorna uma interface ICodeGenerator onde a geração do código fonte pode ser controlado.

Para ver um exemplo do design pattern Builder na prática é só baixar o projeto de exemplo que segue no link abaixo: Exemplo padrão Builder (VS2008)

Até a próxima...

Continue Reading

Abstract Factory

Posted by Hugo Estevam Longo | Posted in | Posted on 19:53
1
Definição: Fornece uma interface para criar família de objetos relacionados ou dependentes sem especificar a classe concreta deles.

As classes e/ou objetos que participam deste padrão são: • AbstractFactory (ContinenteFactory) o declara uma interface para operações que criam produtos abstratos • ConcreteFactory (AfricaFactory, AmericaFactory) o implementa a operação para criar um objeto produto concreto • AbstractProduct (Herbivoro, Carnivoro) o declara uma interface para um objeto do tipo produto • Product (Gnu, Leao, Bufalo, Lobo) o define um objeto produto para ser criado pela fábrica concreta que implementa a interface AbstractProduct • Client (MundoAnimal) o usa as interfaces declaradas pelas classes AbstractFactory e AbstractProduct

Abstract Factory: Quando e onde usar? O padrão Abstract Factory provém um cliente com uma classe que cria objetos que possuem relação através de características comuns. Outra razão e benefício para criar objetos usando o padrão Abstract Factory é especialmente quando os contrutores das classes são chamadas diretamentes para criar objetos diferentes(overloads). Construtores são limitados no controle de processos de criação de objetos em geral. Se sua aplicação necessita de maior controle, considere usar um Factory. As Factorys incluem cenários que envolvem caching de objetos, sharing, re-using e aplicações que mantenham contadores de objetos e tipos.

Existe momentos em que o cliente não conhece exatamente que tipo deve construir. Isso pode ser resolvido fácilmente com o uso de tipos base ou interface e a fábrica pode passar parâmetros ou outros tipos de informações para tomar essa decisão para o cliente. Um exemplo disso são os provider especificos dos objetos ADO.NET(DbConnection, DbCommand, DbDataAdapter, etc).

Os contrutores não passam muito bem a sua intenção quando existem vários overloads por que eles necessitam ter o mesmo nome da classe (ou Sub New no VB.NET). Construtores com muitos overloads acabam confundindo os desenvolvedores na hora de decidir qual deles usar. Substituir construtores por métodos factory que mostram a sua intenção muitas vezes é o melhor a fazer.

Exemplo:

Vários construtores sobrecarregados, qual deles você deveria usar? 

// C# 
public Veiculo (int passageiros);
public Veiculo (int passageiros, int cavalosPotencia);
public Veiculo (int rodas, bool trailer);
public Veiculo (string tipo);


' VB.NET
Public Sub New(ByVal passageiros As Integer)
Public Sub New(ByVal passageiros As Integer, ByVal cavalosPotencia As Integer)
Public Sub New(ByVal rodas As Integer, ByVal trailer As Boolean)
Public Sub New(ByVal tipo As String)

Com o padrão Factory o código fica mais expressivo e os desenvolvedores mais produtivos: 

// C#
public Veiculo CriaCarro(int passageiros);
public Veiculo CriaSport(int passageiros, int cavalosPotencia);
public Veiculo CriaOnibus(int rodas, bool trailer);
public Veiculo CriaBarco();
public Veiculo CriaMoto();


' VB.NET 
Public Function CriaCarro(ByVal passageiros As Integer) As Veiculo
Public Function CriaSport(ByVal passageiros As Integer, ByVal cavalosPotencia As Integer)As Veiculo
Public Function CriaOnibus(ByVal rodas As Integer, ByVal trailer As Boolean)As Veiculo
Public Function CriaBarco()As Veiculo
Public Function CriaMoto()As Veiculo

Para ver um exemplo do padrão AbstractFactory na prática é só baixar o projeto que segue no link abaixo:

http://cid-17621fcd61d3a95a.skydrive.live.com/self.aspx/Blog/AbstractFactory.zip (VS 2008)

Até a próxima...

Continue Reading

Assinar: Postagens (Atom)