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: Metodologia Posted by Rafael on 30/10/2010 05:43 | Comentários (2)

Pessoal, hoje venho com um post bem pequeno, porém interessante. Na verdade, é mais uma curiosidade sobre Terminologias de TI.

Já ouvi diversas vezes: "Utilizamos uma Medologia de Desenvolvimento baseado em RUP na empresa na qual eu trabalho", ou então, "Utilizamos um Processo de Desenvolvimento baseado em RUP na empresa na qual eu trabalho".

Mas, afinal de contas, Metodologia e Processo são a mesma coisa?

A resposta é não! 

A Metodologia define o Processo a ser executado. Assim sendo, o que usamos e/ou executamos durante o Desenvolvimento de um Software é um Processo baseado em uma Metodologia qualquer.

Pra quem não sabia a diferença, fica aí a dica.

Até mais!

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!

Tags: , , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 17/10/2010 01:46 | Comentários (6)

Já ouvi diversas vezes as pessoas falarem: “Este é o Modelo de Casos de Uso do sistema XYZ”, ou então, “Este é o Diagrama de Casos de Uso do sistema XPTO”. Mas, afinal de contas, Modelos e Diagramas são a mesma coisa? Na verdade, Modelos e Diagramas não são a mesma coisa.

Quando dizemos que determinado documento é um Modelo, estamos dizendo que ele contém a definição de todo o sistema, ou seja, é um único documento que possui todas as informações de um sistema, relativas àquele artefato (Caso de Uso, Seqüência, Atividades, etc.). Por exemplo, um Modelo de Caso de Uso de um sistema, possui todos os casos de uso de um sistema.

Diagramas são perspectivas de um determinado Modelo. Criamos Diagramas para facilitar o entendimento (e conseqüentemente o desenvolvimento) de um sistema, ou seja, criamos perspectivas de um determinado modelo. Assim, quando dizemos que determinado documento é um Diagrama de Casos de Uso, sabemos que se trata de uma perspectiva do Modelo de Casos de Uso.

Por isso, sistemas possuem apenas um Modelo de Caso de Uso, e diversos Diagramas de Caso de Uso. O mesmo é verdadeiro para os demais artefatos.

Tags: , , | Categories: Tecnologia COM Posted by Rafael on 16/10/2010 09:19 | Comentários (0)

Hoje um colega de trabalho me fez a seguinte pergunta: O que é DCOM? De primeira eu não consegui responder com propriedade, mas afirmei que deveria ser alguma variação do COM, tecnologia já ultrapassada, mas ainda presente em várias corporações.

Pesquisei um pouco sobre o que é DCOM, e quero compartilhar isso com vocês, apenas como curiosidade: O que é DCOM e COM e DCOM.

Boa leitura!

Tags: , , , | Categories: ASP.NET, JavaScript Posted by Rafael on 14/10/2010 08:32 | Comentários (4)

Meses atrás eu me deparei com um pequeno problema. Eu precisava fazer com que um botão de uma página ASP.NET fosse desabilitado no clique, e o evento Click do mesmo fosse disparado.

Existem diversas maneiras de implementar essa solução, inclusive com padrões de projeto e melhores práticas. Porém, todo padrão deve ser utilizado com bom senso (falarei mais sobre isso em posts futuros), ou então, poderemos criar uma bazuca para matarmos uma mosca. Não faz o menor sentido.

Sou um grande adepto da utilização de padrões de projeto, porém, busco sempre um meio termo, um "ponto ótimo" ou "ponto de equilíbrio".

Assim sendo, nas circunstâncias que eu me encontrava, implementei da maneira mais rápida e prática possível, resolvendo muito bem o problema, e no tempo que eu precisava.

Até a chamada do evento Click ao clicar, nada demais. Com as facilidades do Microsoft Visual Studio, bastam dois cliques no botão, que o método Click é criado e associado ao botão, juntamente com o evento. Tudo muito rápido e fácil.

Aqui está o código gerado na página ASP.NET, seguido do código gerado no CodeBehind da mesma:

<asp:Button ID="botao" runat="server" Text="Clique" onclick="botao_Click"/>



protected void botao_Click(object sender, EventArgs e)

{

            

}

 

Legal, o evento clique já foi associado a um método pelo atributo onclick.

Existe um atributo chamado OnClientClick que é utilizado para invocar scripts no lado do cliente (client side), ou seja, é utilizado para invocar scripts da própria página. Assim que o evento Click é disparado, o script contido ou referenciado no atributo OnClientClick é invocado, e, se o retorno do script for true, o método associado ao atributo onclick é invocado.

O script em JavaScript e o código do botão da página ASP.NET ficaram assim:

<script type="text/javascript">

    function desabilitarBotao() {

        document.getElementById("botao").disabled = true;

    }

<script>



<asp:Button ID="botao" runat="server" Text="Clique" onclick="botao_Click" 

          OnClientClick="javascript:return desabilitarBotao();"/>

 

Tudo parece estar correto. Porém, quando executamos a página, o botão é desabilitado como desejado, porém, o método botao_Click não é invocado.

Isso ocorre porque o IE desabilita toda e qualquer ação do botão quando o mesmo é desabilitado, o que faz sentido. Se estamos desabilitando um objeto, não queremos que alguma ação relacionada a ele seja disparada.

Agora é que entra a função setTimeout do JavaScript. Vejamos os parâmetros dessa função: setTimeout(code, delay), onde code é o código que queremos adiar sua execução, e delay é o tempo que queremos adiar o código, expresso em milisegundos.

Vamos modificar o script, adicionando a função setTimeout:

<script type="text/javascript">

    function desabilitarBotao() {

        window.setTimeout('document.getElementById("botao").disabled = true;', 50);

        return true;

    }

<script>

 

Definimos um delay de 50 milisegundos.

Para testarmos se o botão é desabilitado e o método do CodeBehind realmente é chamado, inseri um breakpoint dentro do método, e executei a aplicação ASP.NET:

Botão da página desabilitado:

É isso. Espero ter ajudado de alguma forma.

Até a próxima!

Tags: , , | Categories: C#, Linguagem de Programação Posted by Rafael on 12/10/2010 23:19 | Comentários (0)

Quando declaramos variáveis de tipos nativos em C#, sempre um valor default é associado às mesmas. Veja o código abaixo.

As variáveis foram declaradas, e note na coluna Value que cada uma recebeu um valor padrão. Isso, em determinadas situações, pode ser um problema. Imagine que você deseja persistir um objeto em uma tabela do banco de dados, e que, alguns campos dessa tabela permitem a inserção de valores nulos. Na compilação não teremos problemas, porém, uma exception será disparada em tempo de execução, se tentarmos atribuir um valor nulo à alguma propriedade do nosso objeto.

Para resolvermos esse problema, utilizamos os nullable types. Muito simples e fácil, basta inserirmos o símbolo ? à direita do tipo da variável, assim:

Notem na coluna Value que o valor atribuído a cada variável é null, ao invés do valor padrão de cada tipo. Assim, podemos atribuir valores nulos ao nosso objeto, e persisti-lo sem problemas.

Simples assim.

Até a próxima!