Conhecendo Design Patterns e o padrão Strategy

Nest post falarei um pouco sobre design patterns, algo que existe há décadas, muitas universidades ignoram e consequentemente poucos desenvolvedores sabem o que são ou sabem utilizar na prática.

Eu mesmo comecei a estudar sobre o assunto há uns 2 anos e, aos poucos, fui começando a entender e a aplicar alguns dos padrões mais conhecidos.

Breve histórico

No final dos anos 70, “padrão de projeto” era um conceito da Arquitetura, descrito no livro “A Pattern Language“, do famoso arquiteto americano austríaco Christopher Alexander. Já nos anos 80, Kent Beck e Ward Cunningham começaram a aplicar a ideia de padrões na área de programação.

Porém, somente em 1995, os padrões de projeto (ou design patterns) ganharam popularidade, quando Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides publicaram o livro “Design Patterns – Elements of Reusable Object-Oriented Software“, catalogando 23 design patterns. Esses 4 autores ficaram então conhecidos como Gang of Four (GoF), que também é um termo usado para se referir aos padrões do livro (GoF Design Patterns). (Quem souber de onde surgiu o nome Gang of Four me avise!)

Os GoF Design Patterns são, atualmente, considerados a base para vários outros padrões e o livro acima se tornou um clássico, sendo citado em inúmeros artigos, palestras e outros livros.

Definição

Mas afinal, o que é um design pattern?

Um design pattern descreve uma solução geral para um problema de design que ocorre com frequência na área de desenvolvimento de software. Sendo assim, design pattern não é código pronto para reaproveitar em sua aplicação e sim um modelo para resolver um problema.

Exemplo (Padrão Strategy)

Ainda perdido? Vou tentar clarear melhor com um exemplo prático do padrão Strategy. Este padrão, além de muito popular, é bem simples de ser entendido.

O padrão Strategy serve para “definir uma família de algoritmos, encapsular cada uma delas e torná-las intercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam” (como definido no livro do GoF).

Em outras palavras, Strategy nos permite configurar uma classe com um de vários comportamentos, utilizando o conceito de OO chamado de composição.

A estrutura deste padrão pode ser visualizada pelo seguinte diagrama de classes:

(figura obtida de DoFactory.com)

Imagine que, em uma aplicação de vendas, um Pedido possua duas formas diferentes (estratégias) de se calcular a taxa de entrega do mesmo: Padrão e Expresso.

Neste caso, o Pedido (Context) seria configurado por um cliente (classe que o utiliza) com a estratégia desejada. A implementação da classe Pedido poderia ser algo como (por simplicidade inclui apenas a estratégia):

public class Pedido
{
    // utilizando composição: o pedido mantém uma referência (passada em seu construtor)
    // para a Strategy base, normalmente uma interface ou classe abstrata

    private ICalculadorDeFrete _calculadorDeFrete;
    public Pedido(ICalculadorDeFrete calculadorDeFrete)
    {
        _calculadorDeFrete = calculadorDeFrete;
    }

    public decimal CalcularFrete()
    {
        // delegando o cálculo do frete para o objeto Strategy configurado
        return _calculadorDeFrete.CalcularFretePara(this);
    }
}

Abaixo escrevemos a Strategy base ICalculadorDeFrete:

public interface ICalculadorDeFrete
{
    decimal CalcularFretePara(Pedido pedido);
}

Implementamos, então, as estratégias concretas:

// frete "Padrão"
public class CalculadorDeFretePadrao : ICalculadorDeFrete
{
    public decimal CalcularFretePara(Pedido pedido)
    {
        // aqui vai o algoritmo de cálculo de frete "padrão"
    }
}

// frete "Expresso"
public class CalculadorDeFreteExpresso : ICalculadorDeFrete
{
    public decimal CalcularFretePara(Pedido pedido)
    {
        // aqui vai o algoritmo de cálculo de frete "expresso"
    }
}

Temos, assim, toda a estrutura implementada: o contexto (Pedido), a Strategy base (ICalculadorDeFrete) e as Strategies concretas (CalculadorDeFretePadrao e CalculadorDeFreteExpresso).

Dessa forma, o cliente que for utilizar o Pedido, poderá configurá-lo com o calculador desejado:

