Tags: , | Categories: Padrões de Projeto Posted by Rafael on 12/05/2011 02:07 | Comentários (1)

Olá pessoal!

Hoje vamos falar um pouco sobre um padrão de criação bem simples, o padrão Prototype. Esse padrão tem como objetivo criar um "clone", ou seja, uma cópia, de um determinado objeto. Segue abaixo a definição do nosso livro base:

"Especificar os tipos de objetos a serem criados usando uma instância-protótipo e criar novos objetos pela cópia desse protótipo." [GAMMA, 2009].

Um dos diversos cenários que podemos aplicar o padrão Prototype é quando necessitamos guardar o estado de um objeto, em determinados pontos de execução de um processamento, por exemplo. Na maioria das vezes, é mais interessante criarmos "clones", ou cópias, de um objeto em determinado momento, do que criar a instância manualmente.

A estrutura do padrão Prototype é a seguinte:

Estrutura do Padrão Prototype

O padrão Prototype pode ser implementado em conjunto com os padrões AbstractFactory, Composite e Decorator. Estudaremos em breve sobre os dois últimos padrões citados.

No código de exemplo, criaremos uma classe abstrata chamada Ave que implementa a interface ICloneable, e uma classe concreta Calopsita que herda de Ave. O projeto completo pode ser baixado aqui: Prototype.zip (20,74 kb)

Segue o código implementado junto com a classe de teste:

Classe Ave.cs

Classe Calopsita.cs

Classe Teste

O resultado:

Resultado

Repare que o nome dos dois objetos é o mesmo, porém o código hash é diferente, ou seja, são objetos do mesmo tipo e com as mesmas características, porém, são objetos distintos.

Esse é o padrão Prototype, muito simples e fácil de entender e utilizar.

Até a próxima!

 

 

Referência Bibliográfica

GAMMA, Erich, Padrões de Projeto, Porto Alegre: Bookman, 2009.

Tags: , , | Categories: Padrões de Projeto Posted by Rafael on 07/05/2011 17:06 | Comentários (0)

Olá pessoal!

Hoje vamos falar um pouco sobre um padrão muito utilizado e, de igual modo, simples: o padrão Singleton.

Esse padrão tem como objetivo "garantir que uma classe tenha somente uma instância e fornecer um ponto de acesso global para a mesma". [GAMMA, 2000].

Em algumas situações precisamos garantir que apenas uma instância de uma determinada classe seja criada no contexto do sistema. São os casos de fazermos uso de propriedades específicas de configuração comuns à toda aplicação, utilização de um Proxy qualquer existente na sua empresa, que seja utilizado para integração dos sistemas, por exemplo.

Por se tratar de um padrão muito simples, vamos direto para a representação da sua estrutura, e logo em seguida para uma implementação de exemplo.

A estrutura do padrão Singleton é a seguinte:

Estrutura Singleton

Para que exista uma instância única na aplicação, precisamos criar um construtor privado na classe Singleton, uma variável estática, e implementarmos a lógica para criação da instância e o seu retorno. O código abaixo exemplifica isso:

Aqui está o projeto completo: Singleton.zip (20,92 kb)

Ao executar o projeto, se você inserir um breakpoint no método obterInstancia da classe ProxyConnectionDB e ir passo-a-passo, notará que ele cria a instância apenas na primeira execução (variável con1), pois a classe nunca foi utilizada. Porém, na segunda chamada (variável con2) o objeto já existe, e sua instância é retornada, sem criar uma nova instância.

O exemplo acima implementa o padrão Singleton pois tem um contrutor privado, e um método que cria e/ou retorna a instância da classe, que será acessada por um único ponto na aplicação.

Alguns padrões podem ser implementados usando Singleton. É o caso dos padrões Prototype, AbstractyFactory e Builder. Já conhecemos o padrão AbstractyFactory, e veremos os padrões Prototype e Builder em breve.

É isso!

Até a próxima!

 

 

Referência Bibliográfica

GAMMA, Erich, Padrões de Projeto, Porto Alegre: Bookman, 2009.

Tags: , | Categories: Padrões de Projeto Posted by Rafael on 03/01/2011 21:30 | Comentários (2)

Antes de qualquer coisa, quero nesse primerio post de 2011, desejar a todos vocês que acompanham o meu blog um Feliz 2011 com muita paz, saúde, sucesso e felicidade! Que Deus abençoe a todos vocês e os guie e guarde sempre!

