A Infragistics, tradicional fabricante de componentes .Net, criou o Quince,  um meme para o compartilhamento de padrões de projeto. Pelo que percebi, o foco são padrões de interface para projetos .Net.

Cada meme possui um descritivo do problema, comentários e solução proposta.

É uma idéia interessante pois auxilia naqueles momentos em que você não sabe como resolver detalhes de uma interface visual, desde coisas simples como “alinho os labels à esquerda ou acima?” até como criar uma interface para um sistema de monitoramento de tempo real.

O projeto segue o padrão Web 2.0: você pode compartilhar seus próprios padrões.

E para finalizar, o mais legal de tudo: totalmente feito em Silverlight. A interface ficou muito leve e prática. Obviamente também é um showcase dos componentes da Infragistics.

Site: http://quince.infragistics.com

Descobri o site pelo blog do Otávio.

"Subindo" um pouco o nível da série de posts sobre design patterns, falarei hoje sobre o pattern "Repository".

Este pattern não é tão amplamente difundido, apesar de sua grande flexibilidade e poder de resolver nosso velho dilema de como isolar a persistência das demais camadas permitindo uma arquitetura plugável onde podemos utilizar múltiplos bancos de dados (na verdade, uma implementação concreta de repositório pode persistir dados em qualquer lugar, não necessariamente direto em um banco de dados.

Um repositório media o relacionamento entre o dominio e os dados. Imagine um repositório literalmente: é um lugar onde são guardadas coisas e coleções de coisas e onde efetuamos pesquisas dessas coisas.

Fonte: http://www.martinfowler.com/eaaCatalog/repository.html

Leia mais...

Em aplicações asp.net (webforms), uma das dúvidas freqüentes é o que fazer após uma ação, como por exemplo, gravar um novo registro. Acredito que seja comum a simples exibição de uma mensagem “Registro salvo com sucesso”, na mesma página onde os registros foram salvos.
Alguns problemas podem ocorrer com essa prática: caso o usuário submeta o formulário novamente, o registro poderá ser duplicado. Se pressionar atualizar, será exibida uma mensagem como a abaixo (a mensagem pode variar de acordo com o browser):

Para evitar esse tipo de problema deve-se procurar utilizar o Design Pattern PRG, onde após um post (submit), respondemos com um redirect para uma nova página, ao invés de simplesmente retornar um HTML, ou seja, no caso do asp.net, utilizamos o comando Response.Redirect(“pagina_sucesso.aspx”) para direcionar à uma nova página onde informaremos que o registro foi salvo com sucesso.

Continuando a série Design Patterns, nessa parte 2 iremos ver o padrão Observer.

Suponha que você tenha uma linha de produção que é automaticamente alimentada de componentes por diversos robôs assim que entra um novo pedido. Cada robô solta um determinado número de peças por quantidade de pedido.

Uma primeira abordagem seria algo como abaixo:

using System;

namespace NadaObserver
{
    class Program
    {
        static void Main(string[] args)
        {
            LinhaProducao linha1 = new LinhaProducao();
            Robo wallE = new Robo("Wall-E",linha1, 1);
            Robo c3po = new Robo("C3PO", linha1, 10);
            Robo sonny = new Robo("Sonny", linha1, 20);
            Robo terminator = new Robo("Terminator 800", linha1, 1000);

            //entrou novo pedido de 10 peças
            Pedido ped = new Pedido(10);
            
            // põe o povo para trabalhar

            wallE.SuprirPecas(ped.QtPedido);
            c3po.SuprirPecas(ped.QtPedido);
            sonny.SuprirPecas(ped.QtPedido);

            Console.ReadLine();
            
        }
    }

    public class Pedido{

        public Pedido(int qtPedido)
        {
            this.QtPedido = qtPedido;
        }

        public int QtPedido { get; set; }
       
    }


    public class LinhaProducao{

        public LinhaProducao()
        {
        }

        public void ReceberPecasDoRobo(int qtPecas)
        {
            Console.WriteLine("Recebi {0} peças para montagem", qtPecas);
        }
    }

    public class Robo
    {
        private int _fatorPecasPorPedido = 1;
        
        private LinhaProducao _linhaDeProducao = null;

        public Robo(string nomeRobo, LinhaProducao linhaDeProducao, int fatorPecasPorPedido)
        {
            this.NomeRobo = nomeRobo;
            this._linhaDeProducao = linhaDeProducao;
            this._fatorPecasPorPedido = fatorPecasPorPedido;
        }

        public string NomeRobo { get; set; }

        public void SuprirPecas(int qtItensPedido)
        {
            this._linhaDeProducao.ReceberPecasDoRobo(qtItensPedido * this._fatorPecasPorPedido);
        }
 
    }
}

Além de deselegante, essa solução trás alguns problemas: a aplicação chamadora sempre deverá saber quais são os robôs que estão ligados à cada linha de produção.

Leia mais...

No post “Linq to SQL Context único por aplicação” demonstrei a utilização de um Singleton para disponibilizar um único Linq Context por aplicação.

Para muitos é óbvio o que é um Singleton bem como um Design Pattern. No entanto, pensando em quem não conhece muito bem esses conceitos resolvi criar uma série de posts para demonstrar alguns dos principais design patterns que podemos usar no dia a dia.

Primeiramente, o que é um Design Pattern? Segundo a Wikipédia, “Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos”.
Ou seja, são peças de código, estratégias de resolução, etc, que nos poupam tempo na resolução de problemas pelos quais outros desenvolvedores já passaram. Essas soluções são amplamente utilizadas e testadas, não havendo, geralmente, contestações sobre o seu funcionamento.

Acredito que o maior problema com relação aos DP (Design Patterns) seja “quando” utilizá-los. Percebo que há muita confusão com relação a isso, devido principalmente quando se tenta utilizá-los a qualquer custo, apenas para estar “na moda”.

A primeira coisa que você precisa saber sobre os Design Patterns é: design patterns se encaixam na categoria best practices, ou seja, seria bom se você utilizasse, mas você não será condenado à forca caso não utilize.

Em seguida, você deve saber que deve procurar um design pattern para um problema, não o contrário, ou seja, achar algum problema para tentar enquadrá-lo sob um Design Pattern. Essa última situação é a mais comum quando se tenta apenas seguir a moda.

Sugiro que você procure ter uma visão geral sobre os principais Design Patterns para que no momento em que precisar de algum deles você tenha a percepção “automática” de que ele pode ser auxiliado por algo que outro desenvolvedor já pensou.

Design Patterns normalmente são independentes de linguagem, mas a implementação deles pode variar de acordo com os recursos disponíveis em cada linguagem. Obviamente aqui irei focar em C#.

Primeiro Pattern: Singleton

Leia mais...

Na empresa onde trabalho, estamos criando uma nova arquitetura de sistemas foi me solicitado que criasse um pequeno exemplo usando essa arquitetura, com as classes Cidade, Estado, etc.

A princípio, o design mais comum seria o de criar uma superclasse comum (ex. "Região") e a partir dela herdar cada uma.

No entanto, IMHO, não é uma resposa tão óbvia, já que uma Cidade "é um" Região mas também "é um" divisão política.

Talvez, nesse caso, fosse mais interessante usar Interface.

Alguns links para estudo:

http://guj.com.br/posts/list/87814.java

http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/

http://www.datasuldirect.com.br/flash/JAVA_SC/Or_Obj.pdf

UPDATE (11/08)

Mais um post interessante sobre o mesmo assunto:No, inheritance is not the way to achieve code reuse!