Postado em 1 de abril de 2011
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:
- Programação Orientada a Objetos: uma introdução
- Programação Orientada ao Objeto: uma abordagem didática
- Tutorial de Programação Orientada a Objetos no PHP
- PHP Orientado a Objetos: Para quem está começando
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