Introdução aos Padrões de Projeto com PHP

Atenção! Essa postagem foi escrita há mais de 2 anos. Na informática tudo evolui muito rápido e algumas informações podem estar desatualizadas. Embora o conteúdo possa continuar relevante, lembre-se de levar em conta a data de publicação enquanto estiver lendo. Caso tenha sugestões para atualizá-la, não deixe de comentar!

Salve, galera! Depois de quase 5 meses sem dar as caras por aqui, consegui tempo pra voltar!
Realmente o final de ano foi difícil, mas graças a Deus, terminei a faculdade e agora tenho mais tempo para me dedicar aos estudos que antes eram paralelos.

Mas sem muita conversa, vamos direto ao que interessa: padrões de projeto.

Hoje inicio uma série de alguns posts falando sobre os padrões de projeto mais úteis para programadores PHP e algumas aplicações práticas dos mesmos. Então vamos estudar juntos!

Antes de começar…

Para iniciar os seus estudos, antes de mais nada, você deve estar familiarizado com o PHP 5 (ou superior). Assumo que você já tenha fluência na linguagem. Também é necessário que você já tenha uma boa noção de Orientação a Objetos. Todos os padrões de projeto são feitos de forma orientada a objetos e os termos abordados são diretamente ligados a este paradigma. Caso você não conheça esta metodologia ou nunca tenha trabalhado com ela, sugiro alguns links para dar uma olhada:

O que são e para que servem os Padrões de Projeto?

O conceito de padrões de projeto foi originalmente concebido pelo arquiteto austríaco Christopher Alexander, em meados da década de 1970. O que levou Alexander a realizar este estudo foi o fato de que ele gostaria de descobrir se havia alguma regra que pudesse especificar quando uma construção é de boa ou de má qualidade.

A partir deste estudo, Alexander começou a levantar pontos que estavam presentes em construções boas e não estavam nas ruins e vice versa. Com estes dados em mãos ele começou a elaborar diversas propostas para a solução de problemas comuns dentro da engenharia e da arquitetura.

“Cada padrão descreve um problema que ocorre frequentemente em nosso ambiente e então descreve a essência da solução deste problema, de tal forma que você possa usar a mesma solução milhões de vezes, sem nunca utilizá-la da mesma forma.”

Christopher Alexander – A Pattern Language

Tendo isso em mente podemos afirmar que um padrão de projeto nada mais é do que uma forma prevista, estruturada e documentada de solucionar um dado problema que é bastante comum.

No início da década de 1990, a GoF (Gang of Four – Gangue dos Quatro), formada por Eric Gamma, Richard Helm, Ralph Johnson e John Vlissides percebeu que as técnicas publicas por Alexander iam muito além do objetivo de padronizar a criação arquitetônica. Era possível identificar padrões que iriam auxiliar na resolução dos problemas comumente encontrados durante o desenvolvimento de softwares. Lançaram então o Design Patterns: Elements of Reusable Object-Oriented Software, livro este que tornou-se a maior influência sobre a comunidade de desenvolvimento de softwares da época (e que perdura até hoje). Ao todo são citados 23 padrões, divididos em três categorias: criacionais, estruturais e comportamentais. Estas categorias serão explicadas mais adiante.

Por que estudar Padrões de Projeto?

Agora que você já sabe o que são os padrões de projeto, já deve estar procurando (se ainda não encontrou) motivos para estudá-los. Eis alguns bons motivos de porque você deve investir tempo de estudo nestes padrões:

  • Reutiliza ao invés de redescobrir: todos os padrões já foram previamente testados e implementados em projetos que deram certo.
  • Otimiza a comunicação entre os desenvolvedores: unifica a língua que é falada entre os envolvidos no projeto, pois todos tem ciência dos termos empregados.
  • Facilita a análise: Quando você iniciar a análise já terá base e estará bem direcionado ao que implementar no seu projeto;
  • Proporciona alterações menos dolorosas: uma vez que existe uma padronização, as alterações tornam-se mais simples devido às estruturações do projeto;
  • Desestimula o uso de herança: delegar é melhor do que estender – a GoF não condena de maneira alguma o uso de herança, mas recomenda que se dê preferência pela extensão por delegação caso queira escrever código reusável. A herança não é totalmente desencorajada, até porque um bom sistema usa tanto delegação quanto herança;
  • Aumenta a confiabilidade;
  • Reduz a complexidade do código;

Como dividem-se os padrões?

Para uma melhor organização dos padrões apresentados, eles foram divididos conforme a aplicação de cada um. As três categorias distintas dos padrões de projeto são:

  • Criacionais: Abstraem e escondem o processo de instanciação. O sistema torna-se independente da maneira como o objeto é composto, construido e representado.
  • Estruturais: Trabalham com a composição de classes e objetos, definindo a relação entre ambos.
  • Comportamentais: Definem como os objetos irão se comportar e padroniza a comunicação que haverá entre os objetos dentro da estrutura do projeto.

E agora?

E agora, meus caros amigos, teremos que esperar pelo próximo post, onde vou começar a falar mais sobre os tipos de padrões, explicar melhor as divisões e dar um resumo de cada um.

Espero que esse post tenha servido para dar uma iluminada no conceito de Design Patterns que muitas vezes é bastante obscuro!

Aceito sugestões para as próximas postagens!

Um abraço a todos e fiquem com Deus!
Rafael Jaques