2007-07-03 04:58:16
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 17)

Para ver os artigos anteriores desta série, clique aqui.

Olá pessoal. Obrigado por todos os comentários e emails! Estou tendo um prazer enorme escrevendo essa série, e fico ainda mais feliz quando vejo que realmente tem gente curtindo.

Mas vamos ao que realmente interessa. No nosso último encontro expliquei que existem diferentes formas, ou patterns, para lidar com buscas e coleções de objetos, mas que eu ainda não estava satisfeito com aquilo que conheço. Como já disse em outras oportunidades, aprendi o pouco que sei de PHP nos becos escuros da internet, entre latões de lixo e scripts procedurais escritos por sabe-se lá quem. Não tenho, portanto, nenhuma pretensão de conhecer todos os sutras da programação orientada a objetos. Mas, outro dia, eu tive uma idéia que achei interessante, nada original, mas um pouco diferente das duas implementações que mostrei pra vocês.

Um dos design patterns mais interessantes (e, para mim, mais difíceis de entender) que conheço chama-se Iterator. Devo ter lido as definições e exemplos umas 1000 vezes sem entender direito como usar essa coisa. Pra quem vem de um passado procedural, especialmente usando uma linguagem como o PHP que lida muito bem com arrays, é muito difícil entender o benefício de usar os tais iterators.

Os iterators, juntamente com um outro pattern chamado Collection, vão formar a base do nosso novo desenho. O que estou pensando é relativamente simples: assim como temos a classe base Model, para operações com modelos, quero criar uma classe ModelCollection, que vai cuidar das operações com coleções de modelos. Dessa forma, temos um paralelo interessante: assim como podemos carregar as informações do modelo fazendo $model->load e assim por diante, poderemos carregar as informações de coleções fazendo $modelcollection->load.

O que eu gosto nesse desenho é que tudo fica claramente definido: um $model é sempre um objeto, enquanto que os $modelcollections são sempre coleções de objetos. Uma função de um $model jamais vai retornar uma coleção de objetos; uma $modelcollection jamais vai retornar um objeto (caso uma busca retorne apenas um resultado, ainda assim será uma coleção com apenas um objeto).

Parêntesis: uma das coisas que me deixa maluco no PHP é o fato de você poder misturar absolutamente tudo - uma mesma função pode retornar uma string, um array, um objeto... É o que os estudiosos chamam de loosely typed language, uma linguagem que não exige a definição dos dados usados pelas variáveis. Claro que essa característica pode ser usada para o bem: muitas implementações interessantes usam essa característica para flexibilizar e agilizar o desenvolvimento. Mas com o tempo, depois de passar anos da minha vida tentando decifrar códigos de scripts PHP por aí, eu afirmo categoricamente: tentar entender um script ou classe de alguma outra pessoa escrita em uma linguagem loosely typed é muito mais difícil.

Mas por que esse parêntesis tão grande? Porque no desenho que estou propondo vamos sempre lidar com objetos; Porque as Collections nos oferecem possibilidades muito, mas muito interessantes mesmo pra trabalhar com objetos e coleções de classes diferentes de forma transparente.

Não entendeu? Bom, vamos aos nossos exemplos então. Imagine que temos dois modelos completamente diferentes. Tipo "Post" e "Carro". Logicamente, dentro do nosso desenho, vamos ter os modelos $post e $carro, além das collections $postcollection e $carrocollection. Onde queremos chegar? Bem, como tanto a classe PostCollection quanto a classe CarroCollection são "filhas" da classe ModelCollection temos a certeza que estas subclasses implementam as mesmas funções. E por que isso é lindo? Porque eu posso agora implementar, por exemplo, a classe HtmlHelper, cuja função buildTable aceita qualquer ModelCollection e imprime uma tabela html. Pra usar, basta fazer $htmlhelper>buildTable($postcollection) ou $htmlhelper->buildTable($carrocollection).

Sacaram a beleza? Esse é só um exemplo do que podemos fazer com as collections e os iterators, mas o importante é ver que esse design faz com que qualquer coleção se comporte de forma igual, pra que a gente possa implementar coisas genéricas que funcionam pra qualquer uma delas. A coisa que imediatamente vêm à mente é que essa classe ModelCollection vai ter um método genérico pra fazer paginação, um pra fazer ordenação dos dados, e assim por diante.

Quando nossas classes estiverem prontas, olha só o que vamos precisar fazer pra imprimir uma tabela html:

(controller)

