Robson Castilho

Desenvolvendo software com qualidade

Conhecendo Design Patterns e o padrão Strategy

Publicado em 25/06/2011 por Robson CastilhoFala, galera

Nest post falarei um pouco sobre design patterns, algo que existe há décadas, muitas universidadesignoram 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 aaplicar 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 PatternLanguage (http://www.amazon.com/Pattern‑Language‑Buildings‑Construction‑Environmental/dp/0195019199%3FSubscriptionId%3D0G81C5DAZ03ZR9WH9X82%26tag%3Dzemanta‑20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D0195019199)“,do famoso arquiteto americano austríaco Christopher Alexander(http://en.wikipedia.org/wiki/Christopher_Alexander). Já nos anos 80, Kent Beck e Ward Cunninghamcomeç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, quandoErich Gamma, Richard Helm, Ralph Johnson e John Vlissides publicaram o livro “Design Patterns –Elements of Reusable Object‑Oriented Software (http://www.amazon.com/Design‑Patterns‑Elements‑Reusable‑Object‑Oriented/dp/0201633612%3FSubscriptionId%3D0G81C5DAZ03ZR9WH9X82%26tag%3Dzemanta‑20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D0201633612)“,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). (Quemsouber 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 livroacima 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 comfrequência na área de desenvolvimento de software. Sendo assim, design pattern não é código prontopara reaproveitar em sua aplicação e sim um modelo para resolver um problema.

Exemplo (Padrão Strategy)

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á‑lasintercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes que outilizam” (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 (http://www.dofactory.com/Patterns/PatternStrategy.aspx#_self1))

Imagine que, em uma aplicação de vendas, um Pedido possua duas formas diferentes (estratégias) de secalcular 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égiadesejada. A implementação da classe Pedido poderia ser algo como (por simplicidade inclui apenas aestratégia):

Abaixo escrevemos a Strategy base ICalculadorDeFrete:

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

1234567891011121314151617

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);    }}

1234

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

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

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

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

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 calculadorconcreto e sim da interface ICalculadorDeFrete.2. Open‑closed principle: nosso Pedido não terá nenhum impacto caso o número de classes derivadasaumente (precisamos de um novo cálculo de frete) e nem se precisarmos alterar o algoritmo de algumcalculador.

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

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

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 seperguntando: o que eu ganho ao utilizar design patterns? Como eu sei em que situação aplicardeterminado(s) padrão(ões)?

Vamos a algumas vantagens:

1234567891011121314151617

// 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"    }}

12345678910

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

Vamos a algumas vantagens:

– Vocabulário comum entre desenvolvedores: devs que conhecem padrões podem conversar “dandonome 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 eSOLID.

– Um padrão pode ser utilizado para refatoração de um código ruim, altamente acoplado e de baixacoesã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 designpattern possui uma intenção explícita, explicando qual sua finalidade – como a citada acima no padrãoStrategy). 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 osoftware. Design Patterns é muito legal, e por isso nos empolgamos em querer utilizá‑los a qualquercusto, o que pode ser perigoso!

