Maratona4Java2005: Alem do Java™: Novos Horizontes para o Desenvolvedor

From Fragmental Bliki

Introdução

Palestra polêmica sobre o futuro da plataforma Java, com ênfase em novas linguagens para a JVM. Apresentada no Maratona4Java de Brasília. Slides em PDF disponíveis

Comentários Comentados

AOP==Gambiarra?

Boa tarde Phillip.

Desculpe o comentário, mas lendo a apresentação que disponibilizaste sobre o título: "Alem do Java™: Novos horizontes para o  
desenvolvedor" verifiquei que você mencionou que AOP seria uma gambiarra.

Por não ter assistido a tua apresentação, não posso tirar conclusões ou expor a minha colocação. Mas lembro que AOP não 
possui qualquer vinculação direta com linguagens ou tecnologia. O próprio Bruce reconhecesse isto no seu livro: Beyond 
Java™.

Alessandro Leite

Oi, Alessandro,

Esses slides sem apresentação ficam confusos mesmo, mas antes de mais nada, apesar do título, eu concordo em parte com o Bruce Tate, mas não no todo, de qualquer modo Bruce em seu livro usa AOP de uma maneira parecida como a apresentada na palestra.

AOP em si é excelente, está ajudando muito em diversos aspectos da Programação e projeto Orientado a Objetos, mas muitas e muitas vezes têm-se utilizado AOP em java para simplesmente vencer dificuldades da falta de dinamismo da linguagem. Mixins são um exemplo disso.

A lsita de gambiarras inclui também XML. XML não é algo ruim, mas o uso que se têm feito dela é extremamente inapropriado.

Na minha visão de Além do java existe lugar para AOP e XML, mas não exatamente como usamos hoje. Esse é o ponto ;)

Não somente a AOP, mas também a linguagem Java™. Muitos dos problemas relacionados ao aumento da complexidade do  
desenvolvimento de software utilizando a plataforma Java™, tem relação direta com o desenvolvedor, que utiliza os seus 
conhecimentos, às vezes não muito, para inserir códigos não muito compreensíveis, pois se criou uma cultura de que código de 
difícil compreensão é sinônimo de conhecimento. Por isso gosto da frase do Martin Fowler, "É fácil escrever um código que um 
compilador entenda. Difícil é escrever código que um humano entenda". Tenho constatado isto, observando aplicações que fazem 
uso abusivo de XML, onde até mesmo um arquivo texto puro seria o ideal, utilização desnecessária dos padrões de software, o 
próprio Bruce cita essa característica no seu livro, no ponto onde relata a proliferação de frameworks voltados à 
implementação do design pattern MVC no contexto da WEB. Com AOP não tenho observado esse comportamento, haja vista, que a 
sua adoção ainda não está tão avançada quanto na parte acadêmica.
  A abordagem de separação de interesses Mixins não é AOP.  
[]'s
Alessandro Leite

Oi,

O problema é que a presença de um tipo único de ferramenta (i.e. Java) para toda e qualquer função faz com que mesmo programadores experientes ou que sabem o que estão fazendo tenham que recorrer a meios não ótimos para contornar dificuldades que poderiam ser melhor endereçadas com outras ferramentas.

Produtos bons como Spring, Hibernate e EJB3 sofrem por isso.

na verdade o ponto do mixin é exatamente um exemplo. Ruby não precisa de AOP para mixins, com Java você não tem muita escolha.

[]s