Então, deve fazer um ano e meio que eu não posto (bosto?) aqui. Porém, se você ainda é um sobrevivente, saiba que estou de casa nova: www.objectzilla.com.br.

Te vejo lá.

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido.

O fanzoca do Java é uma pessoa legal (diferentemente do fanzoca do Linux, que é um chato de galochas, porque além de ficar enchendo o saco quando a gente fica usando o Windows na frente dele, ele resolveu parar de tomar banho enquanto a Palmolive não trocar todas as máquinas Windows para Linux) mas seu ufanismo, às vezes, irrita. Principalmente quando faz comparações com C++ e diz que esta é uma linguagem grande e complexa. Não discordo desse fato, porém difamar uma linguagem por ser muito grande é a mesma coisa que difamar a sua avó por ter muitas rugas. Ou você acha que Java não sofrerá as ações do tempo? Imagine como seria Java em 2035? Acredito que deva ser uma coisa muito medonha, com a novíssima classe javax.dirtywork.WebApplication, que promete pela milésima vez acabar com todos os seus problemas, dividindo espaço na JRE com java.util.Date e seus vários construtores e métodos depreciados.

Mas o futuro a Deus pertence, vamos falar de hoje! A versões do Java lançados anteriormente foram o Java 5 em 2004 (9 anos) e Java 6 em 2006 (11 anos). Nesse período, Java era uma criança doce e comportada. Tudo bem que às vezes nos dava nos nervos com suas infantilidades (vide o EJB, o CMP, os Applets, o JDO…), mas no geral era adorável. Mas agora com a chegada da adolescência, Java está testando todos os limites, resolveu que agora é livre e que não é mais dono de ninguém. Tudo bem, faz parte da idade. Mas será que é certo deixá-lo assim tão solto? Não sei, suas amizades não são lá das melhores, como por exemplo o Ruby. O Java vive dizendo que estão numa boa, mas o Ruby, nas costas, fala mal de umas e outras do Java.

O Java, agora, também está achando que pode tudo! Resolveu que num próximo release, vai ter tudo que lhe der na telha. Quer ter closures, quer ter properties, quer até ter XML embutido nele. Vê se pode? Será que ele não percebe, que se depois não gostar, fica difícil voltar atrás! Os pais dele esperam que ele não vá para o mau caminho!

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido.

Já reparou que quem gosta de Java odeia C++? Mesmo os dois tendo uma sintaxe parecida? Pode me encher os ouvidos de argumentos técnicos, mas eu descobri a razão dessa briga há uns meses atrás na Califórnia: Java é Hamlet!Isso mesmo, a história do Java é quase hamletiana, pense bem, o pai – no nosso caso James Gosling – depois de perder a cabeça por causa do C++ pede ao filho Duke Hamlet para vingá-lo, matando a linguagem inimiga.

Até aí fichinha, o problema é que a mãe de Duke Hamlet casou-se com o assassino de seu pai, o C++! Será por isso que o Java, apesar de se mostrar uma evolução do C++, tem uma relação tão promíscua com a sua linguagem mãe? Tipo, a sua sintaxe de chaves, o fallback do switch…

Bom, mas as semelhanças com a obra shakesperiana pára por aí. Java nunca matou C++, não matou nem uma outra linguagem por engano. Se acontecesse de verdade, talvez acabaria morrendo junto…

No final das contas mesmo, o que era alta literatura, degringolou geral. Surgiu o .NET, que parecia uma vilã de novela mexicana (“Eu vou acabar com Maria Afonsina!”), querendo sempre acabar com o reinado do Java. Tudo bem que Java também queria acabar com reinado do .NET, mas sabe como é, né? Java é o lado bonzinho da história, e os bonzinhos podem fazer o que quiser com os vilões. Enfim, o que era história interessante, virou uma outra mais água-com-açúcar.

Quando o Ruby chegou, tentou-se fazer o mesmo conflito C++/Java, porém agora Java/Ruby. Mas não foi dessa vez, porque pra essa história contrataram o Baz Luhrmann pra direção e os atores de High School Musical pra contracenar. Ficou um negócio tão bobinho que até uma criança de 5 anos é capaz de entender!

