Hello World em Rails

Fala pessoal...

Esse final de semana tirei algumas horas para estudar Ruby on Rails. Como não tenho um vasto conhecimento na plataforma, não vou me deixar guiar pelas poucas coisas que vi. O que posso dizer é que até então tenho gostado.


Configurando no Windows

Mesmo estando on Windows, achei a configuração do ambiente de desenvolvimento extremamente simples. Basta baixar a ultima versão do Ruby no próprio site do RoR e realizar alguns passos simples. Depois de rápidos next > next >finish, o Ruby teoricamente estará instalado. Basta agora instalar o framework Rails, abrindo o console do windows e digitando:

gem install rails --include-dependencies

Sua primeira aplicação

Pronto! Ruby e Rails instalados. Para criar um "hello world", basta agora criar uma pasta em algum lugar ( de preferência via Console ) e logo após, dar um rails "nome a aplicação". Mais ou menos assim:

md C:\rubydevs
cd C:\rubydevs
rails hello

Como é notório, criei um diretório na raiz e, na ultima linha chamei o daemon do rails dando o nome da minha futura aplicação. Ele automaticamente cria toda a estrutura de desenvolvimento que preciso, colocando todos os arquivos usados pelo RoR lá.

Para criar um primeiro controle para sua aplicação, entre no diretório do projeto ( no meu caso hello ) e, via prompt, faça o seguinte:

ruby script/generate controller helloworld

Fazendo isso, usamos um script gerador que já faz algumas coisas úteis para nós ( como criar helper e test para o controle novo).

Agora é hora de criarmos alguma ação para o novo controler. Que tal sairmos um pouco do maldit... ehrr... bom, quero dizer, adorável Console do Windows ? A própria instalação do Ruby já nos deixa com o SciTE, um editor de textos bacana. Se preferir uma IDE, uma dica é começar utilizando o Aptana RadRails ( plugin para o Eclipse ). Se você seguir o mesmo caminho que eu, terá que baixar o Aptana Studio ( já com o Eclipse ) e depois fazer uma pequena atualização para o RadRails - que aparecerá automaticamente no startup do Aptana.

Depois vá na pasta app/controllers e abra o controle criado - no nosso caso o helloworld. O nome do file sempre fica nomedocontrole_controller.rb . A estrutura do arquivo será identico a seguinte:

class HelloworldController < ApplicationController
end

Temos o declarador class seguido pelo nome do controle, o "<" indicando herança, o nome da classe Pai e o end finalizando a classe. Vamos criar o método dummie. Agora seu arquivo deve ficar da seguinte maneira:

class HelloworldController < ApplicationController
def dummie
end
end


Já é o suficiente. Vamos agora para a visão. Dentre a estrutura de diretórios, existe um chamado views. Se você abrir este diretório, notará que existe um subdiretório com o nome do seu novo controle - isso não é magia, é pura tecnologia. Agora, crie um aquivo com a extensão rhtml que será a visão do seu controle. Como o nome da ação que criamos é dummie, logo, o nome da visão será dummie.rhtml . Esse arquivo será automaticamente chamado pelo RoR, quando o método dummie do controle for chamado. Como ele será a parte html da sua aplicação web, escreva alguma coisa para estar no browser.

Agora é só rodar. Para isso, retorne ao console e, dentro do diretório da sua aplicação, digite:

ruby script/server

O script server levanta automaticamente o servidor na porta 3000. Para testar, vá no seu browser favorito ( provavelmente Firefox, Opera ou Safari ) e teste a url:

http://localhost:3000/helloworld/dummie

Eis aí a criança. Sei que o tópico foi extremamente simples, mas tentei abordar desde a instalação a primeira aplicação. Tenho feito alguns teste e tenho gostado do que tenho visto. Com o passar do tempo vou dividindo com vocês.

Ahh.... pega o saco preto pro MySQL

