Artigo .net Magazine 51 - Design Patterns � Parte 5

Chegamos ao quinto e �ltimo artigo de Design Patterns. Por cinco meses estamos aprofundando as melhores pr�ticas de desenvolvimento de software. Vimos os seguintes padr�es:

Strategy (ediç�o 47 da .Net Magazine)
Decorator e Template Method (ediç�o 48 da .Net Magazine)
Factory Method (ediç�o 49 da .Net Magazine)
Abstract Factory (ediç�o 50 da .Net Magazine)
Singleton e Composite (esta ediç�o)

Abordarei neste �ltimo artigo o padr�o Singleton, que vai nos mostrar como criar um objeto �nico, sem outras inst�ncias do mesmo tipo no mesmo dom�nio de aplicaç�o. Veremos tamb�m o padr�o Composite, que permitir� a utilizaç�o de �rvores de objeto, tratando as partes e o todo uniformemente, o que simplifica bastante o modelo de programaç�o.

S�o padr�es simples, mas que resolvem grandes problemas. Muitas vezes acabamos por achar soluç�es intermedi�rias, que simulam ou se parecem com estes padr�es, mas n�o atendem completamente �s mesmas necessidades. Veremos, como nos outros artigos, exemplos de aplicaç�o dos padr�es no pr�prio .Net Framework assim como veremos um caso de interligaç�o do padr�o Singleton com o padr�o de Factory.

O problema de um objeto �nico

Frequentemente nos deparamos com a necessidade de limitar a criaç�o de um determinado tipo a um �nico objeto. Existem v�rios tipos de objetos dos quais precisamos um s�, e n�o mais que um. Alguns exemplos s�o:

Um gerenciador de cache;
Um gerenciador de uploads ou downloads;
Um controlador de configuraç�o;

Em todos esses exemplos, voc� vai querer ter apenas um destes objetos em sua aplicaç�o. De que adianta, por exemplo, um gerenciador de cache, do qual voc� pode ter mais de um? Se voc� est� precisando de um dado que pode existir em cache, voc� quer requisitar o dado sempre ao mesmo gerenciador de cache. Da mesma forma, porque sua aplicaç�o teria mais de um gerenciador de upload? Se ela est� gerenciando uploads, � bom que isso seja feito por um �nico objeto, para que, ao solicitar a fila de uploads, a mesma lista seja retornada.

Configuraç�o � outro exemplo interessante e com bastante aplicaç�o. J� vi algumas vezes arquiteturas que concentram em um �nico objeto as responsabilidades de configuraç�o, como por exemplo, caminho e porta de SMTP para envio de mensagens, pol�ticas de tratamento de erro, entre outras informaç�es. Da mesma forma, ter um �nico objeto instanciado desta classe de configuraç�o � uma boa id�ia, o que evita o risco de estar entrando em contato com configuraç�es desatualizadas.

Como possibilitar a criaç�o de um �nico objeto? A palavra-chave �new�, parte integrante de grande parte das linguagens orientadas a objeto (C#, VB, Java, C++, entre diversas outras), permite criar quantos objetos voc� quiser de qualquer tipo. C�digos como o da Listagem 1 mostram como � f�cil criar quantos objetos quisermos de um determinado tipo.

  
 'classe de gerenciador de downloads
 'queremos uma s� desta
 Public Class GerenciadorDeDownloads
    Public Function ObterDownloads() As List(Of Download)
    End Function
    Public Function SubmeterNovoDownload(ByVal d As Download) As Boolean
    End Function
 End Class
 Public Class Download
    Public Sub New(ByVal strUrl As String)
    End Sub
 End Class
 
 Public Class Cliente
  Public Sub Funcao()
    'criaç�o de v�rios gerenciadores, e agora?
    Dim g1 As New GerenciadorDeDownloads
    Dim g2 As New GerenciadorDeDownloads
    Dim g3 As New GerenciadorDeDownloads
    g1.SubmeterNovoDownload(New Download("http://www..."))
    g2.SubmeterNovoDownload(New Download("http://www.outro..."))
    g3.SubmeterNovoDownload(New Download("http://www.maisoutro..."))
    'temos agora 2 listas de gerenciadores...
    Dim l1 As List(Of Download) = g1.ObterDownloads()
    Dim l2 As List(Of Download) = g2.ObterDownloads()
  End Sub
 End Class

Listagem 1. Como fazer para controlar a instanciaç�o do objeto

O padr�o Singleton

� para atender esse cen�rio que o padr�o Singleton foi compilado. Este padr�o serve unicamente para nos ajudar a criar um �nico objeto de um determinado tipo, dentro do contexto de uma aplicaç�o.

O padr�o Singleton utiliza uma construç�o muito peculiar para resolver o �problema do new�. Veja o seguinte c�digo:


Public Class GerenciadorDeDownloads
    Private Sub New()
    End Sub
  End Class

Muitas pessoas n�o sabem que essa construç�o � poss�vel, mas ela � perfeitamente legal no .Net e na OO em geral. Parece estranho declarar um construtor privado, afinal, � ele quem permite instanciar a classe, e isso significaria que a classe n�o pode ser instanciada. Se a classe s� pode ser instanciada por ela mesma (o construtor � privado) e n�o existe nenhuma classe instanciada, essa funç�o n�o vai rodar nunca, e ser� imposs�vel criar o objeto. Acabamos de criar um paradoxo, um problema sem soluç�o, certo? Errado. �Privado� quer dizer que nenhum outro objeto pode chamar este m�todo, mas nada impede do pr�prio tipo chamar o construtor atrav�s de um m�todo est�tico (�static� ou �shared�), e m�todos est�ticos n�o dependem de objetos instanciados, logo, n�o h� depend�ncia do construtor.

Assim, utilizando um m�todo est�tico, podemos criar o objeto:"

[...] continue lendo...

Artigo .net Magazine 51 - Design Patterns � Parte 5

Artigo da Revista .NET Magazine - Edição 51.

O problema de um objeto �nico

O padr�o Singleton

Artigos relacionados