É, já não se fazem mais conflitos como antigamente…

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido.

Aviso aos navegantes: um raio perto da minha casa queimou o modem do Speedy, o roteador wireless, a placa de rede do meu computador, o meu DVD e, pra finalizar, a geladeira. Por isso fiquei uma semana sem postar. Mas não se preocupe, porque a boa notícia (boa?) é que eu aumentei meu buffer de posts, então vocês receberão novos posts diariamente.

Quanto à Conexão Java, estarei lá. Mas me não espere me ver com todo aquele pseudo-deslumbramento que o pessoal do GUJOrkut tem, pra mim é só um evento como qualquer outro. No mais é só, larga essa leitura enfadonha e vai ver um site de mulher pelada. Tchau e até amanhã.

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido. Mas não se assuste, como esse texto tem alguma coisa de interessante, eu farei uma versão atualizada lá. E só removerei este texto depois de passar o link aqui.

A Edição número 51 de Java Magazine troxe um artigo sobre JavaFX nada excitante, pois mostrou um formzinho bobo, ao invés de um desenho 2D interativo, que eu acredito ser esse seu forte. Mas isso é assunto pra outro post, o mais me irritou no artigo foi a seguinte declaração (tudo bem que se fala de linguagens dinâmicas em geral, mas acerta em cheio o Ruby):

“A utilização de outras linguagens dentro da plataforma Java está se tornando cada vez mais comum, e podemos dizer que se trata de um bom casamento de conveniência. Para o Java, este relacionamento permite unir esforços para tarefas nas quais há uma sinergia forte com uma determinada linguagem (avaliação de regras de negócio, processamento de expressões regulares, clientes web etc.). Já para a outra linguagem, é uma espécie de ‘golpe do baú’: toda a infra-instrutura da plataforma Java – bibliotecas, frameworks, containers, padrões e tudo o mais – vêm de graça.”

O que? Casamento de conveniência? Só se for pro Java! Esse discursinho de sinergia é balela, os caras da Sun trouxe a equipe do jRuby para o seu chapéu porque estavam cagando de medo do Rails ganhar popularidade em aplicações de pequeno e médio porte. Para a Sun, eu vejo a “união” como uma espécie de “vão-se os anéis, ficam-se os dedos”, é como se eles dissessem: “Olham, ex-adeptos do Java que migraram pro Ruby, vocês podem mudar suas preferências de linguagem. Mas que tal usar algo que roda em cima da JVM, hein? Vocês podem ainda usar aquelas APIs Java que vocês estão acostumados quando quiserem!”. Assim, se Java cair de desuso, a JVM estaria firme e forte. E o Ruby não está dando golpe do baú no Java, pois se quiser, pode rodar em cima de Linux, Apache (ou lighttpd) e MySQL. Java EE é algo totalmente opcional.

Bom, mas o que essa linguagem tem de tão especial? Tecnicamente é uma linguagem com tipagem dinâmica, com objetos abertos (dá pra adicionar métodos a uma classe depois que ela foi declarada), totalmente orientado a objetos – sem aquela diferência entre tipos primitivos e objetos, uma aberração que parece existir somente no Java -, e com características muito fortes de meta-programação. Seu framework, o Ruby on Rails (ou Rails) possui coisas revolucionárias em relação ao universo Java, como gerador de código bom (porque no Java não tem, né! Os que existem, são frameworks proprietários geradores de código escroto!), nada de programação em camadas (essa praga!), zero configuração, DRY (não se repita!), utilização correta do protocolo HTTP (requisição GET é pra consulta e requisição POST é pra enviar formulários, alterando o estado do servidor. Sabia disso, JavaServer Faces?) e uso do protocolo REST.

