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

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

Olá amigos. Estamos de volta depois de muita farofa, bacalhau, doce de leite, maionese, pamonha, queijo cavalinha, uma nova geladeira que não chega, livros e muita alegria. Espero que todos tenham passado dias maravilhosos nesse fim-de-ano e que possam ter aproveitado esses dias pra curtir a família e os amigos!

Mas chegou a hora de voltar para o batente. Antes que vocês comecem a mandar os já tradicionais emails "Cadê o 22! Queremos o 22!" eu já estou escrevendo mais um capítulo desta série singela, que procura explicar os conceitos mais enrolados de orientação a objetos em uma linguagem que todos aqui possam facilmente entender. E, pra ser bem honesto, os emails cobrando o 22 na verdade já começaram a chegar, então a hora é essa. Não estou reclamando de vocês de forma alguma, caros leitores! A pressão ajuda! Obrigado a todos que cobram, que agradecem, que mandam correções e puxões de orelha, sua contribuição faz disso aqui um lugar melhor.

Ah, o Natal. Que loucura que é o Natal. Falar sobre oop aqui no Digitalminds sempre é divertido porque eu tenho que bolar metáforas interessantes pra que o assunto não fique chato no primeiro parágrafo.  Então, como não poderia deixar de ser, o artigo de hoje está em clima de Natal. Não, eu não estou maluco, eu sei que o Natal já passou. Mas a segunda semana de janeiro não tem muita coisa interessante pra nos oferecer, a não ser que você conte o Dia de Reis.

O DIA DE REIS! É isso! Meu Deus como pude esquecer! Muito bem, senhores, esqueçam o natal. É hora de falar de Belchior (ou Melchior), Gaspar e Baltazar.
Não, senhores, não estamos falando de Belchior, nem de Gaspar, ou mesmo de Baltazar. Estamos falando de três magos persas, sacerdotes de Zaratrustra, homens sábios que conheciam profundamente a astrologia e que vislumbraram um sinal - na noite do dia 25 de dezembro do ano 1, souberam pelo brilho da estrela de Belém que um Rei nascera. E para comprovar que a wikipedia é sempre uma diversão, veja este parágrafo:

A melhor descrição dos reis magos foi feita por São Beda, o Venerável (673-735), que no seu tratado “Excerpta et Colletanea” assim relata: “Melchior era velho de setenta anos, de cabelos e barbas brancas, tendo partido de Ur, terra dos Caldeus. Gaspar era moço, de vinte anos, robusto e partira de uma distante região montanhosa, perto do Mar Cáspio. E Baltazar era mouro, de barba cerrada e com quarenta anos, partira do Golfo Pérsico, na Arábia Feliz”.

Uau. Sábios, caldeus, Ur, Pérsia. Agora que consegui a atenção total e irrestrita de vocês, futuros reis magos da OOP, e cobri todos de Incenso e Mirra, é hora de falar de uma classe importantíssima que ficou faltando no nosso grande esquema das coisas: a venerável classe ModelCollection.

Lembram que optamos por simplificar as funcionalidades da classe Model, fazendo com que ela realizasse operações somente em registros únicos no banco de dados? Muito bem, senhores, a classe ModelCollection aparece para nos salvar nos casos em que precisamos trabalhar com conjuntos de registros. Aqui é bom repetir o aviso: esta implementação é diferente da utilizada nos frameworks que utilizam o pattern ActiveRecord, como o Cake. Nestes frameworks todas as operações com registros e conjuntos de registros são feitas pela classe Model e suas subclasses. Assim, um objeto da classe model típico destes frameworks tem funções tanto para buscar, editar, salvar e deletar um registro quanto para buscar conjuntos de registros. Isso faz com que o objeto da classe que estamos usando não tenha um mapeamento direto com os dados que estão no banco. Isso me incomoda muito, pois eu gosto de pensar no objeto como uma coisa, uma representação virtual dos dados que estão no banco. Pra mim é estranho usar o modelo para retornar uma lista de registros. A nossa implementação vai claramente mapear um registro no banco a um objeto da classe correspondente, e um conjunto de registros a uma coleção de objetos da classe correspondente. Exemplo: nossa classe Post. Teremos no banco a tabela Posts, com os campos title e text, por exemplo. Para acessar e alterar  o campo de título de um post em nosso framework vamos seguir os seguintes passos:

1. Criar um novo objeto da classe Post fazendo $post = new Post();
   
2. Carregar os dados do registro que queremos alterar com id número $id  usando $post->loadById($id);
3. Mudar o título usando $post->setTitle("Novo Título!");
4. Salvar o post com $post->save();

1. Criar um novo objeto da classe Post fazendo $post = new Post();
2. Mudar o título usando $post->setTitle("Título do Novo Post!");
3. Mudar o texto usando $post->setText("Texto do Post!");
4. Salvar o post com $post->save();

1. Criar um novo objeto da classe PostCollection fazendo $collection = new PostCollection();
2. Carregar o conjunto de registros usando uma das várias funções disponíveis, por exemplo $collection->loadAll();

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

Olá amigos. Em nosso último encontro finalizamos nossa primeira análise das classes principais do MVC: Model, View e Controller. Sei que muitos de vocês estão ansiosos para começar a codificar mas ainda temos bastante mufa pra queimar antes de começar a digitar código php!

Bom, pra começar, um pouco da história do cinema: quem não se lembra de Sean Connery como o policial irlandês em Os Intocáveis ? E de Kevin Spacey, como o bobalhão "Verbal" em Os Suspeitos ? E de Gene Hackman como o xerife mau, muito mal de Os Imperdoáveis ? Muito bem, o que esses três papéis interpretados por estes grandes atores têm em comum? As três interpretações foram premiadas com Oscars de melhor ator coadjuvante. E por quê todo este papo cinematográfico? É que hoje vamos falar de uma classe coadjuvante que é fundamental em nosso quase-framework: nosso amigo Dispatcher.

Muito bem, como já falamos algumas vezes, nosso framework é bastante esperto: ele vai permitir que acessemos métodos de nossos controllers simplesmente interpretando uma URL. Por exemplo, para acessar o método view() do controller BlogPost para ver o post com o id 19 nossa url seria

http://nossoblog.com.br/blogpost/view/19

Ok, mas quem transforma uma coisa na outra? Quem chama o que? Como isso funciona na prática?

Senhores, eu vos apresento a classe Dispatcher, encarregada de interpretar as urls de nossa aplicação e executar os métodos apropriados nos controllers corretos. Ela também vai checar se o controller e o método requisitados realmente existem, e vai apresentar mensagens de erro em caso negativo. Por fim, a classe vai separar corretamente os parametros do request, enviando um array já certinho para o método que foi chamado.

Uma outra função muito interessante de nossa classe Dispatcher vai ser interpretar extensões; sim, amigos, vamos fazer com que a extensão definida na url defina o layout e o template a ser utilizado, seguindo uma estrutura de arquivos pré-determinada. Exemplo: se ao invés da url acima tivessemos alguma coisa como

http://nossoblog.com.br/blogpost/view/19.xml

