2006-12-04 13:22:49
tags: 

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

Olá a todos. Mais uma vez estamos aqui (excepcionalmente escrevo numa segunda-feira, já que meu fim-de-semana foi totalmente dominado pelo PES6, também conhecido como Winning Eleven 10) pra falar de OOP, ou object-oriented programming. No último post, deixei bastante suspense no ar. O que é o design pattern MVC? Por que usar MVC neste projeto?

Como muitos que nos acompanham já sabem, muitas vezes este esquizofrênico autor acaba fazendo novas perguntas e dando respostas totalmente desvairadas às perguntas feitas anteriormente. Desvairadas no bom sentido, claro - para chegar à essência de qualquer coisa, primeiro temos que entender muito bem suas particularidades; portanto minha resposta à pergunta "O que é o design pattern MVC" vai ter duas etapas (consegui colocar 3 acentos graves em um só parágrafo. Uau.)

Etapa 1: O que é "Design Pattern"?

Design Pattern é o termo utilizado para definir uma prática bem estabelecida em arquitetura de software, uma solução clássica para um problema recorrente. Ou seja: meu amigo, esse problema que você está tendo muito provavelmente alguém muito mais inteligente e com mais disponibilidade de tempo já teve e já resolveu com uma classe, uma beleza que muito provavelmente você não conseguiria. É isso mesmo, o primeiro passo para se tornar um grande desenvolvedor (ou um chutador barato como eu) é aceitar a humildade em seu coração e perceber que as soluções mais bonitas já estão por aí. É só achar. E os design pattern clássicos são pura poesia em forma de código.

"Mas tudo bem, Danilo, eu sou humilde, mas ainda não entendi". Bom, aí, só mostrando na prática, não é mesmo? Então vamos lá, chegou a hora de não explicar o que é MVC.

Etapa 2: O que é "MVC"?

Model, View, Controller. É isso. Entendeu? Olha, se você ainda não entendeu, pode desistir. Não vai adiantar. Invente alguma outra coisa pra fazer, vá mexer no Photoshop, sei lá.

Brincadeirinha. O difícil dessa história de design pattern é compreender a beleza da solução. Só com o uso você pode entender. Eu poderia copiar e colar várias definições sobre o que é MVC, falar sobre toda a teoria, mas, como vocês já sabem, esta não é uma série convencional, e eu estou me propondo a mostrar essas coisas de um ponto de vista mais tosco. Algo como um PHP de rua, se é que vocês me entendem.

Então, pra mostrar ná prática o que é MVC, vou começar listando as coisas que mais me irritavam quando desenvolvia scripts PHP. Aí, se você não entender, realmente vai ser melhor ir fazer gifs animados lá no Photoshop, saca? :-)


- Lógica no meio do desenho da tela

Não existe nada mais desesperador do que lógica no meio do desenho da tela. Digo isso com conhecimento de causa, já que este é um dos piores problemas deste blog que vocês leêm nesse exato momento. É um inferno. Quero trocar o conteúdo de um link, mas ele está no meio de infindáveis ifs (perdoem o trocadilho) e depende de uma outra infinidade de variáveis que não sei mais de onde vieram e pra onde vão. Para criar o RSS feed do blog? Tive que começar do zero, o trabalho de editar o código que já existia nem valia a pena. Um outro exemplo clássico é a versão 2 do OsCommerce, o software open-source de comércio eletrônico. Tentem mudar qualquer coisa ali pra ver. Tem um milhão de condicionais e funções que rodam nas páginas de apresentação de conteúdo, entre um div e um p por exemplo. É coisa pra deixar qualquer um maluco. Um trabalho que poderia levar alguns dias me tomou 3 meses. Eu odeio isso com todas as minhas forças.

- Segurança $_GET e $_POST

Se você usa scripts php diversos para cada uma das páginas do seu site sabe muito bem que cada input do usuário, em cada página, precisa ser validado. Aí, digamos que você tenha 12 páginas php em seu site, e você copia e cola código em todas elas. Ok, agora, imaginemos ainda que 3 variáveis mudaram. Você tem que ir lá e copiar tudo de novo, doze vezes. Os mais espertinhos vão dizer "ah, mas é só fazer um include!", ao que eu respondo "mas, hey, amigo, cada página tem diferenças sutis em relação às outras, os dados comuns têm uma validação diferente de acordo com a situação do usuário e - deus que me livre - de acordo com seus níveis de permissão". Aí, cara, você cai duro, imaginando que aquele orçamento que você deu foi totalmente por água abaixo e que você vai ficar copiando e colando código para toda a eternidade, até que um dia não exista mais PHP no mundo e finalmente você possa descansar em paz.

OBSERVAÇÃO: Claro que dá pra fazer um site ou uma aplicação assim. O que nós estamos falando é de produtividade e capacidade de evolução com o tempo. Todo bom desenvolvedor que conheci é preguiçoso; afinal o computador foi criado pra que nós não tivessemos tanto trabalho, não é mesmo?


- Includes em múltiplos arquivos

Ah, includes. Os includes são uma bênção. Mas quando se tem 30 arquivos php para trabalhar, gerenciar includes se torna uma tarefa muito chata. Uma das soluções que a comunidade desenvolveu ao longo do tempo é o pattern "top.php", um arquivo que é incluído em todas as páginas do site, no topo, que por sua vez inclui outros 30 arquivos necessários ao funcionamento do site. Preciso dizer que tem desperdício de recursos aí? Aquela página que só precisa dos arquivos 1.php e 2.php acaba carregando o 3.php até o 30.php sem precisar. Bons desenvolvedores são higiênicos também; não gostam que tenha sujeira embaixo do tapete.

- SQL misturado com scripts php

Ah, essa é de doer. Já cansei de fazer código que tem SQL misturado, no meio dos scripts PHP. Sim eu era um "lousy coder", um desenvolvedor mixuruca, mas se você olhar tem muito código open source por aí assim. Meu Deus, como eu não via a gravidade desta heresia? Como eu não pude perceber que lugar de SQL não é no script que desenha minha tela? Que sql é coisa muito séria, que deve estar protegido, separado em classes que deixe tudo bem seguro pra que nenhum engraçadinho detone meus dados? Bem, acho que eu realmente não ligava. Mas quando a coisa começou a tirar a minha produtividade, e eu perdia horas procurando "cadê aquela query, acho que deve ser essa aqui" etc e tal a coisa ficou mais clara pra mim. Tinha que haver uma solução melhor pra isso.


Bom, o que posso dizer para vocês é que o pattern MVC resolve estes e muitos outros problemas, e uma vez tendo usado MVC você não vai querer mais voltar para o inferno. Mas tem uma questão: a coisa toda é mais complicada. Fato. Precisa pensar um pouco antes de sair escrevendo código. Precisa planejar. E esse planejamento é precisamente o que vamos começar a fazer no próximo artigo. Até lá.

p.s. o gnomo é o c...