O MySQL sempre foi um banco de dados razoavelmente flexivel pra mim. Até uns 5 minutos atrás, isso era uma verdade plena. Estava eu desenvolvendo uma procedure dinâmica, que de acordo com os parâmetros fornecidos, ela monta um update.

Até que a procedure era simples, menos de 100 linhas, nada de cursor, chamada de outras procedures ou recursividade. Acontece que ele criava a procedure sem problema algum, eu passava todos os parâmetros certos e ele não estourava excessão mas também não realizava o update.

And now, are you scared ?

Bom, depois de muito futucar, decidi ver uma coisa boba. Boba não, completamente ridícula. Havia um coalesce na procedure ( função que checa se o primeiro parâmetro é nulo, caso sim, retorna o segundo ). A sintaxe é parecida com o seguinte:

set a = colalesce(b,c);

Acontece que eu coloquei um inocente espaço entre a função e o parênteses. Isso virou um tormento na minha vida. Esse simples fato, fez com que eu recebesse a seguinte mensagem via prompt :

FUNCTION BD1.COALESCE does not exist

Mas não é uma gracinha ? Se isso fosse um padrão no MySQL, eu nem reclamava. Mas já cansei de dar esses moles e nunca tive problemas. Vai entender...

Console online de Ruby

Tenho me acostumado com a idéia de estudar Ruby on Rails. E como dita a regra, se Rails é somente um framework sobre Ruby, nada mais lógico do que procurar ter um bom conhecimento nesta linguagem para se dar bem.

Para auxiliar nesta tarefa, eis o tryruby, uma aplicação web que permite executar alguns comandos na linguagem.

http://tryruby.hobix.com/

Simulando um With no PHP com Interfaces Fluentes

Esses dias estava conversando com um grande colega programador sobre a carência do comando With no PHP. Estive procurando por algum tempo e como não tive uma solução que me agradasse joguei a idéia para o limbo.


Até que ontem, em mais uma das minhas noites de insônia, tive a idéia de simular o comando With com umas das melhores práticas de legibilidade de código: Fluents Interfaces, ou Interfaces Fluentes.


Primeiro Passo: Falando de Fluents Interfaces e PHP


Acredito que para muitos o termo "Interfaces Fluentes" não é novidade alguma. Mas, para quem não conhece, trata-se de uma maneira mais intuitiva de construir suas classes. Como a implementação de POO no PHP4 era deficiente (leia-se precária) não era possível a prática de Interfaces Fluentes graças à seguinte limitação: no PHP4 você não consegue criar uma referência direta ao objeto através do retorno dos seus próprios métodos.

Mas no PHP5 e sua OO totalmente reescrita, eis que tudo (ou quase) se fez novo. Agora, como a deficiência acima foi suprida, podemos facilmente fazer referencia direta ao objeto retornado por um dos seus próprios métodos.


Exemplo:

// Classe que retorna a própria referencia em todos os métodos
class escreveONomeCompletoUsandoInterfaceFluente {

public function escreveNome( $str ) {


// Escreve um nome qualquer
echo( $str );


// Retorna a referencia do próprio objeto
return $this;

}

public function escreveSobreNome( $str ) {


// Escreve um sobrenome qualquer
echo( $str );


// Retorna referencia ao próprio objeto
return $this;
}

}


Ao ler a classe de exemplo acima, você notará que eu sempre retorno o próprio objeto. Pois bem imaginemos uma possivel utilização NORMAL da classe acima:


$escreveNomeCompleto = new escreveONomeCompletoUsandoInterfaceFluente();
$escreveNomeCompleto->escreveNome( ‘ Pedro ‘ );
$escreveNomeCompleto->escreveSobreNome( ‘ Mendes ‘ );


Porém, como eu estou retornando o próprio objeto nos métodos da classe criada, a implementação Fluente do código seria a seguinte:


$escreveNomeCompleto = new escreveONomeCompletoUsandoInterfaceFluente();
$escreveNomeCompleto->escreveNome( ‘ Pedro ‘ )->escreveSobreNome( ‘ Mendes ‘ );