Mas sucesso não se conquista somente no lado técnico. Claro que as linguagens muito feias, como PL/SQL ou Perl, tem tudo pra não conquistar ninguém, mas ser uma linguagem bonita não basta. Muitas linguagens boas morreram por ter uma “fala pequena” com o público (entenderam a piada? fala pequena… small não-sei-do-que…). Até hoje, Java era a única linguagem que eu vi que possui fãs. Há o Linux também. Mas Ruby estrapolou isso, é, além de uma linguagem boa e que possui fãs, uma linguagem “cool”, e por isso mesmo pop. Nela, nada parece sisudo. Nenhuma linguagem diz, em seu site principal que é “o melhor amigo do programador”.

E o seu livro principal? O Agile Web Development with Rails usa uma historinha entre um experiente desenvolvedor e uma cliente pra construir a aplicação em frente aos nossos olhos (repare que a cliente é uma mulher, pois o autor, apesar de nunca revelar o nome, usa sempre “she”. Isso explica o porquê dele ser sempre atencioso…). E tem um livro com cartoons também. No Java, as coisas são mais sisudas, com exceção, é claro, da série Head First (onde tem aquela moreninha gostosa que fica implicando com tudo o ques os autores falam), mas é diferente, tem que ficar explicando no início do livro por que eles são desse jeito e não algo mais sério, como se esperassem que alguém do Java torcesse o nariz. O Ruby, as coisas desencanadas surgem mais naturalmente.

Quer ver? Sabia que existe o Ruby Quiz, onde o pessoal desafia os burros iniciantes na linguagem? E se fazer quebra-cabeças não bastasse, que tal entrar num concurso anual onde você e mais três amigos se juntam pra fazer uma aplicação com Rails em 48 horas de sábado e domingo? Coisa de nerd, né? Não viu nada! Dois geeks fizeram uma série de vídeos comparando Ruby, com PHP, Java, .Net… E uma piada de primeiro de abril indica, Rubyista é um Emo Programmer.

E se quiser algo útil, pode é claro, acessar o RubyForge!

Eu já não sei se toda essa frescura em torno do Ruby é bom ou não, eu não estou nem aí. Gosto do Ruby, e muito mais do Rails, pois foi com esse framework que eu aprendi a programar em web de verdade.

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido. Mas não se assuste, como esse texto tem alguma coisa de interessante, eu farei uma versão atualizada lá. E só removerei este texto depois de passar o link aqui.

No post anterior, comentei sobre a opinião de Bruno Borges dizendo que a especificação é lerdinha. Hoje, irei comentar sobre a opinião de que Craig era o homem errado na especificação do Faces.

É piada corrente (piada?) de que a única coisa que Craig fez de bom foi o Tomcat, o resto (Struts e JSF) foi um lixo. Não é bem assim, temos a mania de olhar as coisas do passado com os olhos do presente e criticar os criadores por não terem uma maldita bola de cristal para saberem o que aconteceria no futuro se fizessem desse ou de outro jeito.

Bruno Borges chamou de “Tríplice Aliança” a referência de um objeto via programação java, página JSP e arquivo XML (Mas o que interessa na verdade é o “meio-de-campo”, ou seja, XML.). Porém, considerando o ano de 2000, quando o Struts surgiu (ao mesmo tempo que o então chamado J2EE surgiu), haveria para os frameworks uma alternativa ao XML?

Havia, é o padrão Template Method: que é um algoritmo implementado numa classe abstrata, parte do framework, e ações de verdade implementados numa classe concreta, parte do aplicativo do usuário. Assim, os usuários escrevem apenas as suas ações, sem se preocupar em como elas seriam conectadas entre si, que é responsabilidade da classe base.

Mas se é uma idéia aparentemente boa, por que o J2EE não a seguiu? Seguiu, até hoje os frameworks seguem esse padrão, porém não mais no seu jeito clássico. Então porque o J2EE não a seguiu do seu jeito clássico? Bem, as primeiras tecnologias em Java eram no Template Method. Lembra do Applet? Quem já não encarou os métodos init() e paint() de uma classe que estendia Applet? Pois é, isso é Template Method implementado de maneira pura, pois havia a classe base que usava esses e outros métodos para prover o suporte ao Applet. As primeiras tecnologias do Enterprise (o Enterprise do Java, Capitão Spock!) tinham um pedaço no XML e mais um pedaço de Template Method, eram assim com Servlet (com doGet() e doPost()) e com o EJB (ejbActivate(), ejbPassivate() e outros).

