Vitor Pamplona

Innovation on Vision: Imaging , Enhancement and Simulation

É Tudo Questão de Interface

Uma interface é um conjunto definido de entradas e saídas que rege a comunicação entre duas entidades. A Sun é péssima com interfaces, e ela foi capaz de contagiar toda uma comunidade. Deixando de lado o horrível LookAndFeel do java (Vide: Netbeans é feio) e os componentes simplistas do Swing; as classes do SDK java e de muitas bibliotecas independentes são péssimas no quesito interface. E olha que nem estou falando em interfaces gráficas.

 O mundo java é famoso pelo estilo arquitetural de suas soluções: modularizáveis, extensíveis, acopláveis, generalistas e... burocráticas. JFreeReport e Prefuse são exemplos perfeitos deste estilo. A forte preocupação com a orientação a objetos e com design patterns desvia a atenção dos programadores da interface, deixando-a em segundo plano, se houver tempo para um segundo plano.

Para usar o Prefuse, por exemplo, você precisa conhecer, em detalhes, TODAS as classes do framework e como se integram. Em um exemplo simples, você é obrigado a acoplar o seu programa a cinco ou seis classes, modificar a sua estrutura de dados e abrir o código em busca da fonte das diversas mensagens de erro que, atualmente, poderiam ser geradas automaticamente por um gerador de lero-lero. A interface é ridícula.

O brazilian-rails é o contra exemplo. Uma interface simples, métodos intuitivos e baixa acoplagem. Não é necessário instanciar classes, se infiltrar no modelo MVC e você faz muito com pouco código. Quem baixa uma biblioteca tem mais o que se preocupar do que conhecer as classes, subclasses e o método de trabalho da mesma.

No mundo java, quem nunca se atrapalhou com as classes Date e Calendar? E que tal o BigDecimal? Por que a classe Number não tem um método porExtenso? Vejam que são classes que deveriam ser simples e fáceis. Alguém já tentou carregar uma imagem no formato tga, exr, hdr no Java? Nem tente. Para rotacionar qualquer imagem em C, usando a biblioteca de baixo nível DevIL, existe um método rotate. No java, existem quase 100 linhas envolvendo 6 classes diferentes que precisam ser reprogramadas a cada chamada de rotate e, claro, você precisa saber onde e como usar estas classes para o seu programa não ficar lento. Até hoje, discutem-se maneiras práticas de criar interfaces swing em java e receio que ainda estão longe de algo interessante e prático como o Delphi.

A comunidade C + +, conhecida por sua ênfase muitas vezes excessiva em performance também tem seus problemas. Muitas bibliotecas com entradas e saídas em baixo nível, muitas máquinas de estados e enumerações públicas, muitas funções com parâmetros replicados, incompreensíveis e fora de contexto. No entanto, a integração delas ao seu código é quase sempre simples: chamadas de funções normalmente estáticas. E não há nada de errado nisso.

Mesmo com todo o baixo nível, problemas de linkedição e máquinas de estado escrotas, eu prefiro as bibliotecas do C + +. Primeiro porque normalmente estão bem otimizadas, coisa que nem sempre se vê no java. Segundo porque não me incomodam. Não preciso decorar classes, métodos, criar e destruir objetos de controle, criar singletons e integrar com o Spring. Seja o que for, basta uma chamada de função encontrada em qualquer exemplo na web.

Pela própria cultura de manter a portabilidade, o desenvolvedor Java se mantém psicologicamente preso a tecnologia. Dificilmente vejo alguém do java usar uma DLL ou importar algo de outra linguagem fora da JVM por livre opção. Como se as outras linguagens não fossem portáveis. Quando isso acontece, o desenvolvedor Java frequentemente tenta criar uma estrutura OO a partir de métodos portados. Vícios de cultura.

Já em C + +, os desenvolvedores adoram ports. Principalmente de FORTRAN. É.. O bom e velho Fortran ainda é campeão de performance em manipulação matricial / algébrica e em algumas outras coisas. Quem já usou a Lapack sabe do que eu estou falando. A linguagem Cuda da nVídia nasceu com port para C + +. Quantos anos iremos esperar para ver um port de Cuda para Java? Eu gostaria de ter, por exemplo, uma GLUT feito em Java: Extremamente leve, simples e sem a parafernalha do Swing. Excelente para prototipagem de OpenGL. Mas acho que isso nunca vai acontecer. Pelo menos não em um port leve.

Sabem, criar bibliotecas é como criar serviços web. Quanto menor o tráfego, menor o número de interfaces e mais baixa a acoplagem, mais seguro, rápido e fácil será a implementação de   um cliente. Não importa como a estrutura interna da biblioteca funcione. Importa que o desenvolvedor deve chamar o método findX se quiser encontrar o X e saveX se quiser salvá-lo.

Essa semana no JavaFree, tivemos uma discussão interessante. A idéia era comparar a HQL e a Criteria do Hibernate com a SQL. A Criteria é um outro bom exemplo da cultura burocrática do Java. Alguém achou que a solução de HQL / SQL não era OO o suficiente, então encontrou uma maneira chata, confusa, lenta e extremamente limitada de criar uma SQL através de objetos e chamadas de métodos. Se pelo menos a criteria conseguisse compilar a HQL, garantindo que nomes de campos / atributos e tabelas / classes estejam corretos, mas não. Não há nada que substitui uma boa DSL.

É tudo questão de interface.

Posted in Jan 26, 2009 by Vitor Pamplona - Edit - History

Showing Comments

Sabe que você está criando uma grande encrenca com a grande maioria dos javaneses, não é?

Mas concordo com você. Chega um ponto que a busca excessiva pela " beleza " do código extrapola algumas regras de bom senso. Já vi um cara que, pra não fazer um IF no código criou um esquema com classes e mapas exagerado. Resultado: Um cara foi dar manutenção e demorou 1 dia pra descobrir que aquilo era um IF....

Post o link para esse post no DFJUG ou em algum outro grupo Java. Vai dar uma boa discussão.

Demonio de Maxwell
demoniodemaxwell.wordpress.com

- - Demônio de Maxwell

- - Posted in Jan 27, 2009 by 201.22.135.198

Java é burocrático. As APIs de Java são burocráticas.

Choveu no molhado.

- - Posted in Feb 7, 2009 by 189.70.41.20

Olá Vitor Pamplona,

Gostaria de saber se vc se interessa sobre o seguinte Tema: Engenharia de Semiótica - IHC (Interação Humano Computador) "?
Estou desenvolvendo o meu TCC com este tema mais especificamente (End User Development-Desenvolvimento por Usuário Final). Só que ainda encontro muitos barreiras qnto a pesquisa.
Se vc se interessar por favor responda este comment.
Vlws


- - Andre Thyago

- - Posted in Apr 9, 2010 by 200.140.40.97

Add New Comment

Your Name:


Write the code showed above on the text below.