Desta forma, esta criada uma implementação simples das Fluents Interfaces no PHP. Como você pode perceber, a idéia central é você encadear a chamada dos seus métodos da seguinte forma: $objeto->metodo1()->metodo2()->metodo3()->…->metodofinal(); ao invés de ficar chamando o objeto a cada vez que você queira chamar um método.


Segundo Passo: Aplicando o conceito de Fluents Interfaces para alcançar o conceito de With


Em algumas linguagens você tem o comando With, que funcionada da seguinte forma:


With instanciaDoObjeto

metodoUm();
metodoDois();
metodoTres();

End With;


Com isso, você fornece a instância do objeto e simplesmente trabalha com seus atributos e/ou métodos dentro do bloco criado, diminuindo o código a ser escrito e deixando-o mais limpo. No PHP eu não achei nada que criasse o With diretamente, mas com o conceito de Interfaces Fluentes, o mesmo código acima poderia ficar da seguinte forma:


$instanciaDoObjeto
->metodoUm();
->metodoDois();
->metodoTres();


Pronto! Esta criado o conceito do With com uma estrutura mais aprimorada. Espero que tenham gostado e enviem suas duvidas/criticas/sujestões.



Um abraço,
Pedro Mendes

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 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 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 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, 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 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 $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

Design Patterns no PHP - Parte I : Introdução Geral

Ola pessoal, esse é o primeiro estudo relacionado a PHP que publicarei no blog - e espero que seja o antecessor de muitos outros. Por o PHP ser uma linguagem extremamente fácil, tanto pela sintaxe, quanto pela comunidade de programadores que mantem blogs e fóruns pela internet, cada programador PHP acaba tendo uma "escola" diferente. Obviamente, isso eh bom pois, cada um aprende de acordo com o seu próprio ritmo de estudos, mas, in other hand, vejo muita muita gente dizendo-se programador com deficiências em áreas basicas da programação. Falando de maneira simples, a galera ta mais preocupada em fazer um site do que construir uma solução.

Pensando nisso, resolvi começar falando a respeito de Padrões de Projetos ou Padrões de Desenho de Software, termos estes originários do inglês Designer Patterns. Ao longo desse estudo, vamos tentar abordar os principais pontos de desenvolvimento de software estruturado e no final pretendo realizar um passo-a-passo de um projeto junto vocês, ok?

Antes de comerçarmos o estudo em si, existe um ponto muito importante que necessita ser ressaltado: o PHP, ao contrário de outras linguagens como C ou Java por exemplo, não obriga o programador a desenvolver pensando nos moldes da Orientação a Objetos (OO). Não caindo no mérito desta caracteristica do PHP ser boa ou ruim, é importante o programador ver-se motivado a querer aprender esse padrão e utilizá-lo sempre em seus projetos. Como tem sempre aquele pessoal que aprendeu programar de uma forma, e fica meio reguardado para migrar para uma outra forma de pensar, gosto sempre de dizer que existem soluções e soluções. Como li em algum lugar certa vez "Qualquer chimpanzé consegue escrever um código que o computador entenda, o dificil é escrever um código que o homem também possa entender". Esse é o espirito da coisa.



Qual são os principios da Orientação a Objetos ?

Para podermos aprendermos os Design Patterns, devemos impreterivelmente entendermos como funciona um código Orientado a Objetos. Um código OO deve seguir os seguintes conceitos :

- Encapsulamento :
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 capsula, deve ser independente e bem formulada, de maneira a ficar claro onde ela se aplica no seu projeto.

- Generalidade:
Todo código orientado a objetos deve ser construido pensando sempre em ser reaproveitado em outros projetos.

- Equilíbrio:
Quando escolhemos seguir um padrão em um projeto, devemos sempre usarmos o esquilibrio em até onde vamos padronizar nossos códigos. Devemos sempre analizar qual tipo de problema teremos que resolver, vermos como funcionam as soluções tradicionais e como funcionam as soluções ruins ou fracassadas. Com isso, conseguimos facilmente entender como se comportará o nosso código.

