Desde que escrevi esse artigo, aprendi muito sobre programação orientada a objetos. Sugiro que não use esse post como referência. Se desejar, “JavaScript Orientado a Objetos” é uma fonte mais correta e atualizada sobre POO.

Eu sei que PHP é um tanto fora do contexto do blog, mas pra quem tiver a fim, fica aí a dica. E os conceitos servem também pra JavaScript Orientado a Objeto.

Que diabos é Programação Orientada a Objeto?

A Orientação a Objetos é uma maneira de programar que modela os processos de programação de uma maneira próxima a realidade, tratando cada componente de uma aplicação (script) como um objeto, com suas características e funcionalidades.

Nada impede que se programe dessa maneira na versão 4 do PHP, mas a versão 5 reescreveu o tratamento de objetos, permitindo mais recursos, performance e vantagens no uso deste tipo de programação.

Classes e Objetos

Classe é a estrutura fundamental para a criação de um objeto. Uma classe é um conjunto organizado de variáveis (propriedades ou atributos) e métodos (funções), que será utilizada como um novo tipo e instanciará um objeto. Uma classe tem por objetivo criar um objeto, que é uma representação desta classe em uma variável.

Vamos utilizar a seguinte classe:

<?php
// Classe dog
class dog {
	public $nome;
	public $humor;
	function setNome( $nome )
	{
		$this->nome = $nome;
	}
	function setHumor( $humor )
	{
		$this->humor = $humor;
	}
	function falar()
	{
		echo $this->nome . ' está ' . $this->humor . ' e disse: AUAU!';
	}
}
?>

Aí criamos uma classe que instanciará um objeto, no nosso caso, um cachorro. Ela tem duas propriedades ($nome e $humor), e três métodos (setNome($nome), setHumor($humor) e falar()). Agora, criando um objeto a partir dessa classe, vamos ver o que podemos fazer com ela:

$cachorro = new dog; // Instanciamos o objeto "cachorro"
$cachorro->setNome( "Rex" ); // Setamos $cachorro->nome;
$cachorro->setHumor( "feliz" ); // Setamos $cachorro->humor;
$cachorro->falar(); // Chamamos o método $cachorro->falar();

Como você deve ter visto, instanciamos um objeto utilizando o operador new. Para utilizarmos as propriedades e métodos da classe, devemos utilizar o operador ->, como vimos acima.

A variável $this

Na definição da classe, podemos usar a variável $this, que é o próprio objeto. Quando uma classe é instanciada em um objeto, e utilizamos a variável $this, essa variável se refere ao objeto que estamos utilizando.

Herança

Herança é uma forma de reutilização de código em que novas classes são criadas a partir de classes já existentes, herdando atributos e métodos, e incluindo outros que sejam de necessidade. Vamos extender nossa classe dog, suportando também raças.

class raca extends dog
{
	public $raca;
	function setRaca( $raca )
	{
		$this->raca = $raca;
	}
	function falar()
	{
		echo $this->nome . ' é da raça ' . $this->raca . ' e disse: AUAU!';
	}
}

A classe raca, acima, herdou todas as propriedades e métodos da sua classe pai, dog. Além disso, foi adicionado um método setRaca($raca), e o método falar() foi modificado. Usando sub-classes, é possível redefinir métodos e propriedades, e acrescentar outros, dependendo das necessidades.

Espero que tenha dado uma boa base. Logo entraremos em JavaScript também…

Atenção: esse script está ultrapassado e pode conter bugs. Ele não recebe mais suporte e atualização. Use por sua conta e risco.

O JGQueryString é um objeto que desenvolvi para tornar o JavaScript capaz de ler Query Strings, aquelas informações passadas junto com a URL, depois do “?”. Ele permite acessar os valores das variáveis enviadas pelo método HTTP GET.

Métodos

• getVar(varName) – Retorna o valor da variável varName.
• getVars() – Retorna um array contendo todas as variáveis enviadas.

Exemplo de Uso:

JGQueryString.getVar("firstName");
JGQueryString.getVars()["variavel"];
var httpGetVar = JGQueryString.getVars();
alert(httpGetVar["variavel"]);

E a URL da página deve conter a query string: http://url/da/pagina.htm?variavel=valor&outravar=outrovalor

Testada em IE 6 e Firefox 1.5. Quem puder testar em outros browsers, ou detectar algum bug, me avise.

Essa técnica não é das mais difíceis, nem das mais extensas. Explicarei elas pra quem está começando com Ajax, mas também é útil para POO (mas de outra maneira).

Às vezes pode ser necessário importar uma função personalizada de um script server-side, criada dinamicamente, na hora, para satisfazer um requisito qualquer. Não interessa muito qual o propósito de uma função deste tipo, ela pode ser usada para muitas coisas.