Hoje falaremos sobre um dos padrões mais utilizados, o padrão Factory Method. Também conhecido como Virtual Constructor, tem por objetivo definir uma interface para a criação de um objeto, delegando a decisão sobre qual classe instanciar para as subclasses.

Já fizemos uso do padrão Factory Method tanto quando implementamos o padrão Abstract Factory, quanto quando implementamos o padrão Adapter. Além desses, o padrão Factory Method é utilizado na implementação de vários outros padrões. Isso demonstra o quão utilizado é o padrão Factory Method.

Utilizamos o padrão Factory Method quando queremos separar a lógica que define qual classe instanciar do aplicativo cliente, ou seja, a classe ou aplicativo cliente invoca um método de uma subclasse que retorna a instancia de uma outra classe de acordo com uma lógica específica, encapsulando assim o conhecimento sobre qual classe deve ser instanciada. A classe cliente tem apenas o conhecimento de quando criar a classe desejada, mas não possui o conhecimento de qual classe criar ou como a criar.

O padrão Factory Method segue o seguinte padrão:

Vou utilizar o exemplo o post anterior, para facilitar. Você pode baixar o código fonte do exemplo aqui.

Vamos analisar os objetos do exemplo:

 

Program.cs

class Program

{

    static void Main(string[] args)

    {

        ITerminal34 terminal = ComponenteHidraulicoFactories.ObterTerminal();

        terminal.Acoplar();



        Console.ReadKey();

    }

}

 

ComponenteHidraulicoFactories.cs

public class ComponenteHidraulicoFactories

{

    public static ITerminal34 ObterTerminal()

    {

        return new Adaptador12para34();

    }

}

 

ITerminal34.cs

public interface ITerminal34

{

    void Acoplar();

}

 

Adaptador12para34.cs

public class Adaptador12para34 : ITerminal34

{

    public void Acoplar()

    {

        Torneira12.Acoplar12();

    }

}

 

A classe Program (cliente) determina o momento (quando) em que uma instância de uma classe do tipo ITerminal34 deve ser criada, mas não como ou qual deve ser criada. Isso cabe ao método ObterTerminal() da classe ComponenteHidraulicoFactories, que retorna uma instância de Adaptador12para34, que por sua vez, implementa a interface ITerminal34.

O método ObterTerminal() da classe ComponenteHidraulicoFactories implementa o padrão Factory Method pois encapsula a logica de qual classe instanciar e como ela é instanciada, retornando apenas a instancia da classe escolhida, já criada.

Esse é o Factory Method. Um padrão simples e muito utilizado.

Até a próxima!

Tags: , | Categories: Padrões de Projeto Posted by Rafael on 30/12/2010 19:16 | Comentários (0)

Conversando hoje com um companheiro de equipe, percebi que um código exemplo fez falta no post anterior. Pensando nisso, desenvolvi um exemplo em C#, o qual vocês podem baixar aqui: Blog.DP.Adapter.zip (19,40 kb). Esse código de exemplo implementa o exemplo proposto no post anterior, seguindo o seguinte diagrama:

Um detalhe interessante nesse exemplo é o uso de um Factory Method, ou seja, um método que retorna a instância que se deseja. No nosso caso, uma instância da classe Adaptador12para34 é retornada, para evidenciarmos a chamada do método da classe adaptada Torneira12 (adaptee) através da interface Adaptador12para34. Abordaremos o padrão FactoryMethod em um próximo post com maiores detalhes e exemplos.

Ao executarmos o código, a seguinte mensagem é apresentada:

Note que essa mensagem encontra-se dentro do método Acoplar12(), dentro da classe Torneira12. Note também que, na classe Program que contém o método Main, associamos a instância da classe Adaptador12para34, que implementa a interface ITerminal34, retornada pelo Factory Method à variável terminal, e invocamos o método Acoplar() da instância, que, por sua vez, invoca o método Acoplar12 da classe Torneira12.

Temos assim a implementação do padrão Adapter, através da criação de uma interface (Adaptador12para34) que estabelece o acesso ao objeto implementado fora do padrão (Torneira12), para o padrão da aplicação, de forma transparente para o cliente, que no nosso exemplo é a classe Program.

Espero que esse exemplo auxilie no entendimento do padrão Adapter.

Até a próxima!

Tags: , | Categories: Padrões de Projeto Posted by Rafael on 28/12/2010 21:34 | Comentários (2)

