Estudos

Design Patterns no PHP – Parte II: Criando classes.



Dando continuidade ao estudo sobre Design Patterns no PHP, vamos hoje começar a falar sobre o Modelo de Classes Ensures e a sua aplicação usando o PHP. No ultimo post ( Design Patterns no PHP – Introdução Geral ), eu havia falado sobre teorias como : Encapsulamento, Generalidade, Equilíbrio, Abstração, Abertura e Combinatoriedade. Agora, levando em consideração que você entendeu o principio teórico da coisa, vamos lá. Caso não, envie perguntas através dos comentários e/ou tente ler novamente o primeiro tópico do estudo.

A invenção da Roda.

O paradigma, ou seja, modelo ou padrão da Orientação a Objetos não é novo. Foi criado na década de 60/70, quando os softwares começaram a ficar extremamente complexos. Além do motivo óbvio de melhor reutilização do que já foi escrito, era necessário uma forma mais eficaz na organização dos sistemas. Até por que, cada vez mais os projetos estouravam seus prazos e valores previstos.

Talvez, ao descrever o passado, muitos programadores enxerguem seu presente ou o da empresa onde trabalha. Projetos que pareciam ser extremamente simples, mas, acabam se tornando uma verdadeira Caixa de Pandora. Historicamente, a primeira linguagem a introduzir conceitos do paradigma de Orientação a Objetos foi a “Simula”. Logo após veio o Smalltalk (criada pela Xérox) que se tornou a primeira linguagem popular Orientada a Objetos – e que alavancou o paradigma.

Mesmo tendo rodas, bicicleta ainda não é carro.

Talvez alguém afirme: Mas o meu código é organizado, afinal de contas eu o separo em varias funções. Será ? Em um sistema simplório, como de um pequeno gerenciador de notícias, você pode pensar que não tem tanto a perder. Mas ai surgem questões do tipo : E se a estrutura do banco tiver que mudar, o quanto você terá que alterar o seu código ? E se novas regras aparecerem ? E se a fonte de dados vier de diferentes meios (RSS, BD1, BD2, arquivos de texto, web services) ? E na hora de documentar o sistema, o que você faz ?

E lá vai o bendito programador abrir um arquivo com umas trinta functions diferentes, copiando e colando uma função qualquer para criar a mesma coisa mas agora com um ou dois parâmetros diferentes. Geralmente você terá que revisar TODO o projeto pois, não existe uma arquitetura flexível a mudanças.

Embora hoje a sigla OOP (Oriented Object Programming) ou POO (Programação Orientada a Objetos) cause certo frisson, ela não é algo tão complexo a ponto de somente nerds com coeficiente de rendimento 9.9 de Harvard possam entender. A POO nada mais é do que a evolução natural da programação procedural. Invista seus esforços para entender a lógica da POO – não fique tão preocupado em decorar ” qual é a sintaxe no php que faz alguma wholesale NBA jerseys coisa . É realmente simples.

Voltando a falar sobre Encapsulamento.

No ultimo post do estudo, eu defini encapsulamento da seguinte forma :

“Todo código que segue os moldes da OO, deve encapsular, ou seja, dividir em pequenas partes um problema/solução bem definido. Cada parte ou cápsula, deve ser independente e bem formulada, de maneira a ficar claro onde ela se aplica no seu projeto.”

Partindo deste principio, imagine que você tenha umas 20 funções que você costuma usar sempre. Funções como acesso ao banco de dados, validação de formulários, cadastro de alguma coisa em alguma tabela, etc. Você tentou organizar seus códigos dividindo-os em pequenas partes. Mas imagine que você pode agora melhorar a interação dessas partes. Fazer com que elas façam o trabalho sujo de maneira mais “automatizada”. Imagine que você pode agora alterar o comportamento das suas funções de acordo com algum evento, melhorar o tratamento de erros, reaproveitar melhor seu código enfim, imagine que você poderá ter mais tempo livre para se preocupar com outras coisas. Essas são as conseqüências naturais da POO.

Com um código seguindo as boas regras da POO, você consegue maior independência e controle entre as suas “cápsulas”. Agora você começará a separar seus códigos não mais por functions, mas sim por classes, que terão um subconjunto de funções (métodos). Vamos ver alguma coisa mais prática no próximo tópico.

Dissecando o sapo.

Vamos à prática. Que tal analisarmos a estrutura de uma classe bem Miami Dolphins Jerseys simples ? Ela só tem uma misera função (que vamos começar a chamar de método) que imprime “Ola Mundo”. Como o objetivo da classe é estudarmos sua sintaxe, Geral logo, não ligue muito para essa função tão tola.

