Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo Clube Delphi 95 - Orientação a Objetos no Delphi for PHP
Artigo publicado pela Clube Delphi edição 95.
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Clique aqui para ler essa revista em PDF.
Delphi for PHP – Boas Práticas - Expert
Orientação a Objetos no Delphi for PHP
Como aplicar conceitos de POO
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;
·"
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Gestor de TI com especialização em gerência de projetos (PMI) e Governança de TI (ITIL e COBIT) pelo instituto Infnet. Embarcadero MVP e Instrutor certificado pela Borland. Graduando-se em Gestão de TI focada em negócios. Grande entusiasta do desenvolvimento orientado a objetos, padrões de projetos,...
