Um pouco de Design Patterns – Parte I /XXIV

Caro leitor, esse post faz parte da sessão ‘Back to Back’, onde visamos rever tópicos que desenvolvedores e engenheiros de software já estudaram em algum momento da carreira. Nesse post eu faço um ‘apanhado’ dos 23 Design Patterns (Padrões de Projeto).

Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (Gang of Four) lançaram em 1995 um livro adaptando as idéias de Cristopher Alexander (arquiteto que em meados dos anos 70 lançou um livro chamado ‘A Patterns Language’ , voltado para construção civil) para o mundo de desenvolvimento de software, onde propuseram soluções para problemas recorrentes.

Os autores definiram que “Padrões de projeto descrevem objetos e classes que se relacionam para resolver um problema de projeto genérico em um contexto particular”, além de três pontos relevantes para o real entendimento:

I – O problema que o padrão pretende resolver;
II – A situação (contexto) em que esse problema ocorre;
III– A solução proposta com adoção do padrão;

Mas por qual motivo devo usar Padrão de Projeto ?

Abaixo as principais vantagens ao adotar Padrões de Projeto conforme Deitel & Deitel:
– Encurtamento da fase de projeto.
– Capacidade de reutilização do projeto;
– Construção de um software confiável com arquiteturas comprovadas;
– Ajudam na identificação de erros;
– Criam vocabulário comum para os envolvidos no desenvolvimento do software;

O fato é que conseguimos criar softwares sem utilizar padrões de projetos, sendo apenas uma das etapas do processo de desenvolvimento. Equivocadamente, programadores tentam adequar padrões em suas necessidades do dia a dia, quando na verdade se esquecem que o uso dos mesmos é para sanar problemas específicos em determinados contextos.

Em tentativas de evitar o acima exposto, empresas definem seus próprios padrões (isso é, elencam como ‘elegíveis’ alguns que resolvam as situações mais corriqueiras), além de desenvolverem seus próprios frameworks.

E qual a diferença entre Frameworks e Padrões de Projeto (ou Design) ?

De acordo com GoF, existem três diferenças principais:

I – Os padrões são mais abstratos, já os frameworks podem ser executados e reutilizados diretamente. Em contraste, os padrões de projeto devem ser implementados toda vez que são usados. Outro ponto é que padrões deixam claro as compensações e as consequências de seu uso.
II– Os padrões sempre são menores, já que um framework pode conter vários padrões aplicados, mas nunca o contrário.
III-Os padrões de design são menos especializados e não ditam a arquitetura de um aplicativo (diferentemente de frameworks).

Pode-se categorizar os Padrões de Projeto como:

• Criacional: Abstract Factory, Builder, Factory Method, Prototype e Singleton.
• Estrutural: Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy.
• Comportamental: Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

Cada padrão descreve um problema que sempre ocorre e uma solução, de forma que possamos usá-lo quantas vezes por preciso.

Em outros posts irei abordar padrão por padrão, utilizando C#. Até a próxima !

Referências:
-http://www.cs.unc.edu/~stotts/GOF/hires/chap1fso.htm;
-Gamma, Helm, Johnson e Vlisside. Design Patterns: Elements of Reusable Software. Addison Wesley: 1995;