/* A função ModelController::loadPage() carrega a página indicada no $_GET['page'] e no $_GET['pagesize']

já na ordem indicada por $_GET['orderby'] e $_GET['direction'] */

$this->postcollection->loadPage();

(view)

$htmlhelper->buildTable($postcollection); // imprime a tabela

$htmlhelper->createPreviousPageLink($postcollection); //cria o link para a próxima página

$htmlhelper->createNextPageLink($postcollection); //cria o link para a próxima página

E acabou. Não é legal isso?

Até a próxima!

2007-06-05 04:32:35
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 16)

Para ver os artigos anteriores desta série, clique aqui.

Olá amigos, estamos de volta. Semana de muitas emoções pra quem gosta de Tênis: Roland Garros é sempre uma festa. Este seu humilde autor confessa que, em sua tenra juventude, chegou a disputar alguns torneios; Lembro-me claramente de ganhar uma cesta com catchup, mostarda, mini-pepinos, azeitonas e mais alguns outros enlatados da empresa patrocinadora de um dos torneios de que participei. Minha melhor colocação, 3o colocado. Pensando bem, acho que fiz bem em não seguir a carreira.

Mas, deixando Jankovics, Vaidisovas, Sharapovas e Ivanovics de lado por alguns momentos, quero voltar nossa atenção novamente para os modelos do MVC. Muito bem amigos, hoje vamos tentar definir o que todos os nossos modelos devem minimamente fazer. Nosso objetivo hoje é listar os métodos da nossa classe Model, a classe base para todos os modelos que criarmos. Não tenho a pretensão de fazer um estudo teórico detalhado; dentro de nossa filosofia PHP de Rua® o que estamos buscando é somente o básico, o essencial.

Então, caros amigos, quais seriam estas funções essenciais, compartilhadas por todos os modelos que vamos criar? Lembrando nossas conversas anteriores, o modelo é um ajudante, uma classe que só existe para ler e gravar informações em nosso banco de dados, e sua estrutura de dados será sempre mapeada à estrutura de uma tabela que existe no BD.

Por exemplo, se criarmos um modelo Tenista, que possua as variáveis $id$nome$ranking, é certo que teremos uma tabela que guardará esta informação, que pra facilitar (nomes têm poder, lembrem-se disso) chamaremos de Tenistas. Essa tabela terá, minimamente, os campos id, nome e ranking. Sacou?

Estamos, de fato, mapeando uma classe à uma tabela, e instâncias da classe a registros da tabela. Essa técnica é chamada de ORM, Object-Relational Mapping. A coisa é mais interessante ainda: como estamos falando de OOP, em algum de nossos métodos vamos bolar um jeito de fazer esse mapeamento da forma mais simples e genérica possível, pra que não tenhamos que criar queries sql específicas para cada novo modelo que criamos.

Vejam a beleza dessa solução, caros leitores! Quando terminarmos a classe Model, qualquer novo objeto de uma classe que a estenda poderá ser salvo ou lido direto do banco sem precisar que nós façamos uma query específica!

Sendo assim, creio que já ficou bastante claro que precisamos das funções save() e load() em nosso modelo-base. A gente não precisa gastar muitos neurônios pra perceber que também precisamos da função delete() além da função __construct() que todos as classes já nos oferecem para criar novos objetos.

Nesse ponto começa uma saudável polêmica: onde devem ficar as funções para buscar objetos? Se eu quiser pegar todas as tenistas que estão no banco, pra quem eu devo pedir? Em alguns frameworks MVC, como o CakePHP, estas funções ficam na classe Model mesmo. Então vocë encontra funções como findAll(), findById(), findByName() e coisas assim, dentro da classe Model.

Pra ser muito sincero, eu acho meio esquisito pedir pra uma tenista buscar as outras tenistas. É assim que fica no CakePHP:

$tenista = new Tenista();

$todasastenistas = $tenista->findAll();

Cara, eu acho isso muito esquisito. A semantica da coisa, sabe? Acho que é um pouco de preciosismo, eu sei. Adoro o Cake, estou realmente impressionado com sua facilidade de uso, mas acho o design da classe model um pouco confusa.

Outros frameworks e ORMs fazem diferente. Criam uma classe só pra fazer isso. Um gnomo, lembram-se? Então, o cara faz o seguinte:

$gnomo = new DbManager();