Nosso framework, ao invés de utilizar o layout em /layouts/default/blogpost/view.php e o template /templates/default/blogpost/view.php utilizaria o layout /layouts/xml/blogpost/view.php e o template /templates/xml/blogpost/view.php. Deu pra sacar o poder? Assim vc pode criar outputs diferentes pra toda a sua aplicação sem nenhum estresse. Bonito demais. Pra colocar o sistema disponível em wap, bastaria fazer um layout e um template, no caso /templates/wml/view.php e /layouts/wml/view.php e utilizar os códigos wml ao invés de html dentro deles. Eu adoro isso.

Você acaba de perceber a beleza de uma solução MVC. A lógica fica totalmente separada da apresentação, o que faz com que seja fácil fazer apresentações totalmente diferentes com o mesmo conteúdo. Sweet!

Vamos então à descrição da classe?

Class Dispatcher

Propriedades

$url

String. Propriedade que irá conter a url requisitada.

$controller

Objeto do tipo Controller. Esta propriedade irá conter uma nova instância do controller requisitado. No nosso exemplo, BlogPost.

$method

String. Método a ser executado no controller requisitado. O método será view(), no nosso exemplo.

$parameters

Array com os parâmetros enviados na requisição via get ou post. No exemplo acima, ele teria uma entrada $parameters["default"]=>"19" já que não nomeamos este parâmetro no request. Poderíamos, se nós fossemos chatos, ter montado a url assim:

http://nossoblog.com.br/blogpost/view/id/19

e aí nosso array seria montado na forma $parameters["id"]=>"19"

O framework vai ser esperto o suficiente pra perceber quando temos só o valor ou o par nome/valor e vai resolver tudo isso pra nós.

Métodos

parseURL()

