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 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!