Nenhuma das três tecnologias “pegou”. O Applet é um fracasso total (e é o único fracasso que o fanático do Java é capaz de admitir), e qualquer um torce o nariz pro EJB ou pra programação puro-Servlet (preferindo usar JSP com “PHP way of coding” ou os frameworks de então, como Struts). Uma das desvantagens de se contar com o Template Method de forma pura é que força nomes artificiais para os métodos. E havia um característica da própria linguagem Java de, por ser uma linguagem imperativa, o programador não dizer o que se faz, mas como se faz. Não há nada de errado nisso, mas certos aspectos ficam prejudicados, por exemplo, se alguém quisesse mexer em alguma configuração, teria, no mínimo, que: obter um container de um singleton, pedir um objeto X desse container, invocar no objeto X um método que altere uma característica da configuração (possivelmente passando um outro objeto) e tratar o retorno e as exceções.

O XML surgui como o salvador da pátria nessa época (lembro da época da faculdade o ufanismo dos javeiros por essa linguagem), era o aspecto de programação declarativa que faltava para o Java: acabou os pequeninos detalhes que o desenvolvedor tinha que resolver, basta escrever uma linha no arquivo XML e tudo será resolvido. Foi assim que a comunidade abraçou o Struts e o Spring, ambos com configuração fortemente baseada em tags. Houve um certo benefício, pois os objetos de usuário ficaram mais limpos, já que parte de sua lógica não estava mais em classes Java. Os desenvolvedores, no início, viam isso como algo bom.

Precisavam configurar A? Coloca A no XML.

Precisavam configurar B? Coloca B no XML.

“Mas puxa, já cheguei a letra Z, o que eu faço?”

Fácil, faz que-nem número, escreva AA, depois AB e assim por diante, se acabar de novo, faz AAA, AAAA e por aí vai.

“Mas eu já cheguei à configuração ZDHUDSALEDOEMWRTJXZQWXSPDFWPDVVBJ!!! E tudo isso em um único arquivo XML!”

Pois é, demorou um tempo pro povo perceber que havia algo errado em se contar tanto com o XML. A W3C imaginou o XML como um documento onde organizações diferentes pudessem enviar dados entre si de maneira estruturada, não como um jeito de configurar as coisas. Não era apenas um repositório de dados, havia lógica dentro das tags que não estava sendo vista pelo compilador Java.

Foi aí que o pessoal se tocou e começou a criar alternativas, como os annotations e novos frameworks baseados nessa “feature”, que trouxe a configuração de maneira declarativa, próxima ao código e aos olhos do compilador.

Essa nova mudança trouxe o Struts para o limbo, qualquer framework web com XML menor era melhor. Mas o mais impressionante não foi o fato do Struts cair do céu para o inferno, foi a rapidez com que isso aconteceu, não durou nem cinco anos! E talvez por isso que povo de Java queira a caveira de Craig McClanaham.

Mas pera lá! O Craig não tinha como fazer previsões, não tinha uma JVM tão boa com reflexão (em termos de desempenho) quanto é hoje, não teve a sua disposição “insights” que só seriam descobertos mais tarde, não tinha as annotations. Ele fez aquilo que era bom para a época. O Struts não é só desvantagem, ele fez com Java para Web virasse sinônimo de MVC, abriu caminho para a era dos frameworks, e levou o J2EE para um caminho que talvez nem a Sun previa.

O povo também não se conforma com o fato de Craig ter entrado na equipe de especificação do JSF: “Errou uma vez! Vai errar de novo!” Não acho, o JSF aprendeu as lições do Struts: possui actions (ou seria managed beans?) sem dependência de container, e, apesar de depender de XML (afinal surgui antes do Java 5), é uma especificação extremamente extensível, sendo possível reimplementar seu esquema de navegação, ampliar seu ciclo de vida, criar novos escopos de beans (muitos fornecem conversation e flash), mudar o renderizador da visão e fornecer componentes visuais de alto nível.