O método parseURL() interpreta uma URL segundo os padrões combinados e popula as propriedades do nosso Dispatcher. Na prática, ele vai separar os pedacinhos da url, dividindo a string em partes. Em primeiro lugar, ele remove a string relativa ao protocolo (http:// ou https://). Depois, o domínio. Ficamos então com a estrutura

controller/método/parametros.extensao

Aí fica facil separar tudo, não?

parseParams()
O método parseParams() faz o mesmo que a função acima, só que para os parâmetros enviados por get e post. Tudo o que estiver entre um ? e o ponto da extensão será considerado parâmetro get. Também será considerado parâmetro get tudo o que vier depois da action requisitada, no caso de nossos exemplos acima "19" e "id"=>"19". Tudo o que vier no $_POST vai ser incluído também em nosso array $parameters.

Repare que pra simplificar as coisas não vamos considerar a diferença entre get e post em nosso array $parameters; será igual fazer um request por get e post. Juntaremos tudo no array, sem distinção.

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

Olá pessoALL. Estamos aqui mais uma vez pra falar de Orientação a Objetos de um jeito bem prático, utilizando o pattern MVC para exemplificar conceitos importantes. A linguagem escolhida, você provavelmente já sabe, é PHP. Então sinta-se à vontade, sente mais perto da fogueira que já vamos começar nosso papo.

Chegamos a um momento importante de nossa série. Vamos falar hoje do último vértice da tríade MVC, mais especificamente a classe View. Você lembra que deixamos a classe View por último por se tratar do conceito mais simples dos três? Muito bem, chegou a hora de ver se a coisa é tão simples quanto falamos.

Nossa classe base View terá a responsabilidade de imprimir nossas páginas HTML, juntando o conteúdo dinâmico obtido por nossos Controllers ao código que colocamos nos templates que criamos. Portanto, primeiro precisamos definir direitinho o que é um template dentro de nosso framework, já que existem inúmeras definições por aí.

Nossos templates serão páginas php especiais, contendo basicamente html, que vão ser utilizadas por nossa classe View para imprimir as páginas de nossas aplicações MVC na tela. Normalmente nestes templates vão conter todo o html básico da página e comandos PHP para imprimir as informações dinâmicas provenientes do controller, normalmente usando só algumas poucas funções do PHP como echo, print e foreach.

<h1><?php echo $this->data['BlogPost']['title'] ?></h1>
<div class="post"><?php echo $this->data['BlogPost']['text'] ?>
</div>

Reparem que não precisamos incluir no template nenhuma informação de tipo de documento (DOCTYPE) ou mesmo a seção <head>. Nossa classe View vai colocar tudo isso automaticamente pra nós, de acordo com definições gerais que vamos colocar em outros arquivos, chamados de layouts. Os layouts são basicamente arquivos HTML sem a seção <body> do html, e servem justamente para que não precisemos ficar repetindo estas informações toda hora. A classe View vai combinar layouts e templates para construir a página. De forma simplificada, portanto, podemos dizer que nossos templates são o corpo do documento html (<body>), e os layouts são o resto. Deu pra sacar?

O que os templates têm de especial? Nada, sinceramente. Especial é o acordo que fazemos para só utilizar html e funções de apresentação dentro deles. Isso é fundamental para que não misturemos lógica (que deve estar toda no controller) e apresentação (que deve estar toda no template). Se você começar a usar outras funções que não echo, print ou foreach (ou alguma outra função de formatação, tipo printf ou number_format) dentro dos templates você vai voltar imediatamente pro inferno.

Alguns caras levaram isso tão a sério que chegaram a criar linguagens especiais só para não usar PHP dentro dos templates. O Smarty, um dos mais poderosos sistemas de template já escritos em php, faz exatamente isso.  Eles criaram tags especiais para cada uma das funções PHP de apresentação, além de terem bolado uma série de outras interessantes. Ao invés de escrever algo tipo

<h1><?php echo $nome ?></h1>

no Smarty você escreveria

<h1>{$nome}</h1>

Bem interessante, não? Isso força o programador a utilizar somente os comandos do Smarty, que são somente de apresentação.

Mas veja que desenvolver uma solução como essa dá bastante trabalho: no fundo, toda essa codificação especial precisa ser transformada novamente em PHP alguma hora. Os críticos dizem que isso é desnecessário e prejudica a performance, já que o PHP oferece todas essas funções nativamente. Bem, os caras do Smarty (e de outros template engines que existem por aí) contra-atacam dizendo que todos os templates são compilados e cacheados em PHP, de forma que a diferença de performance é mínima.

Nós não temos aqui a pretensão de escrever um Smarty; o caminho mais simples é usar PHP puro. Este, portanto, é o caminho que vamos seguir.

Vamos à nossa descrição genérica da classe View:

Class View
Propriedades

$data

Array associativo contendo todas as informações dinâmicas de modelos e coleções.

$url

String com a url que está sendo acessada.

$layout

String com o nome do layout a ser utilizado. O Default é nulo, o que irá fazer com que a classe View utilize um layout padrão.

$baseurl

String com a url base do site para facilitar a montagem de links e caminhos de arquivos.

 $variables

Array associativo que pode conter outras variaveis genéricas definidas pelo controller.

Métodos

render($action,$layout)

Imprime a ação $action usando o layout $layout. Os defaults são a ação corrente e o layout default.

setVariable($variablename,$value)

Define uma variável para uso no view.

setPageTitle

Define o título da página a ser impressa (na tag <title>)

renderError($error)

Imprime uma página de erro utilizando o layout default para erros.

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

Muito bem, caros amigos, voltamos à série que explica os conceitos transcendentais de programação orientada a objetos numa linguagem que todos podem facilmente entender. Este seu autor agradece novamente a todos pelos e-mails e comentários, são eles que nos incentivam a continuar sempre.

No último capítulo começamos a descrever nossas classes, notadamente a classe base Model, de fundamental importância em nosso quase-framework MVC. A fim de continuar nossa tarefa, proponho uma pequena reorganização de nosso estimado acrônimo: gostaria de falar neste artigo da classe base Controller, antes de falar da classe View. O motivo é simples: acredito que vai facilitar o entendimento se deixarmos para falar da classe View depois. Como o PHP é praticamente uma linguagem de construção de templates, posso afirmar de forma geral que todos que já trabalharam com PHP vão entender mais facilmente o conceito de Views.

Vamos lá, então? Vocês ainda se lembram do artigo no qual falamos que a url requisitada para o browser iria definir os modelos e ações a serem realizadas? Muito bem, só pra lembrar, nossas urls terão o seguinte formato:

http://www.meusite.com.br/modelo/acao/parametros

Nosso controller, então, vai saber direitinho em qual modelo aplicar uma determinada ação com certos parâmetros. Um exemplo seria:

http://www.meublog.com.br/blogposts/add/

Nesse caso, primeiramente nosso controller iria instanciar um objeto da classe BlogPost, que é filha da classe Model e já herdou tudo o que precisa para fazer as operações no banco de dados.

Repare que para facilitar vamos utilizar sempre o nome dos controllers no plural - alguns de vocês devem ter estranhado o fato de um controller BlogPostS instanciar na verdade um objeto da classe BlogPost (sem o S). O motivo é bem simples: o controller BlogPosts irá cuidar tanto da criação/edição/visualização/exclusão de um único BlogPost quanto da visualização de coleções de BlogPosts. Quando trabalhamos com um único registro, um único artigo de nosso blog, ele irá utilizar a classe BlogPost. Quando precisarmos trabalhar com coleções ou listas de artigos, como por exemplo uma listagem paginada, ele irá utilizar a classe BlogPostCollection.

Bom, vamos continuar: em seguida, nosso controller de BlogPosts iria executar seu método add. Este método iria checar se existe algum post http de formulário de dados do usuário.

Em caso negativo, ele instancia um objeto da classe View e imprime o template adequado, que claramente será um formulário que submete seus dados para a mesma URL,

http://www.meublog.com.br/blogposts/add

O template adequado, nesse caso, é o arquivo add.tpl, que fica dentro de uma pasta BlogPosts, que por sua vez vai ficar dentro de uma outra pasta Views, em um lugar seguro de nosso servidor que não precisa nem estar disponível publicamente. Repararam como até mesmo a organização dos arquivos é bem resolvida dentro de um framework? Só precisamos criar templates com os mesmos nomes que nossas ações e colocá-los nos folders com os mesmos nomes de nossos controllers para que a mágica aconteça.

Bom, imaginando que o usuário tenha preenchido o formulário acima e o tenha submetido, nosso controller recebe os dados, popula o objeto instanciado da classe BlogPost que está na propriedade $model com os dados que vieram do formulário, faz a validação executando o método $model->validate() e se estiver tudo bem, salva os dados executando $model->save() e mostra uma mensagem de sucesso usando o método flash(). Esse método imprime uma mensagem na tela durante alguns segundos e em seguida redireciona o usuário para outra página qualquer, no nosso caso provavelmente a lista de posts.

Deu pra entender?

Class Controller

Propriedades

$model

A propriedade $model vai armazenar o modelo no qual nosso controller irá operar as ações desejadas. Em nosso exemplo, ele armazenaria uma instância da classe BlogPost.

$modelcollection

A propriedade $modelcollection vai armazenar uma instancia da coleção relacionada ao modelo requisitado a fim de fazer as operações com coleções ou listas. No nosso caso, uma instância da classe BlogPostCollection.

$action

$action vai guardar a ação solicitada. No nosso exemplo, add. Para que a mágica funcione, nosso controller deverá ter um método add(). Para cada ação deverá existir um método correspondente em nosso controller; ações que não existem serão tratadas como erro.

$parameters

A propriedade $parameters guarda todos os parâmetros extras do request. Por exemplo, se estivéssemos vendo uma lista de Posts, poderíamos usar paginação, e o número da página viria como um parâmetro:

http://www.meublog.com.br/posts/list/page=3

$othermodels

$othermodels é uma propriedade que vai nos permitir instanciar objetos de outros modelos que não somente os da classe requisitada no request. Por exemplo, poderíamos querer utilizar as informações do usuário que está adicionando o post a fim de gravar no banco quem fez a última alteração. Assim, precisaríamos também de um objeto da classe User.

$view

Métodos

flash($message,$url,$seconds)

O método flash() mostra o texto de $message durante alguns segundos ($seconds) e em seguida redireciona para a url especificada. Muito útil para mostrar uma mensagem de sucesso ou fracasso de alguma ação.

redirect($url)

O método redirect() é muito simples: ele simplesmente redireciona o processamento para a url desejada.

Por hoje é só, pessoal. Voltamos a qualquer momento com mais orientação a objetos para vocês!

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

Olá Pessoal, estamos de volta com a série que mostra alguns princípios de programação orientada a objetos precisamente a cada rand (1,32768) dias!

Muito bem, senhoras e senhores. Acho que chegou a hora da gente "objetivar" um pouco e listar aqui nossas classes e seus métodos: até eu, depois de algum tempo sem escrever, me perdi! Já falamos livremente sobre os modelos, controllers e views de nosso quase-framework; agora é importante colocar no papel. Digo, no banco de dados. Enfim, vocês entenderam.

Então vamos começar com a classe Model, base para todos os nossos modelos:

Classe Model

Atributos 

$primarykey

String. Nome da chave primária do banco de dados. O default é id, mas pode ser qualquer nome desde que seja inicializado ao criar o modelo.

$table

String. Nome da tabela à qual o modelo será mapeado. O default é o nome do modelo.

$data

Array. O array $data vai conter os dados do modelo, mapeando cada campo com seu valor.

$fields

Array. Lista dos campos da tabela relacionada ao modelo, associado ao tipo e tamanho de cada campo. O default é obtido diretamente do banco de dados.

$validationstatus

Array. O array $validationstatus contém a situação de validação de cada campo do modelo. O método Validate() popula este array com a situação de cada um dos campos, (true/false) de acordo com as regras de validação de cada um.

Métodos

LoadById($id)

Carrega os dados do registro cuja chave primária é $id no array $data do modelo.

Save()

Salva os dados do modelo no banco. Antes executa a função ValidateFields() para garantir que os dados são válidos. Se a chave primária no modelo estiver vazia, ele cria um novo registro. Se estiver preenchida, ele atualiza os dados do registro que contém este id.

DeleteById($id)

Remove da tabela o registro com o id $id. Bem simples. O único perigo aqui é se a gente não configurar corretamente a tabela para lidar com o efeito cascata, ou seja, se a gente deixar alguém apagar um registro que é referenciado por outros registros. Por exemplo, se eu apago um post que tem vários comentários relacionados, precisamos remover todos eles, certo? A boa notícia, pra quem ainda não sabe, é que o banco cuida disso sozinho pra nós.

ValidateFields()

Valida cada um dos campos de acordo com suas regras de validação. Como a classe Model é uma classe genérica, ou melhor dizendo, abstrata, vamos fazer aqui uma validação também genérica, de acordo com as características dos campos da tabela. Assim, vamos validar, por exemplo, se um determinado campo é texto, e se seu tamanho está dentro do tamanho estipulado na descrição da tabela. Para validações mais específicas, vamos reescrever a função ValidateFields() em cada um dos nossos modelos.

Reparem, caros leitores, que nosso objetivo aqui é clareza e simplicidade. Poderiamos ter chamado a função LoadById simplesmente de Load; Mas a idéia é deixar o uso da função realmente claro; Percebam que já na função Save isso já não é necessário pois vamos salvar o estado do modelo no banco, sem a necessidade de nenhum campo específico estar definido. Para salvar um novo registro vamos simplesmente salvar um modelo que tenha sua variável $id vazia.

Uma diferença bastante grande desta proposta em relação ao Cake é a divisão de trabalho: como o Cake usa o pattern ActiveRecord, tem muita coisa dentro da classe Model. Aqui nós estamos dividindo este trabalho com a classe ModelCollection, que irá fazer todo o trabalho de banco de dados quando estivermos lidando com grupos de registros, ou coleções.

That's all, Folks! Mandem seus comentários, dúvidas e xingamentos e até a próxima!

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!

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, 3^o 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 e $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.

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.

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

Estamos de volta, caríssimos leitores. Mais uma vez agradeço pelos comentários e emails. No último artigo nós fechamos o conceito de controllers, e vimos alguns exemplos práticos de como usá-los. Nos artigos anteriores, definimos as outras partes do MVC, models e views (ou templates). Tudo isso sem escrever uma só linha de código.

Bem, depois de tanto tempo sem digitar um único if, alguns de vocês começam a manifestar uma patologia cientificamente conhecida como "fome de código", ou "Síndrome da abstinência de programação". Os sintomas são variados: suor nas mãos, digitação de códigos procedurais aleatórios, criação randômica de scripts, e, nos estágios mais avançados da doença, envio de emails e comentários para o site deste autor bradando palavras de ordem "Código! Queremos código!".

Para todos que estão desesperados para colocar a mão na massa, uma pequena história Zen talvez ajude a acalmar o espírito:

"Um monge perguntou a seu mestre:

– Mestre, quanto tempo vai demorar para que eu atinja a iluminação?

O mestre respondeu:

– Dez anos.

O discípulo respondeu, agitado:

– Mas e se eu trabalhar duro, estudar todos os sutras, praticar dez horas por dia, quanto tempo vai demorar?

– Nesse caso, respondeu o mestre, vai levar 20 anos."

Se existe uma coisa que é fundamental em OOP é paciência. É praticamente impossível fazer alguma coisa que funcione bem usando essa filosofia de trabalho simplesmente abrindo o seu editor e digitando código. Paciência, esse é o caminho.

Mas é necessário desenhar TODO o sistema, cada detalhe, cada vírgula? Certamente não. Mas como saber qual é o momento de parar de desenhar e começar a programar de fato? Ah, jovem monge, nós saberemos. Acredite, nós saberemos. Chegará a hora em que não teremos mais dúvidas, que vamos olhar nosso desenho do sistema e vamos dizer "é, acho que agora já dá pra começar". Ao longo dos anos muitas metodologias e processos foram criadas para tentar desvendar este mistério. Mas só o próprio desenvolvedor, em seu íntimo, sabe quando está pronto. Por mais documentação que um sistema já possua, por mais discussões que se tenha, por mais diagramas e casos de uso e o que for, sempre existe o momento da iluminação, quando tudo aquilo a que fomos submetidos simplesmente "clica" e começa a fazer sentido. Todas as nossas questões sobre como o sistema funciona começam a ser respondidas claramente, e não há mais nenhuma pulga atrás de nossas orelhas.

É, talvez essa seja uma boa definição: a hora de começar a programar é a hora em que não encontramos nenhuma pulga atrás de nossas orelhas. E nesse momento, ainda tenho algumas quando penso em nosso Digitalminds Blogging Engine. Por exemplo: Já sabemos quais são as classes principais que vamos usar, e como vamos usá-las. Mas ainda não sabemos quais métodos e variáveis elas vão apresentar. Qual a vantagem de termos as superclasses Model, View e Controller se não encontrarmos métodos e variáveis que efetivamente facilitem nosso trabalho de criar um sistema? Isso, caros leitores, é precisamente o que vamos fazer nos próximos artigos. Mas ainda nesse artigo quero tentar responder a uma outra questão que está na minha cabeça: Será que não precisamos de mais nenhuma classe nessa história toda?

Bom, eu sempre costumo dizer que a preguiça é uma das minhas grandes virtudes; ela já me ajudou a resolver inúmeros problemas e a ganhar muito tempo pra fazer o que realmente importa na vida, ou seja, nada. De qualquer modo, o que quero dizer com isso é que sim, acredito que teremos algumas outras classes nos ajudando a fazer coisas repetitivas ou chatas demais.

A primeira coisa que me vem à cabeça é "o que fazemos se um erro acontecer?". Sim, amigos, erros vão acontecer, e nós precisamos estar prontos para lidar com eles de uma forma civilizada. E quem já escreveu um sistema qualquer em linguagem procedural sabe como é chato fazer tratamento de erros. São tantas possibilidades, tantas combinações de erros, tantos ifs e tantos switches que só os mais corajosos acabam fazendo tratamento de erro de uma forma realmente completa.

Mas os criadores da programação orientada a objeto, em sua infinita sabedoria, olharam para nós mortais com piedade e com o som de mil trombetas bradaram "Que se criem as Exceptions!" E então, o mar turbulento do tratamento de erros se abriu, e o povo programador pôde passar em paz. Os criadores do PHP, em sua razoável e confusa sabedoria, olharam para nós, os loucos que usam essa linguagem idiossincrática, e também bradaram "Que se criem as Exceptions em PHP5!". E em um segundo, tudo o que já foi feito em PHP para tratamento de erros se tornou obsoleto e bizarro.

O conceito de Exception, senhores, é uma das coisas mais impressionantes que já foram criadas. E, como todo conceito mais complexo de OOP, é muito difícil de entender, justamente por ser uma coisa relativamente simples. Entendeu? Certamente não. Então fique ligado e não perca o próximo artigo.

Grande abraço pra todo mundo.

— Olha, vamos precisar colocar esses 15 logos na página, mas precisamos que você coloque um em cada parágrafo, ok?

Bom profissional que você é, aceita resoluto a solicitação do cliente e insere uma a uma as imagens na página, transformando a sua linda criação em uma quase-árvore-de-natal feita de símbolos e logotipos que não têm absolutamente nada a ver uns com os outros. Pra que a coisa fique minimamente interessante, você perde mais 45 minutos ajustando o css, mexendo no tamanho das imagens, enfim, fazendo o rejunte e o acabamento.

Considerações estéticas à parte, a página eventualmente fica pronta e você pede a aprovação do cliente. Então, caro amigo, o inesperado acontece:

— Olha, ficou poluído demais. Pode voltar atrás.

O que?! Voltar atrás?

É aqui que entra nosso teste: nessa momento de tensão, caro leitor, o que você faria:

Opção 1: aceita, emburrado, e recomeça de imediato a corrigir o código, removendo uma a uma cada modificação feita. Depois, precisa revisar tudo novamente pra ver ser não ficou nenhum erro, se o layout está igual ao original (mas peraí, eu detonei o original!)

Tempo total: 30 minutos.

Opção 2: aceita, levemente aborrecido, e começa a procurar os arquivos de backup que você havia feito antes de alterar os arquivos. Depois, precisa revisar tudo novamente pra ver se realmente tudo está certo, se aquele “salvar como” foi feito com todas as últimas alterações, se aquela modificação de texto que a menina pediu por telefone estava incluída.

Tempo total: 7 minutos.

Opção 3: aceita, com um sorriso cativante no rosto, e clica com o botão direito do mouse no ítem “TortoiseSVN->Exibir histórico”, escolhe a revisão anterior, e clica com o botão direito novamente “Reverter para essa revisão”. Pronto.

Tempo total: 5 segundos.

Muito bem, meu amigo, minha amiga, o que este teste mostra para nós? Se você respondeu opção 1 ou opção 2 você precisa de um sistema de controle de versão. Fato.

Um sistema de controle de versão guarda diferentes versões de um mesmo documento em um repositório e é capaz de fazer operações com elas. Assim, é possível não só voltar a uma versão anterior de um arquivo instantaneamente, mas também comparar e ver exatamente as diferenças entre duas versões, linha a linha. Mais que isso, duas ou mais pessoas podem trabalhar ao mesmo tempo em um arquivo texto, combinando as partes alteradas quando terminarem. Não é feitiçaria, é tecnologia!

Existem várias soluções para controle de versão disponíveis no mercado. Uma das mais populares é a chamada Subversion, ou simplesmente svn.

O Subversion usa uma interface de linha de comando, mas graças à bondade da comunidade open-source já foi desenvolvida uma interface gráfica para Windows chamada TortoiseSVN que é bem mais fácil de usar. Faça o download da aplicação e da tradução para o português brasileiro no endereço

http://tortoisesvn.net/downloads

Observação: Para quem usa mac, existe o SvnX. É um pouco confuso, mas talvez ajude:

http://www.apple.com/downloads/macosx/development_tools/svnx.html

Depois de instalar o TortoiseSVN (será necessário reiniciar o Windows), você já pode criar seu primeiro repositório:

- crie uma pasta nova para conter seu repositório

- clique com o botão direito do mouse nessa pasta e escolha “TortoiseSVN->Criar repositório aqui”.

Pronto, já temos um repositório. Você não vai trabalhar nessa pasta: os repositórios svn guardam os arquivos num formato proprietário que não pode ser usado; Para trabalhar, é preciso fazer um “checkout” do repositório em outra pasta, ou, em português, “Obter” os arquivos do repositório:

- crie uma pasta para guardar seus arquivos de trabalho;

- clique com o botão direito e escolha “SVN Obter”

- Agora é necessário digitar no campo “URL do Repositório” a url do repositório que você criou. Como trata-se de um folder no sistema de arquivos, use o prefixo file:/// antes do caminho da pasta. Exemplo: file:///C:meurepositorio

- clique OK

Pronto. A partir de agora, os arquivos desta pasta poderão ser “Submetidos” clicando com o botão direito sobre ela e selecionando “TortoiseSVN->Submeter” . Uma janela se abrirá e você vai poder selecionar os arquivos que deseja submeter.

Dica importante: nunca apague ou renomeie um arquivo obtido de um repositório subversion pelo Windows; sempre use o menu do TortoiseSVN. Quando isso acontece, o banco de dados interno do subversion fica perdidinho e você pode ter algumas surpresas.

Para saber mais não deixe de ler o livro “Controle de Versão com Subversion”, que já está parcialmente traduzido para o português no endereço

http://svnbook.red-bean.com/

Nos próximos posts da série, vou mostrar como usar um repositório online do Dreamhost.

Divirtam-se!

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

Olá caros amigos caçadores de gnomos. Estamos de volta. Ainda precisamos fechar bem fechado este conceito fundamental chamado controller. Pegando do ponto onde paramos, que tal darmos alguns exemplos práticos de como nossos controllers vão funcionar? Gostou da idéia? Então entra aí e vamos lá.

Onde queremos chegar com toda essa conceituação? Bem, alguma coisa simples que torne o desenvolvimento e o uso de novas funcionalidades bem fácil. Vamos a alguns exemplos.

Primeiro, quero ver uma lista de posts simplesmente acessando a URL

http://meublog/posts/listar

Simples assim. Para criar um novo post:

http://meublog/posts/criar

Ah, e para ver um determinado post, o chamado permalink, quero acessar

http://meublog/posts/ver/xxxx

onde xxxx é o id do post, seja ele um texto ou um número.

Da mesma forma, para editar um post, quero acessar

http://meublog/posts/editar/xxxx

Para apagar um post

http://meublog/posts/apagar/xxxx

e assim por diante. Gostou? Muito bem, meu amigo, você acaba de definir o nosso primeiro controller, e suas primeiras funções ou métodos. Sim, veja a beleza da solução MVC, você está presenciando um mapeamento direto entre classes e métodos diretamente na url que o usuário acessa! Nas urls acima temos um controller chamado posts que tem 5 métodos: listar, criar, ver, editar e apagar.

Repare que ajuda bastante manter a coerência de linguagem - controllers normalmente são substantivos no plural (já que normalmente eles "controlam" dados de um modelo, no caso o controller "posts" lida com as informações do modelo "post") e os métodos normalmente são verbos. Alguns até chamam os métodos de "actions" ou ações, já que realmente nada mais são do que ações de fato. Capisce?

Bom, a essa altura já deve estar claro pra vocês (caso não esteja prometo que devolvo o dinheiro de volta) que já que temos dois modelos (posts e comentarios) precisamos, no mínimo, de dois gnomos: um pra cuidar de posts, e outro pra cuidar de comentários. Nasce, então, o controller "comentarios". Já sabem as urls e métodos que vamos ter que criar?

Por hoje é só. Até a próxima!

Ao longo dos anos aprendi que uma boa estratégia é ter 3 ambientes distintos de trabalho: Produção, Validação e, finalmente, um ambiente de testes internos. O primeiro, intocável, é o ambiente onde os clientes acessam a versão do site atual. O segundo ambiente é o ambiente de validação, onde o cliente aprova as alterações feitas no site. O terceiro é o ambiente onde você testa as modificações antes de apresentar ao cliente.

Acredito que a coisa realmente importante desse approach é ter um ambiente separado de validação para o cliente. Assim você não corre o risco de "quebrar" o site enquanto ele revisa alguma outra coisa que você já fez.

Mas como fazer isso na prática? Um dos motivos da minha simpatia pelo Dreamhost é a possibilidade de criar subdomínios ilimitados. Assim, crio dois subdomínios, um de validação para o cliente e um de teste para mim. Exemplo:

• http://cliente.digitalminds.com.br (ambiente de validação, url enviada para o cliente)
• http://teste.cliente.digitalminds.com.br (ambiente de teste)

Para criar um subdomínio no Dreamhost é muito fácil: acesse o painel de controle, clique na opção "Domains", e em seguida no link "Add New Domain / Sub-Domain". O painel de controle vai configurar automaticamente o subdomínio pra você e já vai criar a pasta com o mesmo nome no seu diretório home. 

Trabalhe localmente e suba os arquivos para o ambiente de teste. Se tudo estiver bem lá, inicie o procedimento de atualização:

1. Renomeie a pasta atual cliente.digitalminds.com.br para cliente.old (se alguma coisa inesperada acontecer é so voltar atrás)
2. Duplique a pasta teste.cliente.digitalminds.com.br e renomeie para cliente.digitalminds.com.br

Tudo pronto, seu cliente já pode fazer a validação das mudanças. Assim você não interrompe o site de validação durante o upload e tem certeza de que tudo está funcionando no servidor.

Existem formas ainda mais bonitas de fazer este tipo de atualização, especialmente se você tem Subversion disponível. Mas aí é outra dica. Pra coisas simples isso funciona muito bem, e você ainda pode fazer um pequeno script bash pra automatizar tudo.

É isso, gente. Até a próxima. Para ver todos os artigos desta série, acesse http://www.digitalminds.com.br/tags/pw

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

E estamos de volta, amigos, em dia de Superbowl (você nem precisa gostar do esporte, mas assistir à final é quase uma obrigação. Os comerciais mais esperados do ano são exibidos durante o evento, o show do intervalo vai ser de Prince, e quem ainda não ouviu o comentarista da ESPN de futebol americano não sabe o que está perdendo - é a coisa mais engraçada da televisão brasileira). Mas nós não estamos aqui para falar de futebol americano, não é? Nosso assunto de hoje, isso sim, são gnomos!

Os gnomos, como todos sabemos, são criaturas lendárias que geralmente usam chapéus ponteagudos e barbas enormes. Presentes na mitologia européia e nos jardins de muitas pessoas de gosto duvidoso, nossos pequenos amigos têm a fama de ter poderes mágicos e de viajar pelo mundo.

Muito bem, caros leitores, chegou finalmente a hora de revelar a todos o porquê da presença desses furtivos seres em nossa história. O que têm em comum, afinal, os gnomos e a programação orientada a objeto?

(rufar de tambores) (trilha de "psicose") (silêncio absoluto)

A resposta é muito simples. Absolutamente nada.

Mas peraí! Peraí! Antes de pegar os ancinhos, enxadas e outras ferramentas agrícolas e se dirigirem até minha casa bradando "IMPOSTOR! IMPOSTOR! MORTE AO IMPOSTOR" preciso de algumas linhas para me explicar.

Dentro da minha filosofia "PHP de Rua®" procuro sempre usar metáforas para explicar alguns conceitos que considero mais complexos. Ok, algumas dessas metáforas não são tão interessantes assim, mas acho que algumas já ajudaram alguns de vocês a compreender um pouco mais do assunto em pauta. Os gnomos, meus caros, são mais uma dessas metáforas, como vocês já devem ter percebido.

A idéia de usar os gnomos me veio à cabeça quando comecei a entender melhor o conceito de "manager" em orientação a objeto. Muito bem, vamos recapitular um pouco pra lembrar alguns conceitos importantes. Todos se lembram que definimos classes para Automóveis, Seres Humanos, e outros objetos? Agora quero pedir que vocês procurem ver uma característica que todas essas classes têm em comum, do ponto de vista conceitual: todas elas são criadas a partir de objetos que, de um modo ou de outro, são coisas de verdade no mundo real. Um automóvel existe como "coisa" tanto abstratamente quanto concretamente. Não sei se vocês estão entendendo, mas talvez ajude dar um exemplo de alguma coisa que não exista na realidade para que fique mais claro.

Na nossa série temos focado em um tipo de modelagem chamada "Real World Modeling", ou modelagem do mundo real. Ou seja, sempre que falamos de classes e objetos, falamos de alguma coisa que efetivamente existe no "mundo real". Automóveis e Seres Humanos são exemplos disso. Poderíamos falar também de Registros (de um banco de dados) ou Fichas de Cadastro; mas sempre partimos de uma "coisa" que já existe na realidade, um conceito pré-existente. Sempre tive mais facilidade de entender este tipo de modelagem; é o que me parece mais lógico. Mas, como vamos ver, muitas vezes em programação orientada a objeto um sistema é modelado usando conceitos que não são reais, ou melhor dizendo, usando conceitos que são criados somente para o sistema que se está desenhando.

Os Controllers, peça fundamental do design pattern MVC, são justamente um exemplo deste problema. Explico: é fácil imaginar que um sistema de gerenciamento de blogs tenha as classes Post e Comment, pois no mundo real estes ítens são componentes de um blog. O conceito de Controller, no entanto, jamais apareceria se nós tentássemos encontrá-lo simplesmente olhando um blog. Trata-se de uma classe criada a partir de uma metáfora de uso criada especificamente para resolver um problema de programação. Na prática, estas classes são normalmente muito importantes em um sistema, e ao mesmo tempo são as mais difíceis de criar, já que não têm uma contrapartida no mundo real.

Mas muito bem, ok, já entendemos que os tais Controllers são diferentes dos outros objetos, mas o que eles são exatamente? Aha, aí é que está. Eles são gnomos, amigos. Criaturas imaginárias que fazem coisas pra nós. Eles recebem ordens e as executam, não recebem salário e não reclamam (bom, se a gente programa tudo certo eles não reclamam).

Os Controllers são fundamentais no modelo MVC, pois são os responsáveis por receber as ordens, ou requests, dos usuários do sistema, interpretá-las e mandar novas ordens para que outras classes executem seus métodos. Eles mandam no pedaço. São os reis da cocada preta. Os maiorais.

Muitos de vocês talvez já saibam que existem dois métodos muito importantes para se requisitar (request, sacou?) coisas quando no protocolo http. Eles são os superpoderosos GET e POST. O método GET pode ser visto na maioria dos sites, é só procurar uma url que tenha uma interrogação. Nesse tipo de request o pedido é feito na própria url, passando muitas vezes pares de variáveis separados por um & (e comercial). Um request GET típico seria:

http://www.google.com.br/search?q=oop

Este request, como vocês podem imaginar, está passando a variável "q" com o valor de "oop" para o sistema. Tudo bem simples e trivial.

Um request post é muito parecido. Na teoria, estes requests teriam funções diferentes, o primeiro para "pegar" informações do servidor e o segundo para "colocar" ou "postar" informações lá. Mas, na prática, essa regra não se aplica muito, a coisa é bem misturada. Para nós, essa distinção não é importante, e para um Controller de verdade ela também não deveria ser, já que queremos que esse gnomo entenda qualquer tipo de ordem que o usuário passe para ele.

Esse é exatamente o ponto. Um controller "recebe" ordens, ou requests e executa métodos de acordo. Ou seja, qualquer request que chege em nosso site irá ser tratado por um gnomo, ou Controller, que irá dizer para modelos e outras classes "ei, você, post número 25, apareça aqui que o usuário quer editá-lo!" ou "Ei template Lista de Posts, tome aqui esta lista de posts e desenhe-se na tela". Em um sistema que implementa autenticação de usuários, por exemplo, os Controllers perguntariam "Ei, autenticador, este cara aqui pode editar este post?" e coisas assim. Deu pra entender?

Até a próxima. Alguém aí já está se coçando pra escrever algum código? Calma, gafanhoto... Ainda temos que decidir que gnomos precisamos. Vejo vocês por aí. Grande abraço.

(Para ver todas as partes desta série clique aqui)

Olá, pessoal, já estamos aqui de volta para falar mais um pouquinho sobre OOP, PHP, e outras siglas igualmente ininteligíveis. Hoje quero falar sobre um tema que sempre gera muita confusão: interfaces. E, é claro, não podemos falar de interface sem olhar a etimologia dessa palavra.

O prefixo inter- vem da preposição latina inter, que significa "entre, no meio de". A palavra face, também de origem latina (fascia), significa "camada externa". Juntando as duas coisas, temos um termo genérico que significa praticamente qualquer coisa em tecnologia. Temos interfaces gráficas, interfaces com o usuário, interfaces RS232, interfaces usb, e por aí vai.

O conceito denominado de interface em OOP é bastante diferente disso tudo. No nosso mundo imaginário de carros, superpoderes, gnomos e outras criaturas fantásticas orientadas a objeto, interfaces são simplesmente definições padronizadas de acesso a funções que estão dentro das classes que as implementam. Falando assim parece bem complicado, mas não é não. Na verdade, na verdade, se a gente olhar com muito cuidado, nós de fato já usamos o conceito de interface aqui mesmo nos artigos anteriores.

Explico: quando nós criamos uma classe, estamos criando também uma interface. Lembra que nós construímos dois carros, um FiatUno e uma FerrariF1, e ambos podiam ->acelerar() ? Justamente! Ajoelhe-se diante do poder das interfaces!

Ao estender a classe Automovel para criar a classe FiatUno e a classe FerrariF1 nós estamos automaticamente implementando a interface usada na classe automóvel nas duas. Assim, temos absoluta certeza que todas as classes-filhas da classe Automovel vão poder ->acelerar(). Esse é exatamente o conceito de interface: a padronização do acesso aos dados e funções de uma classe ou objeto.

Mas o que é realmente interessante é que algum desses gênios malucos que inventaram os conceitos de OOP acordou um belo dia e teve uma idéia brilhante: "Perai, mas eu não preciso ter que criar classes-filhas toda hora pra usar uma interface!". Nasciam as palavras-chave interface e implements, que permitem a criação de interfaces que podem ser usadas entre classes que não tem nenhum parentesco entre si.

E eu estou aqui para provar tudo isso implementando Superpoderes em Automóveis! Você há de concordar que um Automovel não tem nada a ver com um SerHumano, já que eles não têm nenhum parentesco. Como ter certeza que essas classes e todos os seus filhos possam usar objetos da classe SuperPoder de forma padronizada? É fácil:

Primeiro, criamos a interface SuperHeroi:

 interface SuperHeroi {

    public function ativar(SuperPoder $superpoder);

} 

Bom, como você pode notar, a função ativar só vai funcionar se você mandar pra ela o SuperPoder desejado durante a chamada da função. Se mandar texto, número ou qualquer outra coisa vai ganhar um erro de presente.

Agora vamos alterar nossas classes Automovel e SerHumano para implementar a interface SuperHeroi:

Class SerHumano implements SuperHeroi { 	

    public $nome;

    public $vivo; 	

    public function __construct($nome) {

        $this->nome = $nome;

        $this->vivo = true;  	

    }

    public function taVivo() { 

        if($this->vivo == true) {             		

            print "Sim, eu estou vivo, e meu nome é $this->nome!"; 	

        } else {             	

            print "..."; 	

        }  	

    }

    public function ativar(SuperPoder $superpoder){

        $superpoder->ativar()

    }
 

} 

e agora a classe Automovel:

 abstract class Automovel implements SuperHeroi {
     public $aceleracao;
     public $velocidade_atual;
     public $cor;

     public function acelerar() {
        $this->velocidade_atual = $this->velocidade_atual + $this->aceleracao;
        print "Acelerando! Agora a velocidade é de " . $this->velocidade_atual . "Km/h!";
     }    

    public function ativar(SuperPoder $superpoder){

        $superpoder->ativar();

    }

 }

Agora, tanto os objetos SerHumano quanto objetos da classe Automovel (incluindo aqueles das classes FiatUno e FerrariF1, já que pela herança um FiatUno ou uma FerrariF1 sempre têm todas as propriedades e funções da classe Automovel) já podem ->ativar() um SuperPoder. Como a classe SuperPoder é abstrata e ninguém consegue ativar um SuperPoder abstrato, vou ativar a SuperForca:

$meucarro = new FerrariF1('vermelha'); 

$meucarro->ativar(new SuperForca);

// Meu deus, posso levantar um caminhão! 

E os gnomos, você deve estar se perguntando. Eles virão... Eles virão...

Pra quem ainda está procurando por um bom provedor recomendo enfaticamente o Dreamhost. Como já comentei anteriormente, tinha bastante gente que tinha gostado do Dreamhost mas que achava a taxa de setup muito alta. Aí lembrei que eu posso dar um desconto pra quem assinar usando o Digitalminds como referência. Então, como não estou aqui pra viver disso, resolvi descontar toda a taxa de setup da grana que eu receberia por cada referral. Ainda vou ganhar o suficiente pra pagar minha conta lá, então tá tudo certo.

Pra quem não conhece o Dreamhost, essas são algumas das características:

• PHP 5
• Bancos de Dados mysql ilimitados e acessíveis externamente
• Criação de usuários FTP e SSH para clientes
  
• 20 Gb de espaço em disco
• 1 Tb de Transferência (Sim, 1 Terabyte)
  
• dominios e subdomínios ilimitados
• endereços de email ilimitados
• acesso total via ssh (inclui crontab jobs para automatização)
• .htaccess (mod rewrite permitido para o Apache, autenticação Digest)
• suporte técnico (em inglês)
• Instalação em 1 clique de Wordpress, PHP Gallery, PHPbb Fórum, MediaWiki, Joomla e Zencart
• Servidor Jabber e Quicktime Streaming
• e agora, servidores SVN ilimitados (Subversion)
• Você ainda ganha um domínio (.com ou .net) totalmente grátis.    

Com a promoção, você paga US$ 10,95 no cartão de crédito por mês, sem taxa de adesão. Se pagar um ano de uma vez, eles não cobram a taxa, você paga US$9.95 e você ainda ganha o desconto, ficando com 5 meses grátis. Se quiser pagar 2 anos de uma vez o preço cai pra US$8.95 e você ainda ganha o desconto, ficando com 6 meses grátis. Vale a pena!

Mas cuidado: não tem suporte nem documentação em português. Se você está procurando um bom provedor com suporte diferenciado aqui no Brasil, recomendo o Vilago, do Cris Dias.

ATENÇÃO: Algumas pessoas tiveram dúvidas sobre como pegar o desconto, pois ele não aparece até a verificação final.

1. Escolha o plano de hospedagem;
2. Preencha os seus dados;
3. na página entitulada Verify Total, coloque DIGITALMINDS no campo Promo Code;
4. aperte o botão UPDATE para receber o desconto.

Clique aqui para escolher seu plano e aproveite.

(Para ver todas as partes desta série clique aqui)

Falar de cães, gnomos, seres imaginários e programação orientada a objetos não tão divertido sem falar de Carl Linnaeus , um estudante de medicina sueco nascido em 1707 que adorava coletar e estudar plantas. Naquele tempo o estudo da botânica era parte do currículo médico, já queas plantas forneciam a matéria-prima para a fabricação da maioria dos medicamentos.

Em 1735, ao completar seus estudos na Holanda, Carl publica a primeira edição de um dos livros mais importantes da história da humanidade: o Systema Naturae, sua tentativa de organizar e classificar toda a vida na Terra. Outros já haviam feito suas próprias classificações - Aristóteles, o sábio grego, teria feito a primeira tentativa conhecida, agrupando os animais "com sangue" e os "sem sangue". Como o nosso amigo sueco era bem prático, a primeira edição tinha apenas 11 páginas. Mas Linnaeus sabia que era o início de algo muito, muito importante.

Duzentos e setenta e um anos depois muita coisa mudou mas a obra de Carl Linnaeus continua viva, atualizada ano após ano com novas descobertas e mudanças paradigmáticas. Nem é preciso dizer que o trabalho de Charles Darwin também influenciou e muito a classificação da vida. Mas isso não é tão importante agora, na verdade. O importante para nossa conversa é o conceito de classificação em si; Trata-se de uma idéia fundamental para nós, seres humanos; tudo o que vemos e criamos é instintivamente classificado e organizado em grupos similares, de acordo com características que podemos perceber ou mesmo de acordo com padrões sócio-culturais. Por exemplo: se a gente vê uma coisa com caule, galhos e folhas a gente imagina que seja uma árvore, se a gente vê uma coisa com quatro patas que late a gente imagina que seja um cachorro, e se a gente vê uma criaturinha pequena, vestida de verde com uma longa barba branca a gente imagina que seja um gnomo. Mesmo que os conceitos "árvore", "cachorro" e "gnomo" não existam pra nós (digamos que você seja um esquimó vivendo numa ilha totalmente isolada no polo súl que só tem pinguins) é possível perceber, só de olhar para duas "coisas" dessas, que elas são similares. Esse é o exatamente o conceito de classe original - um grupo de coisas com características comuns.

Pra tornar as coisas um pouco mais confusas, a biologia se apropriou deste termo e na classificação biológica atual ele tem um sentido mais específico, um determinado ponto da hierarquia de classificação e se junta a outros termos como espécie, gênero, reino, entre outros. Exemplo: um cachorro é da classe mammalia, ordem Carnivora, família Canidae, espécie Canis lupus. Mas então vamos esquecer tudo isso, e lembrar somente do conceito original da palavra classe - coisas com a mesma classe têm as mesmas características. Tudo bem? Então agora a gente pode generalizar: eu agora te digo que dois objetos que sejam da mesma classe têm as mesmas características e as mesmas funções. Tipo, uma Ferrari F1 tem a mesma classe de um Fiat Uno, sacou? Os dois são automóveis, servem pra se locomover, têm quatro rodas, etc e tal. Agora, claro que uma Ferrari F1 é bem diferente de um Fiat Uno (quem já teve os dois sabe do que eu estou falando :-D Então também podemos dizer que cada um deles faz parte de uma classe mais específica, que estende o conceito da classe Automóvel, que vamos chamar de classe-mãe.

Repare que objetos que sejam somente da classe Automóvel não existem na realidade - é impossível entrar numa loja e comprar um automóvel abstrato, você sempre vai ter que comprar um automóvel de verdade, certo? Então podemos dizer que essa classe é abstrata. Com isso na cabeça, olha o seguinte "código":

abstract class Automovel {    

    public $aceleracao;    

    public $velocidade_atual;    

    public $cor;        

    public function acelerar() {        

        $this->velocidade_atual = $this->velocidade_atual + $this->aceleracao;        

        print "Acelerando! Agora a velocidade é de " . $this->velocidade_atual . "Km/h!";    

    }

}

class FerrariF1 extends Automovel {    

    public function __construct($cor){        

    $this->cor = $cor;         $this->aceleracao = 50;    

    }

}

class FiatUno extends Automovel {    

    public function __construct($cor) {

        $this->cor = $cor;        

        $this->aceleracao = "1";    

        }

}

Ficou difícil? Bom, não é tão difícil não. É o seguinte: A classe Automovel define as características similares de todos os automóveis. Todos eles têm cor, uma aceleração, e uma função acelerar para aumentar a velocidade atual. Simples. As classes FerrariF1 e FiatUno estendem esse comportamento sem perder as características originais da classe Automóvel: mesmo sem definir a funcao "Acelerar" dentro dessas classes as FerrarisF1 e FiatUnos vão poder acelerar, sem problemas.

A funcão __construct (esse nome pode variar de acordo com a linguagem de programação que você estiver usando, no caso estou mostrando o exemplo na linguagem PHP, versão 5) é a fábrica de automóveis: ao ser chamada ela constrói uma FerrariF1 ou um FiatUno de acordo com as especificações. Se eu pedir

    $meucarro = new FerrariF1("vermelha");

A fábrica vai construir pra mim uma FerrariF1 com a cor vemelha. Um luxo. Vou comprar um carro pra você:

     $seucarro = new FiatUno("branco");

E o pessoal de Betim já deve estar correndo pra pintar o Uno de branco uma hora dessas.

A aceleração é diferente: No caso das FerrariF1, elas já nascem com uma aceleração de 50. O Uno não anda tão rápido assim e nasce com uma aceleração de 1. Então tá na hora de apostar corrida;

    $meucarro->acelerar(); // Acelerando! Agora a velocidade é de 50Km/h!

    $seucarro->acelerar(); // Acelerando! Agora a velocidade é de 1Km/h!

Cara, acho que você devia comprar um carrinho melhor, viu? E os gnomos, você deve estar se perguntando. Os gnomos são como automóveis, meu amigo... só que de uma classe diferente.

1. Escolha o plano de hospedagem;
2. Preencha os seus dados;
3. na página entitulada "Verify Total", coloque DIGITALMINDS no campo "Promo Code";
4. aperte o botão UPDATE para receber o desconto.