class=SubTtulo style="MARGIN: 0cm 0cm 0pt">Como aplicar conceitos de POO em aplicações PHP? – Parte 3

 

Olá, ainda nesta linha de OOP no Delphi for PHP neste terceiro e último artigo trataremos de um assunto pouco conhecido pela maioria dos programadores, mas que é fundamental para um bom desenvolvimento: os padrões de projeto. Como podemos observar, a orientação a objetos facilita e muito a nossa vida em relação aos códigos que escrevemos e a manutenção desses códigos, porém conforme vamos avançando em nossos projetos vamos nos deparando com situações delicadas que nos tomam um tempo precioso. Problemas recorrentes que se repetem em cada novo projeto que iniciamos. Se reparar bem todos os programadores têm aquela famosa Unit “Faz Tudo” onde temos rotinas prontas que nos ajudam a resolver estes problemas corriqueiros.

Mas em projetos grandes onde temos um a equipe envolvida esta Unit não ajudará muito. É preciso que haja uma linguagem universal que todos entendam, ou melhor, é preciso que se desenvolva dentro de um padrão, mas o grande problema e que cada equipe pode ter o seu padrão, cada empresa sua linha de raciocínio e aquela velha máxima “Cada um na sua, mas com alguma coisa em comum”.

Enfim, um ponto final foi colocado neste dilema em 1995 com o surgimento dos Design Patterns ou Padrões de Projeto para Sistemas Orientados a Objetos.

 

Histórico

O conceito de padrão de projeto foi usado pela primeira vez na década de 70 pelo arquiteto e urbanista Austríaco Cristopher Alexander. Ele observou na época que as construções, embora fossem diferentes em vários aspectos, todas passavam pelos mesmos problemas na hora de se construir. Eram problemas que se repetiam em todas elas e na maioria das vezes numa mesma fase da construção.

Foi aí que Cristopher resolveu documentar esses problemas e mais do que isso, passou também a documentar as soluções que eram aplicadas para resolução destes problemas. Entenda que até agora não há nada de programação ou informática e sim projetos, plantas, métricas, definições. Neste momento surgiam os padrões de projetos para a engenharia civil. Padrões esses que descreviam os problemas recorrentes em um projeto de engenharia e a solução reutilizável para este problema. Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, Cristopher estabelece que um padrão deve Ter as seguintes características:

·         Encapsulamento;

·         Generalidade;

·         Equilíbrio;

·         Abstração;

·         Abertura;

·         Combinatoriedade;

 

Ou seja, um padrão deve ser independente, deve permitir a construção de outras realizações, deve representar abstrações do conhecimento cotidiano, deve permitir a sua extensão para níveis mais baixos de detalhe e deve ser relacionado hierarquicamente.

Além destas características, Alexander definiu que um padrão deve ser descrito em 5 partes:

·         Nome;

·         Exemplo;

·         Contexto;

·         Problema;

·         Solução;

 

Padrões de Projetos  - Design Patterns

Anos mais tarde Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides iniciaram suas pesquisas baseadas nos trabalhos de Alexander. Também conhecidos como GOF (“Gang of Four”) eles começaram a descrever e documentar os problemas e soluções para desenvolvimento de softwares orientados a objetos e em 1995 lançaram o livro que ser tornou um fenômeno na área de análise e desenvolvimento de software: Design Patterns: Elements of Reusable Object-Oriented Software.

Neste momento iniciava-se uma nova fase no desenvolvimento de sistemas, pois agora havia um padrão a ser seguido, e cada padrão apresentando uma solução que poderia se reutilizada várias vezes para solucionar aqueles problemas recorrentes no desenvolvimento de software. Os padrões GOF, como são conhecidos, se dividem em três grandes categorias: ...

Quer ler esse conteúdo completo? Tenha acesso completo