Não acho correto quando as pessoas falam mal de Craig McClanahan, criar um sistema que possa ser usado por décadas sem grandes problemas é extremamente difícil, reservado para alguns poucos gênios. Seria algo que nem os próprios críticos seriam capazes de fazer. Portanto, deixa o cara em paz, Struts não foi o sistema perfeito, mas foi a mão na roda pra muita aplicação web que surgi por aí.

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido. Mas não se assuste, como esse texto tem alguma coisa de interessante, eu farei uma versão atualizada lá. E só removerei este texto depois de passar o link aqui.

Muita gente do Java tira suas dúvidas e responde as dúvidas dos outros no Orkut GUJ, tem gente “estrela” lá, e tem até moderadores que ficam moderando o que possa parecer imoderável. Mas o que muita gente desconfia mas que não ousa falar é que todo mantenedor de fórum A-DO-RA quando ocorre uma discussão inflamada, pois todo o trabalho que eles tiveram para manter o fórum foi recompensado pela briga alheia. Mas é claro, precisa ter uma boa pauta pra começar uma discussão. Não foi o que aconteceu com o The Server Side, onde eles tiveram a idéia mais boboca do mundo: qual é o melhor? Struts ou JSF?

Tinha tudo pra ser mais uma lenga-lenga sem fim até que Bruno Borges apareceu e colocou um post em inglês que se resume a dois tópicos:

1. Craig McClanahan era o homem errado na especificação do JSF, pois trouxe a “tríplice aliança” (configuração em xml, código em Java e expression language) do Struts para o Faces.

2. Especificações perdem velocidade em relação a frameworks fora dos padrões.

Vou inverter e comentar o segundo tópico primeiro. A “velocidade” que o Bruno falou não deve ser considerada uma qualidade mais importante do que todas as demais. Para exemplificar, vamos fazer a seguinte analogia: imagine que um graçom esteja encarregado de servir copos grandes de chope para os clientes de um bar. Nesse copo, estão marcas com as seguintes indicações: 300 ml, 600 ml, 900 ml e 1200 ml, e o cliente pode pedir na medida em que desejar. Então, o que o garçom deveria fazer?

a) encher o copo na marca de 1200 ml e só colocar menos se o cliente explicitamente pedir, ou;

b) encher o copo na marca de 300 ml e só colocar mais se o cliente explicitamente pedir?

Se ele for honesto, ele deve seguir a orientação b; porque existem dois extremos de consumidores, aqueles que bebem pouco e aqueles que são beberrões, e esta opção é o que melhor satisfaz a ambos pois os que bebem pouco não serão obrigados a pagar por aquilo que não querem beber, e os beberrões não vão se importar em ter que dizer que quer bastante.

Agora imagine Java: existem dois extremos de ambientes de software, os conservadores, que precisam criar aplicações que rodem nas organizações por anos sem que haja necessidades de reengenharia, e os “early adopters”, que criam aplicações inovadoras e cujo tempo de vida estará limitado à próxima inovação. Agora eu pergunto: que tipo de servidor de aplicações seria mais adequado para ambos?

a) Um servidor com as últimas novidades em frameworks, ou;

b) Um servidor com apenas as soluções já conhecidas?

Novamente, se quem fez o servidor for honesto, ele escolhe a opção b, pois quem é conservador não é obrigado a instalar junto aquilo que ele achar muito novo (e por conseguinte, muito arriscado), e quem é “early adopter” não iria se importar em colocar módulos extras que estão mais na ponta.
Eu não acho errado a Sun esperar um ano ou dois para colocar idéias desenvolvidas pela comunidade no Java EE, esse é um período onde aqueles frameworks passarão por um “choque de realidade” e terão seus pontos fortes e fracos destrinchados. Assim, os caras de especificação podem decidir entre rejeitar uma idéia que não se mostrou promissora, ou adaptar idéias legais tentando minimizar os pontos fracos dos frameworks não-padrões (e por isso, eu prefiro que a especificação faça uma nova especificação do que simplesmente incorporar os frameworks de sucesso).