var funcao = 'function test(texto) { alert(texto); }';
eval( '(' + funcao + ')' );

Se você já tentou o código acima (ou algo parecido, quis tirar a parte dos requests pra diminuir o tamanho do texto), não deve ter tido grande sucesso. Isso porque você não gravou esta função, você apenas escreveu ela e depois ela foi “apagada”. Precisamos registrar a função para poder usa-la. Veja:

var funcao = 'func = function (texto) { alert(texto); }';
eval( '(' + funcao + ')' );

Tente isso. Você provavelmente obterá sucesso. A função que desejamos foi registrada (através de sua compilação com eval, como no código mais acima) como “func”. Fácil, não?

Mas não há motivo algum pra fazer isso. Poderíamos ter registrado a função diretamente, como sempre fazemos, certo? CERTO (pensou que eu ia dizer que não, né?), já que não estaríamos usando uma string como função. Esse exemplo é para ser usado com Ajax (onde “funcao” é o responseText).

E se eu quiser registrar uma função de forma diferente, sem Ajax? Da mesma maneira, mas sem precisar compila-la:

var func = function (texto) { alert(texto); };

E usamos normalmente. Mais um exemplo, agora com JSON:

var busca =
	{
	completa: function(texto) { ...busca... },
	simples: function(texto) { ...busca... }
	}

E usando-a:

busca.completa("Texto");
busca.simples("Texto");

metodo.Simples() não? Basta aprender a usar direitinho.

Já que falei sobre o DIVless, vamos passar a algo mais semântico: Tableless. O termo tableless, literalmente, significa “sem tabelas”. Por esse motivo esse termo tem causado uma grande confusão entre os iniciantes no tema.

Pra quem conhece, Tableless significa criar um site seguindo os padrões, com código semântico, preferencialmente estrito, e não banir totalmente o uso da tag <table>, como quem está entrando no tema pensa. Alguns se gabam de conseguir mostrar dados tabulares usando apenas DIVs. Isso é o equivalente a criar um site usando tabelas.

Em minha opinião, um site Tableless é feito seguindo os padrões (ou deveria). O termo tableless é polêmico (vide Tableless tem que morrer), e é apenas um nome. Lá fora o termo usado para definir um site que segue os padrões é “CSS Layout”. E poderia ser qualquer outro. O nome não interessa, o que interessa é como o site é feito. WebStandards são necessários para a criação da Web 2.0, e nesse bolo também entra a semântica.

Tableless, no sentido que costumamos usar, é seguir os padrões, e não banir o uso de tabelas. Pense nisso, lembre-se disso.

Alguns ainda não consideram que um site Tableless segue os padrões (mas pode seguir sim, sem nenhum problema). No Tableless e no Revolução Etc tem dois posts interessantes sobre o assunto: Tableless vs. WebStandards.

Baseando-se nisso, praticamente excluí Tableless do meu vocabulário. Costumo usar “Site Semântico”, ou coisas assim. O termo em questão está aberto a muitas interpretações diferentes. Novamente digo: o nome não interesa. O que interessa é o que o conceito quer dizer.

Andei lendo no Tableless e no Revolução Etc sobre DIVless. Não vi maiores detalhes do assunto (a não ser no site do criador da idéia), então resolvi esclarecer as coisas pro pessoal.

O que é?

Basicamente (e literalmente), DIVless é a ausência de DIVs. Todas as DIVs são trocadas por listas não ordenadas e listas de definição.

Por quê?

Segundo o autor do DIVless, as listas tem um sentido inerente mais hierárquico e sintático. Em outras palavras, a hierarquia do site se apresentaria melhor, com ou sem o uso de CSS ou no código.

O autor também afirma, com ajuda do W3Schools, que as listas como elementos de layout seguem os padrões semânticos.

Também é apontada a falta de significado da tag DIV em browsers antigos, e ela também não apresenta estrutura hierárquica e visual em browsers que não usam CSS. Isso realmente é verdade. E tudo testado em IE 6 e 5.5, Firefox e Safari.

E a Semântica?

Em minha humilde opinião, a semântica vai por água abaixo. O que vale é a palavra do W3C, e não qualquer outra. Layouts são controlados por DIVs, e não listas.

Lembra-se quando ainda usávamos tabelas para posicionar elementos? DIVless é tão semântico quanto isso. Realmente a tag DIV não tem nenhum valor semântico, mas podemos adiciona-lo através dos atributos class e id.

A técnica do DIVless realmente foi bem bolada, todos os argumentos do autor são verdadeiros (exceto a questão semântica). Visitei a página sem suporte a CSS e apareceu bem melhor do que com DIVs. Isso é indiscutível. Mas e a semântica? Realmente é uma questão delicada.

Em minha opinião, DIVless não terá muito futuro, pelo menos até que o futuro chegue.