Dando sequencia à nossa série sobre Padrões de Projeto, vamos falar um pouco sobre o padrão estrutural Adapter. Esse padrão, também conhecido como Wrapper, tem como objetivo criar uma interface comum entre classes, ou seja, classes com interfaces diferentes podem trabalhar em conjunto desde que uma interface adaptadora seja criada para tal fim.

Muitos já fizeram ou fazem uso desse padrão com freqüência no dia-a-dia, principalmente se fazem uso de frameworks ou toolkits de terceiros. Na maioria das vezes, existem classes que foram projetadas para serem reutilizadas, porém, isso não é possível pois elas não atendem a uma interface específica de um objeto de nossa aplicação. Para resolvermos esse problema, criamos uma interface adaptadora para que as classes possam trabalhar em conjunto.

Fazendo uma analogia bem simples, porém interessante, podemos imaginar que a nossa aplicação seja um sistema hidráulico residencial. Quando necessitamos trocar uma torneira (um componente do nosso sistema), por qualquer que seja o motivo, precisamos nos certificar se o tamanho da rosca da torneira (interface terceiro) é compatível com o tamanho do terminal (interface local) do encanamento. Caso o tamanho seja diferente, precisamos utilizar um adaptador (a nova interface criada) para que uma das interfaces seja igual a outra, e o conjunto funcione perfeitamente.

O padrão Adapter é o único padrão cujo escopo abrange tanto Classe quanto Objeto. Os diagramas abaixo, retirados do livro Padrões de Projeto, da GoF, base para todos os posts de padrões de projeto, ilustra bem a diferença entre Classe e Objeto:

Um adaptador de classe usa a herança múltipla para adaptar uma interface à outra:

Padrão Adapter - Escopo Classe

Um adaptador de objeto depende da composição de objetos:

Padrão Adapter - Escopo Objeto

Para finalizar, vamos retomar o nosso exemplo sobre o sistema hidráulico residencial. Consideremos que o tamanho dos tubos do sistema hidráulico, ou encanamento, da nossa residência seja padrão 3/4 de uma polegada, e queiramos utilizar uma torneira que tenha um tamanho 1/2 de uma polegada (nota: o tamanho 3/4 [0,75 polegadas] é 50% maior do que o tamanho 1/2 [0,5 polegadas]). Precisamos utilizar um adaptador que estabeleça uma interface entre 1/2 e 3/4 polegadas, ou seja, uma interface que adapte (adapter) a interface da torneira de 1/2 polegadas (adaptee) para uma interface definida especificamente (target) para o domínio do encanamento (cliente), que é 3/4 polegadas.

Assim, temos:

Espero que esse exemplo simples tenha facilitado o entendimento do padrão Adapter.

Até a próxima!

Tags: , , , | Categories: Padrões de Projeto Posted by Rafael on 17/11/2010 00:30 | Comentários (1)

Pessoal, depois de um longo tempo impossibilitado de escrever, venho falar sobre o nosso primeiro dos cinco padrões de criação, o Abstract Factory, também conhecido como Kit.

A definição do padrão Abstract Factory, segundo o livro Padrões de Projeto - Soluções reutilizáveis de software orientado a objetos, escrito pelos integrantes da "Gang of Four" ou "GoF" é a seguinte: "Fornecer uma interface para a criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.". A definição é auto-explicativa. Utilizamos o padrão Abstract Factory quando queremos construir um conjunto de classes e fornecer apenas a interfaces de acessos às mesmas, não as implementações propriamente ditas, principalmente quando um sistema deve ser independente de como seus objetos são criados. Ou então, quando você precisar garantir que um conjunto de objetos deve ser utilizado em conjunto.

Existem diversas maneiras de implementarmos o padrão Abstract Factory. Demonstrarei apenas uma, bem simplificada, para facilitar o entendimento. A seguir está o diagrama de classes e o código gerado na linguagem C# pode ser baixado aqui: AbstractFactory.zip (30,20 kb)

Consideremos que queremos criar uma aplicação que instancia objetos de acordo com o ambiente onde esteja rodando (web, stand-alone ou mobile). Para facilitar o nosso exemplo, essa informação estará no App.config do aplicativo, mas poderia estar em qualquer outro lugar ou ser consumida de qualquer outra forma.

