Um post rapidinho só pra dar uma notícia importante: a Google está lançando o novo Google Earth 4, que além de inúmeros updates está disponibilizando uma camada de ruas e estradas brasileiras. Vale a pena conferir!
http://earth.google.com/earth4.html
Volto já com a continuação da "Arte". Grande abraço a todos!
Olá todo mundo. Estamos de volta depois de um final de ano chuvoso, marcado pelos excessos gastronômicos e pela total e absoluta imobilidade. Àqueles que conseguiram viajar, meus cumprimentos. A minha viagem vai ficar para o carnaval, não pude viajar desta vez. Acho que a melhor definição dessas "férias" de fim-de-ano foi "uma grande seqüência de sábados, seguida pelo maior domingo de todos os tempos". Mas, quem sou eu para reclamar! Deu pra descansar bastante, curtir um pouco e ganhar a Master League na dificuldade Professional duas vezes.
No nosso último episódio falamos um pouco sobre Views, a letra V do MVC. Pra quem está chegando agora, vale a pena dar uma olhadinha nos artigos anteriores. Hoje vamos falar de modelos. Um assunto muito mais interessante, não? Mas, calmaí. Antes que você se decepcione, não vamos falar de modelos, mas sim de modelos, ok?
Bom, de forma bem simples, o M do MVC é o cara responsável pelo gerenciamento dos dados da aplicação. Toda vez que você precisar ler alguma coisa do banco de dados, ou atualizar alguma informação, você vai utilizar um modelo. A chave para entender os benefícios do MVC é perceber que cada uma das três partes faz um trabalho específico, o que torna tudo no final das contas mais simples e seguro. Na implementação, normalmente se cria uma clase base (normalmente chamada model ou appmodel) que contém quase todas as variáveis e métodos que você precisa para acessar dados no banco. A partir dessa classe, outras classes são criadas, estendendo os métodos para cumprir funcões mais específicas para cada um dos tipos de informação.
A palavra "modelo" talvez seja um pouco difícil de entender. Acho que a tradução foi feita ao pé-da-letra pra manter o acrônimo MVC; mas eu sempre tive dificuldade de entender esse conceito, muito mais do que tive pra entender "View" e "Controller". Pra deixar o conceito mais claro na minha cabeça inventei uma metáfora, talvez ela ajude alguns de vocês. Penso em modelo como um modelo 3d, tipo um robozinho de computação gráfica, responsável por "buscar e levar" os dados até o banco. Assim quando a gente fala que vai criar um modelo para um Post, estamos na verdade construindo um robozinho chamado Post que irá realizar todas as operações com o banco, e guardar informações importantes para nos passar depois. Esse robozinho é criado a partir de um robô genérico, chamado Model, que contém todos os métodos genéricos de todos os robôs. Lembrem que como estamos no mundo da orientação a objeto, podemos criar, na verdade, vários robozinhos Post a partir da classe Post. Esses robôs são instâncias ou objetos da classe Post.
Aliás, pra coisas simples, vocês vão perceber que quase todas as funções ou métodos são muito similares para quase todas as informações. Essa é a beleza dos frameworks MVC como o Rails: só de instalar você já "ganha" uma série de métodos prontos pra usar. Mas essa é uma outra história, que vamos falar um pouco mais tarde.
Muito bem. Quais seriam os modelos que teremos que construir para nossa aplicação funcione? Alguém se arrisca? Vou pelo caminho mais simples, como bom preguiçoso que sou. O primeiro modelo, e mais óbvio, é o modelo de "Post". Sim, amigos, sem posts, não temos um blog. Concordam? Então vamos em frente. Que informações um post deve guardar? Essa é fácil: no mínimo temos que guardar o título do post, seu conteúdo e seu permalink. Pra poder identificar este post de uma forma simples, vamos guardar também uma identificação única, que pode ser um número, por exemplo.
Outro modelo importante pra nosso DBE é o modelo "Comment", que representa um comentário feito em um post. Os comentários vão guardar o conteúdo do comentário e a identificação do post ao qual ele se refere.
Pra nossa primeira versão, que vai ser muito simples, acho que estes dois modelos serão suficientes. O que vocês acham? Ficou faltando alguma coisa? Mandem seus comentários!
Grande abraço e até a próxima.
$ano = 2007;
while ($ano >= 2007){
$felicidade = true;
$paz = true;
$ano = $ano + 1;
}
O leitor Silfar Goulart me fez algumas perguntas por email que prometi responder por aqui. Então vamos lá:
Por que vc escolheu PHP ?
Na verdade, acho que foi PHP que me escolheu. Era uma das poucas opções disponíveis em servidores compartilhados linux. A outra era Perl. Quem conhece Perl gosta bastante, mas sabe que não é uma linguagem muito amigável. Então comecei com PHP.
Por que escrevo esta série em PHP? Bom, porque, como já disse antes, sou preguiçoso e estou muito mais interessado em me aprofundar na parte de design do que em conhecer outras linguagens. Eu realmente acredito que uma aplicação bem desenhada pode ser feita em qualquer linguagem. Dizem que Python é ótima, e eu já andei olhando Ruby e me pareceu muito interessante. Mas como meu tempo é limitado preferi me aprofundar em outras questões que estou achando mais legais no momento.
Agora, por que você vai usar PHP? Bom, primeiro porque ela está disponível em quase todos os servidores compartilhados do mundo. Claro que estas opções estão melhorando a cada dia, cada vez mais provedores estão disponibilizando Ruby e Java, por exemplo. Mas por enquanto, PHP ainda é quase sinônimo de sites dinâmicos no mundo linux.
Segundo, porque é uma linguagem muito gostosa de usar, especialmente simpática para quem está aprendendo. As funções para lidar com arrays são simplesmente maravilhosas, e a versão 5 é bastante esperta, não só em relação a Orientação a Objetos, mas também tem muitas coisas interessantes disponíveis na instalação. Não menos importante é a comunidade de desenvolvedores, muito ativa e prestativa.
Você trabalha mesmo com PHP ?
Sim, trabalho. Não sou um programador full-time, mas eu cuido do desenvolvimento de nossas aplicações server-side aqui na 32Bits™. Não tem nada muito complexo, mas nossas coisas são limpinhas :-)
No Wasabi, quem manda é meu sócio e guru Bruno Goyanna, e aí a coisa é muito mais séria. O Wasabi é todo escrito em Java, com Struts, Velocity, etc e tal. Performance é a palavra chave, e o Bruno é simplesmente "o" cara.
O que acha de python e ruby ?
Conheço muito pouco, mas as duas me parecem muito interessantes, especialmente Ruby. Só fico meio com medo de usar uma linguagem tão nova, sou meio conservador nisso. Quando Ruby estiver há uns 10 anos no mercado aí sim vamos saber se ela é toda essa Coca-cola que andam dizendo.
(UPDATE) O Cris Dias, que além de ser o dono do Vilago é programador Ruby, puxa minha orelha e diz que Ruby nasceu em 1995 também, assim como o PHP. E eu achando que o japa tinha inventado Ruby ano passado. Ignorância minha. É que a linguagem realmente só começou a aparecer por aqui nessa época, mesmo sendo bem forte no Japão. Acho que meu sentimento tem mais a ver com a abundância de recursos na internet disponíveis para PHP. O Cris, faz um artigo aí dando o caminho das pedras pro pessoal!
E sobre os frameworks feitos em python Django e TG ? e em ruby Ruby on Rails ?
Não conheço Django nem TG, mas o Rails é demais. Quem não conhece tem que conhecer, mas acho que é quase impossivel conhecer Ruby sem conhecer Rails, não? Pra quem programa em PHP, o CakePHP é um port muito bom do Rails pra PHP, embora ainda jovem. O que mais me impressiona no Rails é o cuidado com a documentação.
Para ver os artigos anteriores desta série, clique aqui.
Olá todo mundo, escrever nesse calor que está aqui no Rio é quase uma insanidade, mas enquanto houverem leitores a série deve continuar! Hoje vamos começar a detalhar melhor nosso plano falando de uma das partes importantes que compõem o pattern MVC. Mais precisamente, o "V", ou View.
Decidi começar por aí (sei que parece estranho para quem já conhece o funcionamento do MVC) por uma razão bem simples: eu sou preguiçoso, e gosto sempre de começar pelo mais fácil. Na minha modestíssima opinião, o conceito de View é o mais simples dos três, e certamente o mais simples de implementar também.
Quem já trabalhou com algum template engine (como o Smarty, por exemplo), já conhece o conceito de View com outro nome: Template. Basicamente, uma View é um gabarito que permite a visualização de dados dinâmicos dentro de uma determinada formatação. Bom, na verdade é um pouco mais que isso, é também um conjunto de classes que suportam o uso destes templates, afinal se você simplesmente gravar um arquivo com html ele não vai se tornar dinâmico sozinho, não é mesmo?
Uma definição mais careta de View é a seguinte: "uma representação de um estado do modelo". Cuma? Bom, pensei numa metáfora razoavelmente idiota para explicar esse conceito, me perdoem se parecer meio ridículo, mas juro que estou fazendo o melhor que posso :-)
Primeiro, você vai precisar de um caderno, um lápis e um estilete. (?!) É isso mesmo. Vá lá no quarto e pegue um caderno, um lápis e um estilete. Se não tiver um estilete, nosso pseudo template não vai funcionar. Depois você vai entender por quê.
Arranque uma folha do caderno e escreva no topo "Template para criação de Posts". Esse será o nosso template 1. Logo abaixo, escreva "Título do Post:", e embaixo disso, "Texto do Post:". Tudo bem? Bom, você já tem um pseudo template html, mas ainda falta o fundamental, a conexão com o nosso pseudo banco de dados, também conhecido como caderno. O estilete, essa tão importante ferramenta, vai funcionar para fazer a conexão.
Pegue o estilete, e, ao lado do texto "Título do Post", faça um buraco (ou, em nosso pseudo html, um ítem de formulário Input Text) que permita mais ou menos 255 caracteres. Do lado de "Texto do Post:" abra um buraco ainda maior, simulando um TextArea. Eu falei que era uma metáfora meio idiota, não falei?
Muito bem, senhores, vocês têm em suas mãos um Template. Ou uma View, como queiram. Agora podemos usá-la tanto para escrever em nosso "banco de dados" quanto para visualizar seu conteúdo de forma bonita, formatada. Se quiser, você pode editar esse template pintando com hidrocor, sabe como é, dá pra fazer bastante coisa com Hidrocor Style Sheets. OK, deixa pra lá.
Para adicionar um "registro" no "banco de dados" basta "carregar" o seu template, colocando-o sobre uma página vazia do caderno, e escrevendo os dados dentro dos buracos no template. Para adicionar outro registro, vire a página e repita o procedimento. Nesse exemplo, o estado do modelo é a página que você está vendo. Mudar o estado do modelo, portanto, é como mudar de página nesse exemplo tosco. Vocês entenderam?
Claro que um modelo que não é feito de papel pode mudar de estado de outras formas, mudando quais informações estão disponíveis e a forma como elas estão sendo visualizadas. (Ainda preciso ver como fazer sort nesse banco de dados, mas ele possui a grande vantagem de ser portátil, de fácil utilização e ser facilmente expansível "conectando" outros "bancos de dados" quando o espaço acabar. Muito interessante, não? O chato é fazer backup.)
Bom, resumindo, uma View é uma espécie de gabarito que contém partes estáticas (escritas em html, no nosso caso) e outras dinâmicas (escritas em php simplificado, para garantir que não vamos colocar lógica dentro de nossos templates). Claro que os templates que vamos construir são mais poderosos e flexíveis que os feitos em PHTML ou Pseudo Html ou Papel html, sei lá.
Vou dar um exemplo: nosso blog, claro, vai disponibilizar um feed RSS para seus leitores. Usando templates, isso é muito simples: pegamos as mesmas informações que mostramos no blog usando um template bonitinho em html e as mostramos usando um template escrito em XML, no formato Atom, por exemplo. Pra isso funcionar, é só fazer um novo template trocando, por exemplo, a tag "h1" usada no html por uma tag "title", usada no formato Atom. Muito mais fácil do que ficar copiando queries, scripts inteiros, e coisas do gênero.
Em termos práticos, pra nós uma View vai ser um arquivo php que praticamente só contém html. As únicas coisas que estarão escritas em PHP serão os dados que vêm do banco de dados ou algumas funções bem simples para realizar loops, imprimir constantes na tela e pouca coisa mais. Vamos manter nosso DBE bem simples, se depois alguém precisar de mais funcionalidades vamos permitir que se use o Smarty ou qualquer outro template engine pra renderizar nossas Views.
Até a próxima.
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...
Olá todo mundo. Tudo pronto? Cintos de segurança afivelados? Mesinhas fechadas e travadas? Hoje começamos nossa longa jornada com um primeiro passo importante: definir algumas premissas do novo e nada revolucionário Digitalminds Blogging Engine 2.0, o primeiro software open-source para gerenciamento de blogs desenvolvido pela comunidade Digitalminds (o DBE 1.0, como vocês já sabem, é um script todo remendado, feito nas horas vagas, que não tinha código livre por que o autor tem vergonha de mostrar o ninho de rato que a coisa é).
Muito bem, então vamos às premissas:
- cada uma das duas proposições, maior e menor, de um silogismo;
facto ou princípio que serve de base a um raciocínio ou a um estudo
Nossa primeira premissa é que nossas premissas serão as bases do nosso projeto, e que premissas só são alteradas para novas versões. Essa frase ficou um pouco redundante, eu sei, mas vocês vão ver que redundância é uma coisa muito importante quando se trabalha em grupo. Tudo precisa ser muito, muito, mas muito bem explicado para que não haja nenhum problema.
Que fique claro para todos, então, que depois da definição de nossas premissas para a primeira versão do projeto, só poderemos ter novas premissas para uma nova versão. Um dos maiores erros que podemos cometer é mudar de premissas durante o projeto. E, amigos, acreditem, vai ser muito tentador. Muitas vezes em projetos complexos dá muita vontade de mudar o que foi acordado antes, simplesmente por que todos aprendem ao longo do processo e percebem que algumas definições não fazem muito sentido. Mas como diz aquele deputado que não lembro mais o nome, "Versão boa é versão finalizada". É melhor ter um software na mão do que dois voando. Como estamos tentando aprender com o processo, vamos tentar manter a ordem e fechar a primeira versão conforme as premissas originais, ok?
Muito bem, senhores, então quais seriam as outras premissas para o projeto? Tenho algumas idéias que gostaria de sugerir:
- O DBE 2.0 vai rodar necessariamente em ambientes LAMP (Linux, Apache, MySql, PHP). Claro que não será difícil portar o sistema para outras configurações, mas não será nosso objetivo.
- O código será disponibilizado em um repositório Subversion(SVN), e todos poderão atualizá-lo sem restrições. A responsabilidade é sempre deixar a versão do trunk funcionando. Se você não entendeu nada dessa premissa, não se desespere. Vamos explicar diretinho o que é SVN, e dar todas as dicas para usar esse sistema de controle de versão fantástico.
- A versão 2.0 do DBE vai ter apenas o estritamente necessário, do ponto de vista das funcionalidades. Ponto final. Vamos tentar fazer para essa versão apenas o essencial. Se tivermos qualquer dúvida sobre uma funcionalidade, ela fica pra próxima.
- Como simplicidade é a palavra de ordem, não vamos construir nesse momento um sistema de autenticação. Vamos usar a autenticação Digest do Apache, ou mesmo a Basic, caso alguém não seja tão paranóico quanto eu. Trata-se de uma configuração bem simples que pode ser feita em um arquivo .htaccess no seu servidor. A vantagem da Digest é que ela usa criptografia para proteger a sua senha durante o envio. Pra quem não conhece os termos técnicos, autenticação do apache é aquela janelinha que abre em alguns sites pedindo pra você digitar a senha. Nada muito bonito, mas é bem seguro e fácil de implementar.
- A versão 2.0 do DBE vai ser escrita em PHP 5.1.4, usando orientação a objeto. Por quê esta versão? Bom, acho que esta é a primeira versão na qual a programação OOP realmente funciona 100%. Enfim, acho que não vai ser problema pra ninguém, praticamente todos os provedores bons já estão com esta versão, que por sinal tem outros updates importantes na área de segurança.
- Nosso DBE vai ser desenvovido usando modelo simplificado do design pattern mvc. por que usar o pattern mvc? O que é o pattern mvc?
Não perca o próximo capítulo! Só posso dizer que os gnomos estão chegando, amigos, e mais premissas também!
Olá pessoal, depois de mais um longo e tenebroso outono(?!) de muito, muito trabalho estamos de volta. Muito obrigado por todos os comentários e emails, mesmo estando totalmente atolado de trabalho na 32Bits™ eu tento ler todos e respondê-los o mais rapidamente possível. Pra quem tá chegando agora no blog, meu email é danilo[arroba]digitalminds.com.br e você pode ver todos os artigos dessa série clicando no título deste post, ok?
Bom, muitos escreveram perguntando sobre os gnomos. Quando eles vão aparecer nessa tão complexa trama? Qual é sua verdadeira identidade? O máximo que posso dizer é que eles tem contrato para 7 temporadas, e que talvez as respostas ainda demorem um pouco a vir... (funciona pro Lost, não? ;-)
Mas voltando ao que realmente interessa, OOP, ou object-oriented programming, hoje quero preparar o terreno para os próximos episódios. Agora que os conceitos principais já foram apresentados a vocês (se você ainda não sabe o que são classes, subclasses, interfaces, etc, talvez seja bom dar uma olhadinha nos artigos anteriores) gostaria de começar a parte Zen de nossa série. Como nossa marca registrada é gastar metade do artigo falando sobre coisas que são apenas marginalmente relacionadas ao assunto principal, vou tentar explicar o que é Zen em apenas uma palavra, sem nenhum compromisso de conseguir. Vamos lá:
Prática.
Talvez seja mais simples enumerar tudo o que o Zen não é. Zen não significa calma. A frase "Fulaninho é Zen, não se irrita com nada" basicamente não significa nada. Zen não é um conceito esotérico. Zen não é magia, tampouco feitiçaria.
Prática. Contar diariamente de um até dez. Koan. Tornar-se um com o arco. Concentração. Mente de principiante. Buda. E por aí vai.
E o que tudo isso tem a ver com OOP? Bem, caros leitores, a experiência de programação em oop só pode ser totalmente vivida na prática diária. Ler sobre oop é ótimo, mas é como olhar para o dedo que aponta para a Lua, e não olhar a Lua propriamente dita. Como verdadeiramente aprender estes conceitos? Vivendo-os. Como quebrar os Koans das classes, interfaces e patterns?
Recebi alguns emails pedindo que desse exemplos do uso da OOP em situações do dia-a-dia. Muito bem, então vamos começar uma nova etapa dessa série: Digitalminds 2.0.
Já faz tempo que quero refazer o Digitalminds Blogging Engine, que mesmo tendo esse nome bastante pomposo é um script muito furreca, todo remendado, escrito na correria entre trabalhos. Então, vamos nessa? Vamos refazer juntos o DBE, usando os conceitos que falamos, e, ao final do projeto, lançamos o DBE como um produto open source para livre download?
Acho que é uma idéia legal. Tudo bem que já existe o WordPress, etc e tal, mas... se a gente for por aí, TUDO já existe. A idéia é aprender e curtir o processo. Quem se habilita?
Até a próxima. Não percam o próximo artigo, vamos listar nossas premissas para o projeto e quero as opiniões de vocês. 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:
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.
(Para ver todas as partes desta série clique aqui)
Olá pessoal. No último artigo da série a gente construiu carros e falou do conceito mais importante da programação orientada a objetos: herança. Só pra relembrar, o conceito de herança em Object-oriented programming (OOP) é a capacidade de criar uma classe com características próprias que serão transmitidas a todos os objetos criados a partir dela e a possibilidade de estender ou evoluir esta classe criando outras classes filhas, com novas capacidades além das originais.
Falando assim, parece bastante complicado. Mas é pura genética. Você é filho da classe "seu pai" e da classe "sua mãe", portanto tem características similares a eles. No entanto você também é uma classe à parte, pois tem diferentes comportamentos e características em relação a eles. Na verdade muitas linguagens não permitem que um objeto (você, no caso) seja filho de mais de uma classe, pra não complicar as coisas. Assim os objetos em PHP, por exemplo, são sempre filhos de uma única classe (seu pai OU sua mãe, no caso). Estranho? Espere até a gente falar dos gnomos. É aqui que entramos na parte maneira dessa semana. Superpoderes.
Digamos que você seja um ser humano normal, da classe SerHumano:
Class SerHumano {
public $nome;
public $vivo;
public $superpoder;
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 "...";
}
}
}
Bom, como você pode notar, os seres humanos da classe SerHumano não têm lá uma vida muito complicada não. Eles só têm um nome, a propriedade e uma funcão, taVivo(), que serve pra gente saber se o carinha ainda está vivo ou se já partiu desta pra melhor. Que vidão. Mas você percebeu que, assim como na vida real, todos os objetos da classe SerHumano tem o potencial de ter um superpoder. Sim, amigos, a variável $superpoder está lá para mostrar que todos os objetos podem da classe SerHumano podem ter um superpoder, desde que saibamos bem o conceito de Composição em programação orientada a objetos.
Vamos ver como um superpoder pode ser descrito:
abstract class SuperPoder {
abstract function ativar();
}
Vocês lembram da classe Automóvel, abstrata demais pra poder existir como um objeto? A classe superpoder também é assim. Além disso, também definimos a função ativar como sendo abstrata, pra que necessariamente o superpoder defina como ela funciona. Como não dá pra ativar() um superpoder genérico, a gente diz que essa função é abstrata, forçando a definição nas classes que estendem a classe SuperPoder.
Então, na verdade, o que a gente acaba de fazer é criar uma classe para que todos os superpoderes tenham obrigatoriamente a mesma função, ativar, definindo um jeito único de usar todos os superpoderes do mundo. Aí, fica fácil depois um SerHumano ativar() qualquer superpoder, independentemente do que ele faz.
Esse truque também vai nos permitir fazer coisas muito interessantes com diferentes superpoderes, já que todos eles são filhos da mesma classe.
Continuando, vamos para a classe SuperForça:
class SuperForca extends SuperPoder {
function ativar(){
print "Meu deus! Posso levantar um caminhão!";
}
}
Muito bem. Tudo pronto pra gente começar a criar objetos como se não houvesse amanhã. Vamos começar por você, um SerHumano como outro qualquer:
$voce = new SerHumano("Fulano");
$voce->taVivo(); // Sim, eu estou vivo, e meu nome é Fulano!
A função taVivo() confirma que você tá vivo. Muito bem, agora vamos dar a você, meu caro amigo Fulano, um SuperPoder!
$voce->superpoder = new SuperForca();
E pronto! agora você já pode usar seu super poder, já que a variavel $superpoder, que fica dentro do objeto $voce já contém o novo objeto SuperForca:
$voce->superpoder->ativar(); // Meu deus! Posso levantar um caminhão!
Parabéns! Você acaba de conhecer um dos conceitos fundamentais de orientação a objeto: a composição. Algumas vezes vai ser melhor compor diferentes classes para ter maior flexibilidade, como nesse caso, por exemplo.
Explico: se você quisesse agora criar um SuperCao, que não é um SerHumano, claro, seria muito simples. Crie a classe SuperCao já com uma variavel para guardar o SuperPoder e pronto! Se você tivesse definido o superpoder dentro da classe SerHumano o código já começaria a ficar redundante, já que você precisaria definir novamente a função dentro da classe SuperCao.
Tá muito confuso? Não estão gostando? Ou acharam muito bom? Mande seus comentários clicando no link [Comente] aí embaixo. Até a próxima pessoal!
(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.
10 print "Qual e a sua idade?"
20 input i
30 if i > 25 then gosub 100 else gosub 150
40 print "Ate mais. Fui."
40 end
100 rem *** Subrotina 1 ***
110 print "Voce e muito novo! Nao conhece programacao basic!"
120 return
150 rem *** Subrotina 2 ***
160 print "Voce deve ter feito curso de basic..."
170 return
10 Latir
20 Pegar o jornal na porta
30 Trazer o jornal
40 Latir
50 Sentar
60 Deitar
70 Fingir de morto
10 print "*"
20 goto 10
Shares of Apple Computer jumped more than 7% today after the firm unveiled a new program that permits its new line of computers to use the Windows operating system produced by long-time rival Microsoft.
Premonição?Eu tava lá! Foi sensacional... Confira na coluna do Ancelmo Góis, no Globo.
José Serra, neste Museu da Língua Portuguesa, em São Paulo,
foi brincar no painel que junta sílabas quando o visitante o toca e,
na terceira tentativa, apareceu a palavra... governador.