class OlaMundo{

/**
* Classe de estudo cuja unica função é escrever Ola Mundo
*
* @author Chuck Norris.
*/
function imprime(){

echo( “Ola Mundo” );

}

}

Primeiro começamos dizendo que vamos escrever uma classe utilizando o comando class, pós-cedido de um espaço e o nome da classe que iremos criar. Darei dicas para uma boa nomenclatura de uma classe no próximo tópico. Logo após, colocamos o primeiro bracelete “{“, escrevermos todos os métodos e atributos (veremos atributos depois) e finalizamos o método com o bracelete “}”.

Em seqüência criamos os comentários. Isso é uma verdadeira preciosidade em qualquer código fonte. Utilizei o mesmo padrão usado pelo javadoc, onde o comentário deve dizer resumidamente o seguinte: O que o método faz, seu autor, o tipo de retorno que ela pode gerar (String, Array, Boolean, Integer, Double, Object) e os parâmetros (se houver). Como essa é uma classe pra estudo e portanto é bem simples, somente descrevi o método e coloquei seu autor. Sempre comente tudo o que você criar, a ponto de qualquer outro programador conseguir entender seu código se guiando apenas pelos comentários. Isso ajuda a deixar seus códigos auto-documentados.

Depois, criamos nosso primeiro о método. Note que utilizei o comando function para dizer que o que vem após será um método. Assim como em uma função simples, devemos fornecer um nome ao método e, entre parênteses dizer se haverão parâmetros. Abrimos então o método com “{” e depois de tudo, fechamos com “}”.

Claro que o método criado para o exemplo é extremamente simples. Mais tarde, veremos o uso do $this ( que faz referencia ao próprio objeto), modificadores de acesso( public, private e protected), o uso de atributos heranças e polimorfismo. Vamos prosseguir.

Cada macaco no seu galho.

Há uma filosofia no mundo Unix que é : “Não desenvolva coisas grandes que tenham inúmeras funções. Desenvolva coisas pequenas, que em primeiro lugar realize perfeitamente o propósito para qual elas foram designadas e, em segundo lugar, possam se encaixar uma com as outras, para que juntas possam fazer as mesmas inúmeras coisas mas com extrema perfeição”.

Desenvolver seguindo a lógica Orientada a Objetos, não é você pegar todas as suas functions, escrever um “class NinhoDeUrubu { ” no inicio do Armagedon e colocar um ” } ” no final. Como já disse, o principio do encapsulamento é você criar blocos de código que irão se relacionar. Não adianta criar uma classe de conexão com o banco de dados e colocar métodos que irão manipular suas tabelas, envio de e-mail, contas a pagar, etc. Uma coisa é a classe de conexão, outra coisa são as suas tabelas, outra é enviar e-mails, e por ai vai.

Separe suas classes em arquivos diferentes e dê nome CERTO aos bois. Não chame a classe que irá manipular a tabela usuários de DbListaTodos . Pense com carinho na nomenclatura das suas classes. Tenho um amigo pseudo-chinês que sempre diz “O principio da sabedoria consiste em você chamar as coisas pelo nome”. Chame a classe conexão com o banco de dados de algo parecido com ConectaBD , ou DBConnect caso há um padrão de nomenclatura em inglês. Outra coisa: assuma um padrão de nomenclatura para todas as suas classes. Veja um exemplo de como NÃO nomear as suas classes:

class connect_BasedeDados2eenviaemail {}

Vamos aos erros: separação visual com letras iniciais maiúsculas e underscore ao mesmo tempo; palavras em inglês e em português ao mesmo tempo (só faltou espanhol e kanji); nome grande que não diz muita coisa ( esta é a segunda classe de conexão ou ela se conecta ao segundo banco de dados ?); uma classe que conecta ao banco de dados e envia e-mail ? Conclusão : NUNCA coloque seu nome como autor desse anticristo.

Classes hoje, objetos amanhã.

Assumindo que você não saiba, um objeto nada mais é que a sua classe em ação, ou seja, nada mais é que a sua classe instanciada. Diferente de uma function, uma classe precisa ser inicializada ( transformada em objeto ) para poder ser utilizada. Veja o exemplo abaixo de uma função que imprime “ola mundo”.

function ImprimeOlaMundo() {
echo(“Ola mundo”);
}

Para utilizar a função acima, basta somente você chamar a função da seguinte forma:

ImprimeOlaMundo();

E pronto. Seu texto aparecerá na tela. Agora, vamos construir isso utilizando uma classe ?

class OlaMundo{

/**
* Escreve Ola Mundo
*
* @author Chuck Norris.
*/
function imprime(){

echo( “Ola Mundo” );

}

}

