Abordaremos os padrões Flyweight e Decorator, que possuem uma forma prática e objetiva de simplificar o nosso código. Apresentaremos então as suas estruturas e criaremos exemplos simples de como podemos utilizá-los de forma eficiente em nossos projetos, onde teremos um melhor aproveitamento.
Um padrão de projeto é uma solução para um problema de projeto de software comum. Certos problemas de design de software continuamente aparecem durante o desenvolvimento de aplicações diferentes, e os padrões de projeto nos proporcionam uma solução geral para esses problemas, de modo que não tenhamos que inventar uma solução completa a partir do zero.
Com base nisso, começaremos a ver neste artigo os padrões de projetos conhecidos como padrões estruturais. Estes padrões são de certa forma padrões com preocupações em relação à composição de suas classes e objetos para a formação de estruturas maiores. Este tipo de padrão faz uso da herança para a composição de suas interfaces ou implementações. Um exemplo simples que poderíamos citar seria a combinação de duas ou mais classes em uma, tendo como resultado dessa operação uma classe filha que combinaria as propriedades da classe pai. Este é um tipo de padrão muito útil quando se trata da utilização de bibliotecas de classes desenvolvidas independentemente da utilização em conjunto.
Podemos dizer então que os padrões estruturais descrevem determinadas formas de compor objetos para a realização de novas funcionalidades, ao invés da utilização da composição de interfaces. Esta capacidade de flexibilizar a composição de objetos que vemos aqui, vem da condição de podermos realizar alterações em tempo de execução, o que se torna impossível com a utilização de classes estáticas. Podemos pensar também em padrões estruturais como sendo semelhantes aos conceitos simples de estruturas de dados. No entanto, esses padrões especificam os métodos que conectam os objetos, não apenas as suas referências. Esta categoria discute, no entanto, o padrão de composição entre os módulos ou os componentes que permitem que uma pessoa desenvolva ou construa sistemas maiores. Os padrões estruturais definem como cada componente ou entidade deve ser estruturado, de forma a ter módulos muito flexíveis e comunicantes que podem trabalhar juntos em um sistema maior.
Os padrões estruturais incluem algumas técnicas bastante sofisticadas e poderosas. No entanto, eles são baseados principalmente em técnicas básicas, que são a Delegação e a Composição de objetos. Descrevemos estas técnicas a seguir:
- Delegação: é quando um dado objeto proporciona uma interface para um conjunto de operações. No entanto, o tempo de serviço para tais operações é executado por um ou mais objetos diferentes.
- Composição de objetos: os objetos são armazenados como ponteiros ou referências dentro do objeto que fornece a interface para os clientes. A composição de objetos é uma ferramenta poderosa, mas muitas vezes esquecida diante da gama de ferramentas do programador OO. Padrões estruturais nos mostram como tirar mais proveito dessa ferramenta.
Alguns dos efeitos positivos que podemos obter com a utilização de padrões estruturais são:
- Maior eficiência e maior reutilização de código;
- Melhor separação de implementações a partir de interfaces;
- Redução de complexidades, fornecendo assim interfaces mais limpas e simples para um sistema mais fácil para o entendimento dos programadores.
Agora que vimos uma introdução com relação aos padrões de projetos estruturais, veremos então que o conjunto de padrões estruturais é composto por seis tipos, sendo estes o Adapter, o Decorator, o Proxy, o Flyweight, o Bridge, o Facade, e o Composite. Alguns podem ser bem conhecidos no momento, como é o caso do Facade e do Adapter e, por conta disso, neste artigo veremos outros tipos de modelos para termos uma boa noção de sua utilização e termos a ciência de quando utilizá-los. Vejamos então um pouco sobre os padrões Flyweight e Decorator e o que eles têm a nos oferecer de melhor!
Flyweight
O padrão Flyweight é um tipo de padrão de design que é utilizado basicamente para minimizar o uso de recursos quando se trabalha com um grande volume de objetos. Ao criarmos muitos objetos idênticos, o Flyweight pode diminuir a quantidade de memória que está sendo usada para um nível, de certa forma, administrável.
A principal intenção deste padrão é estruturar objetos de modo que eles possam ser compartilhados entre diversos contextos. Ele é, muitas vezes, confundido como sendo uma “fábrica”, que é responsável pela criação do objeto. A estrutura do padrão envolve uma fábrica Flyweight para criar a correta implementação da interface do Flyweight, mas com certeza não são os mesmos padrões utilizados.
A programação orientada a objeto é considerada por muitos desenvolvedores uma bênção, no entanto, ela tem alguns desafios. Considere então um grande objeto de domínio, no qual tenhamos que modelar cada componente como sendo um objeto. Às vezes, programas trabalham com um grande número de objetos que têm a mesma estrutura e alguns estados desses objetos não variam no tempo. Quando usamos uma abordagem tradicional e criamos instâncias desses objetos e preenchemos variáveis de estado com valores, os requisitos de memória e armazenamento podem inaceitavelmente aumentar. Para resolvermos este tipo de situação, podemos então usar o padrão Flyweight.
O padrão Flyweight pode vir para nos auxiliar, pois ele ajuda a reduzir o custo de armazenamento de um grande número de objetos. Ele também nos permite partilhar objetos em vários contextos simultaneamente. O padrão permite alcançar esses objetivos por retenção orientada a objetos de granularidade e flexibilidade ao mesmo tempo.
A solução ideal para situações em que a criação de objetos compartilhados seja necessária pode ser oferecida pelo Flyweight, onde a chave para criarmos os objetos compartilhados é a distinção entre o estado intrínseco e extrínseco de um objeto. Os objetos compartilhados no padrão são chamados Flyweights. Tratando um pouco sobre o estado extrínseco, ele é fornecido como um contrapeso a partir do exterior como um parâmetro, quando alguma operação é chamada nele. Esse estado não é armazenado dentro do Flyweight.
Pod ...
