Como escolher um Padrão de Design?

História 

Para podermos entender o que são design patterns, precisamos de viajar um pouco no tempo até ao início da história desses métodos de construção de projetos. Afinal, quem criou os design patterns e onde surgiram.

 A nossa viagem leva-nos a 1977, onde a primeira ocorrência conhecida do tema foi mencionada  no livro Uma linguagem de padrões (A Pattern Language), escrito por Christopher Alexander, Murray Silverstein, e Sara Ishikawa.

Christopher Alexander foi um arquiteto, matemático e urbanista austríaco. Era professor emérito da Universidade da Califórnia, em Berkeley, e foi um dos principais críticos da arquitetura moderna apontando a desagregação social causada pela mesma.

Murray Silverstein foi coautor  dos livros A Pattern Language e The Oregon Experiment, e lecionou cursos de arquitetura na Universidade da Califórnia. Posteriormente, lecionou também na Universidade de Washington e foi autor de  vários artigos sobre linguagens de padrões.

Sara Ishikawa é arquiteta e académica especializada em relações pessoas-espaço. É professora emérita do College of Environmental Design, na Universidade da Califórnia, em  Berkeley, e é a coautora de A Pattern Language, The Oregon Experiment e Houses Generated By Patterns.

Desde então, surgiram algumas dúzias de padrões de projetos orientados a objeto. Esta abordagem, depressa se tornou popular em vários campos da programação, sendo que, muitos destes padrões, existem agora fora do projeto orientado a objeto. 

O que são

Primeiramente, os padrões de projeto, também denominados Design patterns em  inglês, são soluções criadas pela comunidade que ajudam a organizar os projetos, de forma a se poder  trabalhar em equipa, sem ter que se preocupar se o outro desenvolvedor vai entender o que está a ser feito no código.

Cada design pattern funciona como uma planta de um projeto de construção que se pode customizar de forma a agregar mais valor ao seu projeto. 

Existem diversos padrões de projeto usados por toda a comunidade. Neste texto, iremos abordar dois dos mais conhecidos: 

Abstract Factory

A intenção deste padrão de projeto é fornecer uma interface para criação de famílias de objetos, relacionados ou dependentes, sem especificar suas classes concretas, também  conhecido como Kit.

Este padrão deve ser aplicado quando se deseja isolar a aplicação da implementação da classe concreta, que poderia ser um componente ou framework específico no qual a aplicação conheceria apenas uma interface. Neste caso  a implementação concreta seria conhecida apenas em tempo de execução ou compilação.

Factory Method

 O Factory Method, também conhecido como construtor virtual, possibilita adiar a criação do objeto a subclasses .

Define  uma interface para criar objetos, mas deixa que as subclasses decidam que classe instanciar.Este  padrão é comumente utilizado pelos projetistas de software quando existe a necessidade de encapsular a criação de uma classe isolando-se do conhecimento da classe concreta da aplicação cliente através de uma interface. Essa necessidade é comumente desejada por aqueles que trabalham no desenvolvimento de frameworks, que utilizam classes abstratas para definir e manter relacionamentos entre os objetos. 

Como classificar

Todos os design patterns são classificados de acordo com sua complexidade, dificuldade, e nível de aplicabilidade, mas, no fundo, podemos classificá-los em 2 principais grupos:

Idiomáticos, são os padrões de projeto de mais baixo nível e aplicados a uma linguagem de programação;

arquitetónicos, padrões de alto nível, que podem ser implementados a qualquer linguagem de programação e que também podem ser usados para fazer o projeto da arquitetura de toda a aplicação.

Como categorizar

Além disso, todos os padrões podem ser categorizados pelo seu propósito, ou intenção

• Os padrões criacionais fornecem mecanismos de criação de objetos que aumentam a flexibilidade e a reutilização de código;

• Os padrões estruturais explicam como montar objetos e classes em estruturas maiores, enquanto mantém as estruturas flexíveis e eficientes;

• Os padrões comportamentais cuidam da comunicação eficiente e da assinalação de responsabilidades entre objetos.

Benefícios 

Além de tudo o que já descrevemos até aqui no artigo, existem ainda alguns benefícios ao utilizar padrões de projetos nas suas aplicações. Alguns desses benefícios são:

• Fornecem soluções que já foram testadas e aprovadas;

• Tornam o sistema mais fácil de entender e manter;

• Facilitam a entrada de novos deves no projeto;

• Diminuem a curva de entendimento do projeto; 

• Facilitam o desenvolvimento de novos módulos;

• Melhoram a comunicação entre os desenvolvedores do projeto.

Conclusão

Existe uma analogia que pode ser feita entre os padrões de projeto e um jogo de xadrez, onde primeiro se aprende as regras do jogo, para então depois começar a jogar. Este é um processo que leva um pouco de tempo até se aprender a fazer boas jogadas. 

Mas mais importante do que saber boas jogadas, é saber como o jogo funciona, aquilo que leva o jogador a realizar cada jogada. No fundo, , mais importante do que saber implementar algum padrão de projeto, primeiro é necessário saber como ele funciona 

A principal causa de falhas na aplicação dos padrões é o desconhecimento do seu real propósito.