Não se esqueça que devemos sempre pensar simples (KISS(http://en.wikipedia.org/wiki/KISS_principle)) e não sair acrescentando código que não iremos precisar(pelo menos, em um primeiro momento) (YAGNI(http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)).

Por onde começar?

Interessou? Sugiro começar pelo ótimo Head First: Design Patterns (http://www.amazon.com/First‑Design‑Patterns‑Elisabeth‑Freeman/dp/0596007124/ref=sr_1_2?ie=UTF8&qid=1308972875&sr=8‑2), que éum livro muito didático. Seus exemplos estão em Java, mas como se trata basicamente de conceitos deOO, é praticamente idêntico ao C#. (Se não me engano, no site da editora pode ser feito o download dosexemplos em C#.).

O livro do GoF (http://www.amazon.com/Design‑Patterns‑Elements‑Reusable‑Object‑Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1308972875&sr=8‑1), mencionado no início, é umclássico, mas sua leitura é mais complicada. Por se tratar de um livro mais antigo, seus exemplos estãoem 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 (http://www.dofactory.com), voltadopara o .Net, que possui exemplos de código em C# para todos os 23 padrões do GoF. Vale a penaconferir!

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ãoutilizá‑los indiscriminadamente, complicando o que poderia ser mais simples e saindo do verdadeirofoco que é entregar software.

Espero ter conseguido pelo menos atiçar a curiosidade de vocês para estudarem sobre o assunto. Vale

Espero ter conseguido pelo menos atiçar a curiosidade de vocês para estudarem sobre o assunto. Valemuito a pena!

Acompanhe mais sobre design patterns pela tag “design patterns”(http://robsoncastilho.com.br/tag/design‑patterns/).

[]s e até a próxima!

Esse post foi publicado em patterns e marcado boas praticas, design patterns, OCP, orientacao a objetos,SOLID, strategy. Guardar link permanente.

16 comentários sobre “Conhecendo Design Patterns e opadrão Strategy”

outedg disse:em 25/06/2011 às 19:08É… é realmente um pena que a faculdades acreditem q ensinar um pouco de lógica e de análiseestarão colocando profissionais capacitados no mercado. Ou pior, esses recém formados que“leram” algo sobre Patterns e acham que estão dominando o assunto, e acabam criando problemasainda maiores de manutenção.

Mas é isso aí, parabéns Tiozão pelo post, que estão cada vez mais alto nível!!

ResponderAnônimo disse:em 02/03/2013 às 21:38Parabéns pelo post. Ficou excelente. Nota 1000. vlw

ResponderRobson Castilho disse:em 02/03/2013 às 21:48Obrigado.[]s e volte sempre! 

ResponderRicardo Ferreira disse:em 18/05/2013 às 08:56Muito bom Robson, parabéns, excelente post.

ResponderRobson Castilho disse:em 18/05/2013 às 11:41Obrigado, Ricardo.[]s

ResponderCarlos Lima disse:em 23/09/2013 às 14:07Eu queria saber qual designer utilizar para essa situação. Tenho que importar arquivos, um éposicional e o outro é delimitador, é uma mesma ação só de comportamentos diferentes.

Responder

ResponderRobson Castilho disse:em 23/09/2013 às 17:27Olá, CarlosExistem várias soluções para um mesmo problema. E assim, sem saber seu contexto, fica difícilser muito preciso.Ao que parece, você só varia a parte da extração da linha do arquivo. Sendo assim, essa extraçãopoderia ser abstraída e implementar um método de extração por posição e outro por delimitador.Caso de um strategy mesmo.É o que eu consegui pensar assim de “bate‑pronto”  .Lembrando que você não deve deixar complexo demais seu código se já está simples o bastantecomo está.[]s

ResponderJonatan Machado (@jonatanmachado) disse:em 15/12/2013 às 08:36Seus posts são excelentes.Comecei lendo os princípios SOLID e estou aproveitando todo o restante também.Parabéns Robson!

ResponderRobson Castilho disse:em 15/12/2013 às 16:51Opa, Jonatan.Muito obrigado pelo feedback. Espero continuar ou até aumentar o nível dos posts.[]s

ResponderDiego Garcia disse:em 15/04/2014 às 20:29Opa amigo, excelente post.Sobre a sua pergunta no inicio do post, acredito que gang of four seja uma jogada por ser 4 autoresmesmo.

Abraço e parabéns!

ResponderRobson Castilho disse:em 15/04/2014 às 22:12Olá, Diego.Era o nome de um banda e também o nome de um grupo político da China. Enfim…Obrigado pela visita![]s

ResponderCharles disse:em 22/05/2014 às 11:01Parabéns Robson!!

Encontrei o que a muito tempo tinha dúvidas.

Valeu!!

Responder

Robson Castilho disse:

Robson Castilho disse:em 22/05/2014 às 12:09Que bom, cara.Obrigado e volte sempre []s

ResponderJhonathan Maia disse:em 24/07/2014 às 13:42Carlos, bom tutorial.

Porem ainda sim este exemplo não me abriu a mente para este pattern. Teria a possibilidade de vocêcriar um exemplo utilizando o seguinte cenario: Pessoa, Pessoa Fisica, Pessoa Juridica.

Abraço.

ResponderJhonathan Maia disse:em 24/07/2014 às 13:43Ops: É Robson rsrsrsrsrsrsrs

ResponderRobson Castilho disse:em 24/07/2014 às 21:57Tranquilo, Jhonathan.

O padrão Strategy utiliza‑se do conceito de composição. A classe contexto (no meu exemplo,o Pedido) USA a strategy para variar o comportamento (ao invés de usar herança: Pedido,PedidoComFretePadrao e PedidoComFreteExpresso). Assim tenho um código menosacoplado e mais flexível.

Pelo exemplo que deu (não foi um cenário! :)), você quer fazer uma herança certo? Qual afinalidade? Herdar dados? Sem um contexto não tem com aprofundar…O Strategy nospermite variar COMPORTAMENTO (uma operaçao que seu objeto delega para outro) deforma extensivel, sem termos que ficar alterando a classe contexto quando surgir uma novaestratégia.

Qquer coisa, responde aí que a gente tenta aprofundar mais.[]s

Blog no WordPress.com.  /  O tema Truly Minimal.