Por que eu devo ler este artigo:A utilização de padrões de projetos oferece diversas soluções padronizadas e eficientes para problemáticas de design e programação de softwares que são reutilizáveis no nosso código.

A partir destas soluções podemos deixar construir aplicações robustas de alta qualidade, além de deixá-los mais elegantes. Mas para isso, precisamos ter um entendimento melhor com relação ao uso de cada um deles para que sua utilização seja correta, pois se usarmos uma solução “errada”, ao invés de melhorarmos nosso projeto podemos piorá-lo drasticamente.

Neste artigo veremos como trabalhar com os padrões de projetos afim de obter um melhor desempenho utilizando os padrões criacionais, abstract factory e factory method.

Por definição, no contexto do desenvolvimento de sistemas, um padrão é utilizado para estabelecer uma forma de “descrever” soluções para problemas recorrentes.

A utilização de padrões de projeto é uma forma de estabelecer técnicas genéricas, que podem ser utilizadas para solucionar determinados tipos de problemas durante o desenvolvimento do software, geralmente independente de plataformas, linguagem de programação ou ferramentas utilizadas.

São vários os padrões adotados atualmente, mas dentre tantos se destacam aqueles formulados e apresentados à comunidade por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, mais conhecidos como a gangue dos quatro (Gang of Four - GoF), que fundamentaram 23 padrões em seu livro Design Patterns - Elements of Reusable Object-Oriented Software.

Os padrões definidos pelo GoF são divididos em três grandes grupos, de acordo com o objetivo principal de cada padrão: padrões comportamentais, padrões criacionais e padrões estruturais. A seguir temos uma breve descrição de cada uma dessas categorias criadas pelo GoF.

  • Padrões criacionais: os padrões do tipo criacional têm como princípio abstrair o processo de criação de objetos, ou seja, a criação de instâncias.

    Partindo deste ponto, a preocupação com questões que envolvam como o objeto foi criado ou composto é designada a uma parte específica do sistema, deixando os demais componentes alheios a esse processo.

  • Padrões comportamentais: os padrões comportamentais atuam sobre como serão atribuídas as responsabilidades para as entidades. Este tipo de padrão facilita a comunicação entre os objetos, distribuindo assim as funções e definindo como deve se dar a sua comunicação interna.
  • Padrões estruturais: esse tipo de padrão, como o título já diz, lida com a estrutura dos projetos, facilitando a comunicação entre as suas entidades componentes.

    Esses padrões são abstrações que exemplificam mecanismos inteligentes de organização das entidades de um determinado sistema, de maneira a descrever como os objetos e suas classes poderiam ser combinados para formar estruturas maiores.

O que os padrões de projetos podem evitar?

Como já foi dito, os design patterns surgiram como soluções genéricas para problemas recorrentes, sendo assim, é interessante que se saiba que tipos de problemas são esses e quais padrões podem ser aplicados em cada situação.

Dentre os vários problemas que podemos encontrar ao desenvolver um software, são apresentados a seguir alguns tipos mais comuns e alguns dos padrões de projetos que poderiam ser utilizados para a resolução desses problemas.

  • Problema 1: classes que tenham especificações explícitas no momento da criação dos objetos, o que implica em ter o sistema “preso” a uma implementação específica, sem possibilitar novas modificações de forma simples.

    Diz-se que, neste caso, os componentes (classes) estão fortemente acoplados, o que geralmente não é interessante, pois reduz a flexibilidade do projeto.

    Possível solução: criar objetos indiretamente com a utilização dos padrões Abstract Factory, Factory Method ou Prototype.

  • Problema 2: componentes do sistema possuindo fortes dependências em operações específicas, o que pode indicar que o sistema só possui uma forma de realizar uma requisição satisfatoriamente.

    Possível solução: utilizar padrões de projeto como o Chain of Responsibility ou Command, afim de evitar ações hard-code.

  • Problema 3: dependência em representações ou implementações de objetos, onde o cliente conhece diretamente como o objeto é implementado, representado ou armazenado, e torna-se necessário alterar o objeto utilizado.

    Possível solução: isolamento do cliente com o uso de padrões do tipo Abstract Factory, Bridge, Memento ou Proxy.

Note que é possível utilizar mais de um tipo de padrão (isoladamente ou em conjunto) para a resolução de cada um dos problemas apresentados, ...

Quer ler esse conteúdo completo? Tenha acesso completo