- Abstração:
Para desenvolvermos um código elegante, devemos usar abstrações, ou seja, analizarmos os conceitos do conhecimento cotidiano na nossa vida real e aplicarmos ao nosso código. Parece loucura, mas realmente é assim que funciona.

- Abertura:
Ao adotarmos o padrão OO em nosso código, ele deve ser flexível para que cada capsula tenha liberdade de se aprofundar tanto quanto for necessário em um problema.

- Combinatoriedade:
A capsulas em seu código deve ser relacionadas hierarquicamente. Isso significa que você deve ter partes maiores em seu código, que se relacionam com diversas outras partes menores.

Lembrando que não é necessário você ficar decorando esses conceitos. Basta entendê-los e fazer alguns poucos exercícios tentando combinar os itens acima. Em pouco tempo, esses conceitos serão notados naturalmente em seus códigos.

O PHP pode não ser considerada a linguagem-modelo ao falarmos de OO (tal como Java), mas, através da versão 5 do nosso tão amado HyperText Preprocessor conseguimos utililzar praticamente todos os padrões mais comuns do Designer Patterns. Boiou ? Fique atento nos "próximos capítulos" deste estudo que você poderá entender melhor. No próximo estudo falarei sobre o Modelo de Classes, explanando sobre Classes, Instâncias, Objetos, Métodos, Propriedades, Herança entre outras coisas e, vou montar um exemplo básico em PHP.


Links interessantes para quem quiser saber mais por enquanto:
- Apostila em PDF do Professor Fenando Lozano falando sobre diversos conceitos de OO no PHP : http://www.lozano.eti.br/palestras/oo-php.pdf
- Criar Web - POO no PHP 5 - http://www.criarweb.com/artigos/330.php
- Grupo de PHP no Yahoo! Grupos - sempre com alguém disposto a tirar duvidas - http://br.groups.yahoo.com/group/php-pt/


Um grande abraço e sorte nos estudos!
Pedro Mendes

Abstraindo um pouco mais

A inércia é um fator completamente desnecessário em muitos casos. E isso torna-se um problema quando falamos de vida profissional. O problema que tive não chega ser bem na vida profissional, mas, quase. Sempre quando penso em C, esqueço completamente de alguns padrões muito úteis que aprendi com a OOP. Óbio que não conseguimos propagar as maravilhas da OOP em uma linguagem procedural, mas também não precisa virar zona.

Na faculdade tive um exercício de C que descrevia explicitamente a contrução de duas structs. A idéia do exercício era de um teatro que tinha várias peças e uma tabela de preço por faixa de horário. Como uma peça pode ser apresentada todos os dias de semana, há uma relação de dia da semana por quantidade de vagas.

A resolução da struct de peças de teatro que a santa besta que vos fala fez ficou assim:

typedef struct {

int cod;
char nome[30];
int codhorario[7];
int vagas[7];

} TPeca;

A ideia era usar os arrays codhorario e vagas ( ambos de tamanho 7) para fazer uma relação de codhorario por vagas. Mas que porco não ? Provavelmente se eu visse isso em algum sistema na 3Jane falaria um bocado. Se há uma relação de codhorario com vagas, faz uma struct a mais com um nome dia_vagas e resolve o problema. Não seria menos lusitano se ficasse assim:

typedef struct {

int codhorario;
int vagas;

} TDiaVagas;

typedef struct {

int cod;
char nome[30];
TDiaVagas dia[7];

} TPeca;


No final de contas, vivendo e reaprendendo. Ainda bem que não cheguei ao estágio de comer grama. Nada contra viu, Marcus Miris.

Migrando para o Blogger

Ola pessoal...

Resolvi migrar do Wordpress para o Blogger por alguns motivos que se derem certo, publico mais tarde. Vou pegar os posts do blog antigo e migrar para este novo espaço.

A luta continua!