$todasastenistas = $gnomo->findAll('tenista');

 Nesse caso, a classe DbManager tem todos os tais métodos pra retornar arrays buscados no banco. Hm. Acho um pouco melhor, mas ainda acho estranho não termos uma classe mais esperta, que possamos estender para criar comportamentos diferentes caso a gente precise. A resposta está próxima, caros amigos. Mas não posso perder a chance de continuar no próximo capítulo, não é mesmo?

Até a próxima.

2007-05-02 05:25:23
tags: 

O Zen e a arte cavalheiresca da programação orientada a objeto (Parte 15)

Para ver os artigos anteriores desta série, clique aqui.

Olá meus caros. De volta. "Que você viva em tempos interessantes". Esta antiga maldição chinesa (!?) explica muito bem a sensação que toma conta deste seu humilde autor. Muito a fazer, muito a compreender, pouco tempo. Desculpas à parte, retorno à esta série para falar mais um pouco sobre Exceptions, um conceito fundamental que talvez ajude alguns de vocês a poupar um tanto desse tão precioso tempo; afinal, como bem disse Benjamin Franklin, o tempo perdido nunca mais será encontrado.

Muito bem, senhores, o que faz nossas Exceptions tão especiais? Para entender, precisamos pensar na forma como gerenciamos erros em nossas aplicações. Ou melhor, precisamos pensar na forma como lidamos com erros em nossas vidas. Talvez isso complique as coisas, mas falar sobre a vida sempre é mais interessante, não?

Joãozinho trabalha numa fábrica de automóveis. (é um exemplo, ok? Não quero entrar em discussões morais sobre trabalho infantil, capitalismo, revolução industrial, etc e tal. Tudo bem, é um exemplo estúpido. Podemos ir em frente?) Joãozinho aperta parafusos na linha de montagem, e sua supervisora é a Mariazinha. O chefe da Mariazinha é o Aristides, que fica lá em cima no escritório.

Bom, você sabe que numa fábrica todo tipo de problema pode acontecer. Alguém pode esquecer de mandar o parafuso para o Joãozinho, o parafuso que foi mandado pode estar com defeito, o próprio Joãozinho pode vacilar e não apertar o parafuso... Sabe lá o que pode acontecer. Diante desse cenário, como você faz para gerenciar todos os erros que podem acontecer? Dá uma lista de IFs infinita para o Joãozinho para que ele mesmo resolva tudo? "Se o parafuso estiver com defeito, corra até a sala do Aristides e aperte o botão para parar as máquinas". "Se você dormir no ponto e não apertar o parafuso, corra até a sala do Aristides e aperte o botão para parar as máquinas", e assim por diante? Hmm... não sei se vocês estão entendendo, mas já está dando preguiça só de pensar em fazer essa lista. E a preguiça, amigos, é o nosso sentido-aranha, é nosso superpoder psiônico que avisa quando alguma coisa está esquisita no ar. Imagina se a Mariazinha tiver 50 funcionários sob sua supervisão, vai ter gente correndo pra tudo o que é lado, a sala do Aristides vai ficar totalmente destruída, e produção que é bom nada.

Apresento-lhes, então, as Exceptions, e seus companheiros inseparáveis Try, Catch e Throw. Vamos olhar para o problema acima de um outro ângulo. Imagine se a gente pudesse dizer o seguinte pro pessoal da fábrica:

Olha, Joãozinho, você vai tentar apertar o parafuso. Qualquer problema que você tiver, escreve num papel, amassa até virar uma bola e arremessa pra Mariazinha. A Mariazinha pega a bola, e se não for um problema que ela saiba resolver, amassa de novo e arremessa pro Aristides. Se ele também não souber resolver, a gente para a linha de produção na hora.

Tentar... Pegar... Arremessar... Vocês... sacaram? (se você viu Warriors, na versão legendada, está rolando no chão de rir nesse momento). [Agora relendo esse artigo me parece claro que o criador deste conceito gostava muito de baseball, ou cricket] Se vocês ainda não sacaram, vamos escrever um pouco de (pseudo)código:

/*
* Created on 02/05/2007
*
*/

class Apertador {

    function apertarParafuso(){

        echo "parafuso apertado!";

    }

    function oopa($descricao){

        echo "Apertador: oopa! Deu pau! Segura aí supervisor!";
        throw new Exception($descricao); // amassa e joga a bolinha pra cima!

    }

}



class Supervisor{

    function mandaApertar(){

        try {

            $joaozinho = new Apertador();

            $joaozinho->apertarParafuso();

            $joaozinho->oopa("Parafuso com defeito");

        }

        catch (Exception $e){
            echo "Supervisor: xi! Exception! Não sei o que fazer! Toma aí chefe!";
            throw $e; // peguei a bolinha, mas não sei o que fazer com ela... manda pra cima!

        }

    }

}