Bom, quanto ao seu primeiro tópico, isso é assunto para o meu próximo post.

P.S.: O título é uma homenagem à musica Alcohol do grupo Cansei de Ser Sexy (CSS).

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido.

Tá achando que manjo de Lisp? Neca de Pitibiriba. Minha experiência com essa linguagem se limitou a apenas um dia de aula de Linguagens de Programação com o Professor Zorzo na UFSCar, que no período em que estudei lá (2002 a 2005) significava das 8h00 às 9h30 e das 10h00 às 11h30; além de um trabalhinho não muito complicado.

Lembro apenas que era uma linguagem com muitos parânteses (não que eu ache isso um problema (eu mesmo uso parênteses como um recurso narrativo onde é apresentada uma idéia paralela enquanto eu deixo a outra em suspensão (reparou que tá chovendo muito nesses dias? Não dá nem vontade de subir a serra no fim de semana))) e que tinha um shell próprio (na época pré-Ruby, uma blasfêmia) e era uma linguagem onde fazíamos manipulações de uma lista encadeada fazendo recursão.

Estaria no ostracismo, não fosse o hype atual em torno das linguagens dinâmicas e na percepção atual de que linguagens funcionais escalam muito bem em arquiteturas multinucleares. Tanto é que a InfoQ mostrou uma experiência de uma empresa que fez sua aplicação web com Common Lisp.

E o que é mais interessante, e eu espero que vocês mantenham a seriedade nesse momento, é que a empresa que fez a aplicação web criou um plugin no Eclipse para desenvolver em Lisp, (mantenham-se sérios!) chama-se (olha lá!) Cusp.

MMMMMMMMM… Cusp?

RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ!!!!!

Cuspe! RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ!!!!!

Cuspe! RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ!!!!!

O cara chega lá na monitor do outro e pergunta: “O que é isso?” E o outro: “Cuspe!” RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ!!!!!

Isso que eu chamo de um programa porco! RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ-RÁ!!!!!

Não, desculpa, me descontrolei.

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido. Mas não se assuste, como esse texto tem alguma coisa de interessante, eu farei uma versão atualizada lá. E só removerei este texto depois de passar o link aqui.

Isso já tem mais de um ano, mas em novembro de 2006 o arquiteto da Sun Danny Coward propôs a inclusão de propriedades em seu blog. Para quem está com preguiça de ler, ele sugeriu que a linguagem Java tivesse, ao invés de getters and setters, tivesse a expressão property, ficaria assim:

public property String foo;

E para a leitura de propriedades, seria feita dessa maneira:

a->Foo = b->Foo;

ao invés de:

a.setFoo(b.getFoo()) ;

Isso gerou uma polêmica desgraçada pra muitos javeiros, mas a crítica a ela se dividiu em algumas correntes:

1- Aqueles que acharam que isso seria copiar o .Net com sintaxe do C++. Pra mim, isso é bobagem. Java pode e deve ter influências de outras linguagens, basta, é óbvio, saber escolher aquilo que seja compatível com a filosofia do Java, e saber identificar os pontos fracos das soluções já implementadas. Dizer “isso não foi inventado aqui” não funciona, o Ruby é um exemplo de uma linguagem que não tem vergonha de dizer que se inspirou em outras linguagens, e olha que não é ruim não.

2- Aqueles que identificaram que propriedades não podem ser mapeadas com métodos. E com razão, eu poderia ter facilmente void setMyLink(URL myLink) e void setMyLink(String myLink) em uma mesma classe. Mas como eu mapearia isso para properties (que deve ter um comportamento similar ao de variáveis)? E sem falar que Beans tem um certo problema com coleções, pois não há nada que faça um objeto que possua uma List ter conhecimento da inserção e remoção de elementos desta List e que ao mesmo tempo esse objeto seja reconhecível pelos frameworks que exijem o padrão Bean.