Note que, na classe Cliente, não sabemos qual é o atual ambiente no qual a aplicação está rodando, apenas solicitamos a criação de um TextBox e de um Botão, através da instância retornada pela Factory. Desta maneira, não nos preocupamos com o "como" os objetos são implementados, apenas nos preocupamos em seguir o contrato estabelecido pela interface, mantendo implementação dos objetos restrita.

Se definirmos o valor da chave ambiente no App.config como web, temos a seguinte saída na aplicação Console:

Da mesma maneira, se alterarmos o valor da chave ambiente do App.config para standalone, temos a seguinte saída:

Não diferente, alterando para mobile, temos o seguinte:

Esse é um dos padrões de projeto mais utilizados por arquitetos e desenvolvedores. Seu conhecimento é essencial para quem almeja dominar o mundo dos Padrões de Projeto. O padrão Abstract Factory pode ser combinado com outros padrões, como o padrão Singleton ou Prototype. Abordarei a integração entre esses padrões assim que tivermos uma visão de geral de cada padrão, para facilitar o entendimento.

Padrões de Projeto, como citei anteriormente, não são implementados de uma única maneira. No nosso exemplo, utilizei interfaces no código C#, o que achei mais apropriado, pois não havia implementação, apenas queria estabelecer um contrato entre partes (classes). Porém, nada me impediria de, ao invés de utilizar interfaces, utilizar classes abstratas. Ao invés das classes concretas implementarem as interfaces, elas poderiam herdar o comportamento das classes abstratas. Usualmente, utilizamos interfaces quando não temos implementações padrão, e utilizamos classes abstratas quando temos pelo menos uma implementação padrão, que deve ser herdada pelas classes concretas. Essa abordagem é arquitetural, e foge do nosso foco que é aprender sobre padrões de projeto. O que eu quero deixar claro é que, não importa "o como" implementamos o padrão, desde que a implementação respeite o princípio do padrão, propriamente dito.

No próximo post sobre Padrões de Projeto, abordaremos o padrão Adapter, um padrão estrutural, também muito utilizado, mas não tanto quanto o padrão Abstract Factory.

Espero que esse exemplo simples tenha ajudado vocês de alguma forma.

Até a próxima!

Tags: , , | Categories: Padrões de Projeto Posted by Rafael on 19/10/2010 06:12 | Comentários (4)

Com esse post, inicio uma série sobre Padrões de Projeto (Design Patterns). Abordarei os 23 padrões de projeto de uma forma bem simples. A minha intenção é fazer uma breve descrição sobre cada padrão, seguindo de alguns exemplos, para ajudar àqueles que desenvolvem aplicativos Orientado a Objetos e não conhecem Padrões de Projeto.

Como citei em um post anterior, Padrões de Projeto devem ser utilizados com ponderação. Cada padrão foi criado para solucionar problemas específicos do dia-a-dia de desenvolvedores, porém, como todo e qualquer padrão, a grande maioria requer maior codificação. Por isso, a sua utilização em demasia, é prejudicial. Podemos chegar ao ponto de querer matar um simples e inofensível inseto com uma bazuca. Totalmente sem sentido.

Portanto, bom senso é muito bem-vindo na utilização de Padrões de Projeto.

Quando usamos padrões, agregamos qualidade ao nosso desenvolvimento. Consequentemente, diminuímos a produtividade. É impossível aumentar a qualidade e a produtividade ao mesmo tempo, de qualquer que seja o produto (no nosso caso, software). O que devemos fazer, é encontrar um ponto ótimo entre qualidade e produtividade, mas isso é assunto pra um outro post, só sobre Qualidade x Produtividade, o que não é o nosso foco agora.

Muitas vezes utilizamos técnicas para resolver problemas e criar soluções no nosso dia-a-dia, e nem sabemos que essas técnicas são padrões de projeto. Isso já aconteceu comigo, principalmente quando comecei a estudar padrões de projeto. Portanto, não se espante se ao longo do nosso estudo, se deparar com um padrão que você já utiliza, mas não sabia que é um padrão de projeto.

Os Padrões de Projeto são classificados em 3 grupos, de acordo com suas finalidades: Padrões de Criação, Padrões Estruturais e Padrões Comportamentais. São eles:

Padrões de Criação:

Padrões Estruturais:

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Façade
  • Flyweight
  • Proxy

Padrões Comportamentais:

  • Chain of Responsability
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

Iniciarei pelos seguintes padrões, que são os mais simples e comuns:

Logo após, darei sequência aos demais padrões.

Espero que gostem.

Aguardem!