class Chefe{

    function vamosTrabalhar(){

        try {

        $mariazinha = new Supervisor();

        $mariazinha->mandaApertar();

        } catch (Exception $e) {
            
            echo "Chefe: Para tudo! Quero saber o que aconteceu aqui!"
		echo $e;
            die("Parando as máquinas!");

        }

    }

}


// Muito bem, agora a gente contrata o Aristides:


$aristides = new Chefe();

$aristides->vamosTrabalhar();

?>

 

Rode esse script e veja o resultado. Que interessante! Basta o Joãozinho mandar o erro pra cima que todos na cadeia (as classes que chamam a classe Apertador, neste caso) recebam aquela Exception, graças ao uso do comando Try. Tudo o que roda dentro de um bloco Try é monitorado, e caso uma Exception seja "jogada" ou "arremessada" pra cima o controle vai para o bloco Catch imediatamente abaixo.

Perceba também que ao gerarmos uma Exception, ela já é criada com um monte de informações importantes automaticamente: em qual arquivo e linha que o erro aconteceu, um Trace completo passando por todo o código até o Catch que "pegou" aquela Exception e muito mais. Para ver um bom resumo, basta mandar imprimir a variável que contém a Exception; mas você também pode acessar as propriedades do objeto separadamente usando métodos como $e->getMessage(), $e->getLine(), $e->getFile() entre outras. Não é bom isso?

Com as exceptions nosso trabalho passa a ser somente colocar os Throws nos locais onde erros acontecem, deixando o tratamento desses erros para classes mais acima na hierarquia. Mesmo que você não trate estas Exceptions com blocos Try/Catch a coisa funciona: você pode deixar a exception subir na hierarquia até chegar ao topo, pois toda exception que chega ao topo sem ser "pega" gera um erro fatal. Então, caros amigos, vocês podem trabalhar inicialmente só colocando throws no código, e, ao final, refinar o tratamento distribuindo blocos try/catch pelas classes da hierarquia. Muito bonito.

Mas tem uma coisa ainda mais bonita. Sim, amigos, a classe Exception pode ser estendida. É uma classe como outra qualquer. Isso quer dizer que no nosso caso você poderia criar a exception DefeitoParafusoException, que já conteria a mensagem de erro e mais outras informações que você necessita sem precisar nunca mais digitar. Exemplo:

 

class DefeitoParafusoException extends Exception {
     function __construct(){
        parent::__construct();
        $this->message = "Defeito no parafuso!";
    } 
} 

 

Sacaram? Agora toda vez que você criar uma nova Exception do tipo DefeitoParafusoException a mensagem já será colocada por default na variável $this->message da Exception em questão! Imagine o que você pode fazer com isso. Mas ainda tem mais. Imagine agora que você não quer parar a produção simplesmente por causa de um parafuso com defeito. Muito bem, então vamos fazer com que os Supervisores comecem a "Pegar" este tipo de Exception para não incomodar o chefe:

 

 class Supervisor{

    function mandaApertar(){

        try {

            $joaozinho = new Apertador();

            $joaozinho->apertarParafuso();

            $joaozinho->oopa("Parafuso com defeito");

        }

        catch (DefeitoParafusoException $e){
            echo "Supervisor: é só um maldito parafusinho, diabos! Continuem!";
        }
        
        catch (Exception $e){
            echo "Supervisor: xi! Exception! Não sei o que fazer! Toma aí chefe!";
            throw $e; // peguei a bolinha, mas não sei o que fazer com ela... manda pra cima!

        }

    }

}

 

pra ver isso funcionando, precisamos alterar a função Apertador::oopa() para mandar uma DefeitoParafusoException:

 

 function oopa(){

        echo "Apertador: oopa! Deu pau! Segura aí supervisor!";
        throw new DefeitoParafusoException(); // não precisa mais da descrição...
} 

 

E pronto. Vocês perceberam que podemos utilizar vários blocos de catch um embaixo do outro? Essa é a beleza desta solução. Podemos começar com um tratamento de erros bem genérico, e depois ir especializando com novas subclasses, sempre lembrando de colocar as subclasses mais específicas, neste caso a DefeitoParafusoException nos blocos anteriores, deixando o catch genérico (Exception $e) por último.

Por hoje é só, pessoal, dúvidas, reclamações, elogios e doações são bem-vindas. Grande abraço a todos.