Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo .net magazine 72 - Design Patterns – Strategy e Flyweight
Neste artigo veremos o que são design patterns e a implementação de dois dos 23 padrões definidos no livro Design Patterns Elements of Reusable Object-Oriented Software. São eles o padrão Strategy e o padrão Flyweight. Ao final, veremos como eles podem se relacionar desenvolvendo exemplos práticos dos mesmos.
.net Magazine 72
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 72
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 72
Design Patterns – Strategy e Flyweight
Conceitos e aplicações
Podemos definir design patterns como soluções bem experimentadas para problemas conhecidos. Apesar de o termo ser bastante conhecido na Engenharia de Software, ele teve origem na Engenharia Civil, através dos trabalhos do arquiteto austríaco Chistopher Alexander que, nas décadas de 60 e 70, produziu um método estruturado para descrição de boas práticas de projeto dentro de uma área de conhecimento.
No mundo da TI, um dos livros mais importantes sobre padrões é Design Patterns Elements of Reusable Object-Oriented Software, escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, também conhecidos como GoF, ou Gang of Four. Neste livro estão descritos 23 padrões de modelagem baseados no conhecimento prático dos autores. Estes padrões estão divididos em padrões de criação (creational patterns), que tratam do processo de instanciação de classes; padrões estruturais (structural patterns), que tratam da composição dos objetos; e padrões comportamentais (behavioral patterns), que se preocupam com a comunicação entre os objetos.
Neste artigo vamos comentar e exemplificar o uso de dois padrões descritos pela GoF. São os design patterns conhecidos como Strategy e Flyweight. O primeiro permite que diferentes algoritmos sejam alternados de acordo com a necessidade, enquanto que o segundo provê uma forma de minimizar o uso de memória dos aplicativos, através de cache de objetos. Depois, vamos demonstrar que os padrões não trabalham isolados, mas possuem relacionamentos. Os exemplos que serão vistos são simples, mas possuem todos os elementos necessários para a implementação do padrão. Eles foram desenvolvidos em C#, utilizando a ferramenta Visual Studio 2010.
Conceitualizando o padrão Strategy
O padrão Strategy consiste em se possuir vários algoritmos, ou estratégias, encapsulados em uma classe chamada Context. O programa cliente pode selecionar um desses diferentes algoritmos, de acordo com a situação. Em alguns casos, a classe Context pode até decidir qual é a melhor no momento. O interessante é que essa escolha é feita em tempo de execução.
Com esse padrão, podemos mais facilmente adicionar novos algoritmos, alterar os já existentes ou estender suas funcionalidades.
A Figura 1 ilustra o diagrama UML que define este padrão. Temos os seguintes elementos:
• Context – é a classe que mantém a informação contextual para que um algoritmo possa funcionar. Serve de mediador entre o cliente e os algoritmos;
• Strategy – é a interface, o contrato que define todas as operações comuns que o algoritmo deve suportar. Perceba que a classe Context possui um atributo deste tipo e que servirá para centralizar todas as chamadas;
• ConcreteStrategy – são os próprios algoritmos. Podemos ter quantas classes desse tipo forem necessárias, cada uma representando um algoritmo diferente.
Figura 1. Diagrama UML para o padrão Strategy
Nota do DevMan
UML é uma linguagem visual para a modelagem de sistemas orientados a objetos. Ela tem origem na compilação do que existia de melhor nas técnicas de notações Booch, OMT e OOSE, cujos autores são Grady Booch, James Rumbaugh e Ivar Jacobson, respectivamente.
Um dos seus principais diagramas é o diagrama de classes, que é utilizado para representar a estrutura e relações das classes. Por essa característica, é o diagrama utilizado para demonstrar e documentar os relacionamentos dos objetos que compõem cada design pattern.
Em resumo, este padrão pode ser aplicado quando você possuir uma aplicação onde existem diversas formas de se fazer uma coisa, onde a decisão de quando utilizar um algoritmo ou outro é feita de acordo com a necessidade.
Alternando algoritmos - Exemplo
Para poder demonstrar a utilidade do padrão Strategy, vamos supor uma aplicação que faça o cálculo de área e perímetro de figuras geométricas. Este tipo de rotina teria utilidade, por exemplo, em sistemas para cálculo de gastos de materiais em uma fábrica de embalagens.
Antes do exemplo, vamos relembrar alguns conceitos de geometria que são utilizados aqui. O cálculo do perímetro de um retângulo é a soma de todos os seus lados; já sua área é sua altura multiplicada pela largura. Para círculos, o perímetro é obtido multiplicando-se o raio pela constante ??(pi); sua área é a multiplicação dessa mesma constante pelo raio elevado ao quadrado. Aqui, estamos considerando o raio igual à metade da altura do objeto, para simplificar o exemplo.
A Listagem 1 contém o código da aplicação que faz o consumo de um componente responsável pelos cálculos. Este componente, chamado CalculadoraGeometrica, possui dois métodos: CalcularArea e CalcularPerimetro. Coincidentemente, os dois possuem a mesma assinatura. Recebem três parâmetros, que são:
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Conceitos e aplicações
Podemos definir design patterns como soluções bem experimentadas para problemas conhecidos. Apesar de o termo ser bastante conhecido na Engenharia de Software, ele teve origem na Engenharia Civil, através dos trabalhos do arquiteto austríaco Chistopher Alexander que, nas décadas de 60 e 70, produziu um método estruturado para descrição de boas práticas de projeto dentro de uma área de conhecimento.
No mundo da TI, um dos livros mais importantes sobre padrões é Design Patterns Elements of Reusable Object-Oriented Software, escrito por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, também conhecidos como GoF, ou Gang of Four. Neste livro estão descritos 23 padrões de modelagem baseados no conhecimento prático dos autores. Estes padrões estão divididos em padrões de criação (creational patterns), que tratam do processo de instanciação de classes; padrões estruturais (structural patterns), que tratam da composição dos objetos; e padrões comportamentais (behavioral patterns), que se preocupam com a comunicação entre os objetos.
Neste artigo vamos comentar e exemplificar o uso de dois padrões descritos pela GoF. São os design patterns conhecidos como Strategy e Flyweight. O primeiro permite que diferentes algoritmos sejam alternados de acordo com a necessidade, enquanto que o segundo provê uma forma de minimizar o uso de memória dos aplicativos, através de cache de objetos. Depois, vamos demonstrar que os padrões não trabalham isolados, mas possuem relacionamentos. Os exemplos que serão vistos são simples, mas possuem todos os elementos necessários para a implementação do padrão. Eles foram desenvolvidos em C#, utilizando a ferramenta Visual Studio 2010.
Conceitualizando o padrão Strategy
O padrão Strategy consiste em se possuir vários algoritmos, ou estratégias, encapsulados em uma classe chamada Context. O programa cliente pode selecionar um desses diferentes algoritmos, de acordo com a situação. Em alguns casos, a classe Context pode até decidir qual é a melhor no momento. O interessante é que essa escolha é feita em tempo de execução.
Com esse padrão, podemos mais facilmente adicionar novos algoritmos, alterar os já existentes ou estender suas funcionalidades.
A Figura 1 ilustra o diagrama UML que define este padrão. Temos os seguintes elementos:
• Context – é a classe que mantém a informação contextual para que um algoritmo possa funcionar. Serve de mediador entre o cliente e os algoritmos;
• Strategy – é a interface, o contrato que define todas as operações comuns que o algoritmo deve suportar. Perceba que a classe Context possui um atributo deste tipo e que servirá para centralizar todas as chamadas;
• ConcreteStrategy – são os próprios algoritmos. Podemos ter quantas classes desse tipo forem necessárias, cada uma representando um algoritmo diferente.
Figura 1. Diagrama UML para o padrão Strategy
Nota do DevMan
UML é uma linguagem visual para a modelagem de sistemas orientados a objetos. Ela tem origem na compilação do que existia de melhor nas técnicas de notações Booch, OMT e OOSE, cujos autores são Grady Booch, James Rumbaugh e Ivar Jacobson, respectivamente.
Um dos seus principais diagramas é o diagrama de classes, que é utilizado para representar a estrutura e relações das classes. Por essa característica, é o diagrama utilizado para demonstrar e documentar os relacionamentos dos objetos que compõem cada design pattern.
Em resumo, este padrão pode ser aplicado quando você possuir uma aplicação onde existem diversas formas de se fazer uma coisa, onde a decisão de quando utilizar um algoritmo ou outro é feita de acordo com a necessidade.
Alternando algoritmos - Exemplo
Para poder demonstrar a utilidade do padrão Strategy, vamos supor uma aplicação que faça o cálculo de área e perímetro de figuras geométricas. Este tipo de rotina teria utilidade, por exemplo, em sistemas para cálculo de gastos de materiais em uma fábrica de embalagens.
Antes do exemplo, vamos relembrar alguns conceitos de geometria que são utilizados aqui. O cálculo do perímetro de um retângulo é a soma de todos os seus lados; já sua área é sua altura multiplicada pela largura. Para círculos, o perímetro é obtido multiplicando-se o raio pela constante ??(pi); sua área é a multiplicação dessa mesma constante pelo raio elevado ao quadrado. Aqui, estamos considerando o raio igual à metade da altura do objeto, para simplificar o exemplo.
A Listagem 1 contém o código da aplicação que faz o consumo de um componente responsável pelos cálculos. Este componente, chamado CalculadoraGeometrica, possui dois métodos: CalcularArea e CalcularPerimetro. Coincidentemente, os dois possuem a mesma assinatura. Recebem três parâmetros, que são:
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
2 COMENTÁRIOS
Renato Vilasboas Dos Santos
Pessoal,
Ótima prática, já utilizei com muito sucesso, o trabalho sem dúvida é maior mas a organização e a flexibilidade de mudanças valem o preço,
ótimo artigo !
Renato V.S.
[há +1 ano] -
Responder
Você está em:
canal .net
Publicidade
Fabio Gouw
Space do autor
Microsoft Certified Professional Developer (MCPD), trabalha com desenvolvimento de sistema há 7 anos. Atualmente faz parte da equipe de arquitetura de uma instituição financeira em São Paulo.
Space do autor
0
0