3- Aqueles que acham que isso tiraria a programação explícita do Java. Eu não gosto muito de dogma, e acredito que se possa criar abstrações que facilitem a vida do desenvolvedor. O uso de propriedades poderia tirar deixar um pouco mais implícito, mas também não tornaria a linguagem confusa.

Mas uma coisa ninguém falou, pra quer melhorar os getters e setters se ela está decaindo a cada dia? É isso mesmo que você leu: DE-CA-ÍN-DO. Por várias razões:

1- Estou convencido de que nunca na história desse país, o uso de gettes e setters foi tão criticado. E isso porque uma classe com apenas getters e setters não é muito diferente de uma struct no C-zão. Se você duvida, procura no Google (e no GUJ também) sobre crítica aos getters e setters. Você vai até se deparar com as bibas Paulo Silveira e Philip Shoes, o “Calçado” tendo piti quando escutam que get e set faz com a aplicação fique orientado a objeto. É obvio que isso é mentira! Já participei de dois projetos onde havia um monte de “Bean”, que todo mundo passava a mão, com um monte de “objetos” de “negócio” em volta deles fazendo muita merda. O primeiro, com o objetivo de substituir um legado com problema de manutenção, resultou num programa com problema de manutenção. E o segundo, resultou num programa tão matador que o projeto morreu antes de mostrar seu ROI.

2- Já reparou que o Hibernate pode ser usado com annotations? Já reparou que a JPA é só annotations? Já reparou que existe um container de IoC leve chamado Google Guice que pode ser usado só com annotations? Aquela dependência de getter e setter está caindo cada vez mais. Possivelmente seu uso só servirá para pegar e mudar valores do modelo e jogar na visão (isso se não inventarem outra coisa mais interessante pra fazer isso).

É claro que ainda haverá momentos em que o uso de getters e setters se torna “inevitável” (na verdade, para um desenvolvedor, inevitável significa algo que poderia ser impedido em situações normais, não fosse a preguiça de pensar, mais o chefe que só tá lá porque deu a bunda pro gerente, mais a falta de café e mais o prazo apertado), mas acredito que as situações possíveis vão diminuindo, à medida que vão surgindo alternativas interessantes.

Então resta a dúvida, pra que mexer em algo que já não é tão indispensável assim?

Agora em novo endereço: www.objectzilla.com.br. Atualize-se, este conteúdo será logo removido.

Este sábado instalei o Ubuntu 7.10, depois de uma certa frustração do Ubuntu 7.04 porque não reconhecia o som, nem a placa de rede. Lembro que na versão anterior eu havia conseguido rodar o som, de uma maneira misteriosa que eu nem mesmo sei, o que sei foi que eu fiz um monte de coisa, instalei e desinstalei o Alsa de vários jeitos e num reboot mágico o som apareceu, só a conexão sem fio que não funcionou, o Ndiswrapper não reconhecia os drivers da minha placa de rede. Agora, com essa versão atual, o Ndiswrapper funcionou que é uma beleza, o som não.

E o pior é que eu tive uma certa ilusão quando as propagandas do Ubuntu dizia que a distro procurava os drivers proprietários e sugeria a instalação se houvesse uma conexão à internet disponível (eu tinha, antes da conexão sem fio, havia um fio azul claro atravessando a casa, e que quando alguem tropeçava, derrubava aquele roteador que parece mais leve que o ar), mas achei que ele serviria pro áudio, pro wireless e pra tudo mais. Não, só funcionou pra placa de vídeo NVidea. Ora, apesar de na versão 7.04 não ter nada parecido, eu conseguia instalar esse driver facilmente. Mas o problema com som e placa de rede sem fio está tão problemático de resolver quanto na versão anterior.

Porém, eu gostei da nova versão porque tem o Compiz Fusion, mas é assim, é que-nem trocar XP pelo Vista, nova embalagem com o mesmo conteúdo.

De qualquer maneira, farei o som funcionar, a luta continua!