// alguma classe que utilize o Pedido
// pedido criado com o cálculo de frete padrão
var pedido1 = new Pedido(new CalculadorDeFretePadrao());
var fretePadrao = pedido1.CalcularFrete();

// pedido criado com o cálculo de frete expresso
var pedido2 = new Pedido(new CalculadorDeFreteExpresso());
var freteExpresso = pedido2.CalcularFrete();
.....
.....

Simples não é? Com isso ganhamos em flexibidade, obedecendo alguns princípios básicos da OO:

1. Programe para abstrações: notem que nosso Pedido não depende diretamente de nenhum calculador concreto e sim da interface ICalculadorDeFrete.
2. Open-closed principle: nosso Pedido não terá nenhum impacto caso o número de classes derivadas aumente (precisamos de um novo cálculo de frete) e nem se precisarmos alterar o algoritmo de algum calculador.

Vale lembrar que cada padrão pode ter variações de uma solução para outra. No exemplo dado, a estratégia adotada é passada via construtor do Pedido, mas poderia ser diretamente no método que a utiliza ou ainda, Pedido poderia implementar um método específico para “setar” a estratégia de cálculo.

Outra situação: o método CalcularFretePara recebe o próprio contexto (Pedido), o que é apenas uma alternativa. O Pedido poderia passar para o método somente os campos necessários para o cálculo do frete.

O que eu ganho com eles?

Agora que você já sabe de onde vieram, o que são e já viu um deles na prática, você pode estar se perguntando: o que eu ganho ao utilizar design patterns? Como eu sei em que situação aplicar determinado(s) padrão(ões)?

Vamos a algumas vantagens:

– Vocabulário comum entre desenvolvedores: devs que conhecem padrões podem conversar “dando nome aos bois”, ou seja, ao invés de explicar a solução contando uma história (muitas vezes confusa), pode-se dizer “utilizei o padrão X”.

– Facilitam na aplicação de técnicas e princípios de OO, como herança, composição, polimorfismo e SOLID.

– Um padrão pode ser utilizado para refatoração de um código ruim, altamente acoplado e de baixa coesão.

– Todos esses ítens colaboram para melhor facilidade de extensão e manutenção do software.

Para saber quando aplicá-los, você deve primeiramente conhecê-los e entendê-los bem (cada design pattern possui uma intenção explícita, explicando qual sua finalidade – como a citada acima no padrão Strategy). Feito isso, não se preocupe, a experiência vai te guiar e você vai naturalmente “enxergar” onde cabe determinado padrão.

Mas cuidado!

“Conhecê-los bem” e “saber onde colocá-los” não significa que eles DEVAM ser aplicados por todo o software. Design Patterns é muito legal, e por isso nos empolgamos em querer utilizá-los a qualquer custo, o que pode ser perigoso!

Não se esqueça que devemos sempre pensar simples (KISS) e não sair acrescentando código que não iremos precisar (pelo menos, em um primeiro momento) (YAGNI).

Por onde começar?

Interessou? Sugiro começar pelo ótimo Head First: Design Patterns, que é um livro muito didático. Seus exemplos estão em Java, mas como se trata basicamente de conceitos de OO, é praticamente idêntico ao C#. (Se não me engano, no site da editora pode ser feito o download dos exemplos em C#.).

O livro do GoF, mencionado no início, é um clássico, mas sua leitura é mais complicada. Por se tratar de um livro mais antigo, seus exemplos estão em C++ e há várias citações a aplicativos daquela época e ao SmallTalk (incluindo alguns códigos). Portanto, não recomendo como primeira leitura.

Um site muito conhecido sobre o assunto é o www.dofactory.com, voltado para o .Net, que possui exemplos de código em C# para todos os 23 padrões do GoF. Vale a pena conferir!

Conclusão

Design Patterns estão por aí há muito tempo e merecem ser observados com carinho. Sabendo utilizá-los, podemos melhorar muito o design de nossas aplicações. Contudo, devemos ter cuidado para não utilizá-los indiscriminadamente, complicando o que poderia ser mais simples e saindo do verdadeiro foco que é entregar software.

Acompanhe mais sobre design patterns pela tag “design patterns”.