Analisando a classe acima, podemos perceber que: ela se chama OlaMundo e tem um método chamado imprime() que cospe na tela o texto. Não adianta você escrever algo parecido com o seguinte:

OlaMundo(imprime());

Ao tentar fazer isso (leia-se besteira) você terá um erro catastrófico de sintaxe. Você precisa iniciar o seu objeto, utilizando a classe OlaMundo como base para esse objeto. Para isso você utilizará o construtor new, que cria um objeto no formato que você construiu sua classe. Veja o exemplo da utilização da classe acima.

$ObjetoOlaMundo = new OlaMundo();
$ObjetoOlaMundo->Imprime();

Ooooopa…. peraí, acaba definir de surgir um camarada novo em cena. Trata-se da seta ( -> ). Sinceramente, não faço a mínima idéia da onde Andi Gutmans tirou essa idéia de que a seta era mais prática ou tornava o código legível. Bom, mas ela existe e não pode ser ignorada. Essa seta serve para separar o objeto (a direta) da chamada de algum método ou atributo (à esquerda). A ordem é sempre a seguinte: $ (cifrão) nomeDoObjeto (objeto) -> (seta) chamadaDeAlgumaCoisa ( método ou atributo ). Em outras linguagens ( 99.9% das outras que tenha OO) a separação é feita não com seta, mas sim com ponto. Algo como $nomeDoObjeto.chamadaDeAlgumaCoisa.

Voltando ao exemplo do OlaMundo, veja que você criou um objeto chamado $ObjetoOlaMundo que é uma instância da classe OlaMundo(). Esse objeto agora pode utilizar todos os métodos ou atributos públicos da classe OlaMundo.

E quanto aos atributos, o que são ? Bom, eles são elementos que juntamente com os métodos, definem a estrutura de uma classe. Também chamados de variáveis de classe, eles são nada mais que uma espécie de “variáveis” onde são guardadas informações dentro da classe. Bom, é difícil ser simples demais sem pular vários conceitos, mas, A PRINCIPIO entenda atributos como um padrão para entrada de informação na classe. Vamos aprimorar a classe acima ? Além do Ola Mundo, vamos escrever o nome do usuário.

class OlaMundo{

var $nomeDoUsuario;

/**
* Escreve Ola Mundo
*
* @author Chuck Norris.
*/
function imprime(){

echo( “Ola Mundo e ola ” . $this->nomeDoUsuario );

}
}



Ooooopa (novamente) …. Que história é essa de $nomeDoUsuario lá em cima ???? E que $this é esse no echo ? Simples: se lembra que foi dito que atributos são chamados também de variáveis de classe ? Pois bem, quando você cria uma variável FORA de algum método, essa variável ser torna automaticamente um atributo. Logo, o valor que estiver dentro do atributo $nomeDoUsuario poderá ser acessado por qualquer método da classe. O que eu fiz no echo do método imprime() foi justamente acessar o atributo criado.

Ah, quanto ao wholesale NFL jerseys $this, o conceito dele é um pouco mais complexo. Para simplificar, entenda que você necessita utilizá-lo toda vez que quiser chamar um atributo ou método dentro da mesma classe. No exemplo acima, eu utilizei o $this para alcançar o atributo nomeDoUsuario. Quando queremos chamar outros métodos pertencentes à mesma classe, nós também utilizamos o $this. Para você utilizar a classe acima, atribuindo um nome qualquer no atributo, basta somente você fazer o seguinte:


$ObjetoOlaMundo = new OlaMundo();
$ObjetoOlaMundo->
nomeDoUsuario = “Jeremias”;
$ObjetoOlaMundo->Imprime();

Observações Finais.

Bom, por enquanto é isso. Acho que para um post eu passei bastante conteúdo. Eu tinha em mente passar modificadores de acesso( public, private e protected), o uso de heranças e polimorfismo no mesmo post, mas, acredito que vai ficar puxado para aqueles que estão vendo isso pela primeira vez. Vou criar um post futuro só com exemplos e depois continuamos. Minha meta é chegarmos o quanto antes em UML.


Links interessantes para você já ir lendo:

Centro de Computação da UNICAMP: http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html
Fernando Lozano, consultor independente: http://www.lozano.eti.br/palestras/oo-php.pdf

Se tiver alguma dúvida sobre o que já foi explicado, use os comentários.


Um abraço e sorte nos estudos.
Pedro Mendes


I'm Pedro Mendes, a passionate developer and technology enthusiast. This blog covers programming and technology in the broadest sense possible. It's the place I collect my thoughts, work and findings to share with the public.

View Comments
  • Lucas

    Muito bom