Um dos argumentos de quem gosta de linguagens estaticamente tipadas é a ajuda fornecida pelo compilador no momento da escrita de código. Erros como invocação de métodos que não existem e assinatura errada são facilmente evitados. O mesmo não é encontrado nas linguagens mais dinâmicas, como Ruby, onde os testes de unidade podem trazer essa garantia. Entretanto, a dinamicidade dessas linguagens permite que escrevamos códigos que não são possiveis nas estaticamente tipadas, como Java.

Por exemplo, uma feature muito utilizada pelos códigos escritos em Ruby é o method missing. Talvez apareça até em excesso em alguns projetos,  sendo o caso mais conhecido o próprio Rails, principalmente para escrever DSLs.  Um desses usos é poder buscar por todas as propriedades das classes de modelo. Normalmente teríamos que criar métodos como buscaPorNome, buscaPorEmail ou combinações destes para atingir esse objetivo. Só que no framework ganhamos métodos prontos como Pessoa.findByNome ou Pessoa.findByEmail. O ponto é que esses métodos não existem na classe, mas o Rails permite que a invocação seja realizada e, caso o método não exista, será invocado o method_missing(nomeDoMetodoInvocado,argumentosPassados) . Dessa forma conseguimos ganhar esses comportamentos já prontos.

Scala, a partir da versão 2.9, possui um recurso com o mesmo objetivo do method_missing. Para exemplificar vamos utilizar uma agenda de contatos. Queremos que nossa agenda seja capaz de buscar contatos através de algumas propriedades da nossa classe. Uma implementação inicial seria como a que segue:

   class AgendaPadrao {
     def findByNome(nome:String) = {
       // implementacao padrao
     }

     def findByEmail(email:String) = {
       // implementacao padrao
     }

   }

Aqui caímos no problema mencionado acima, caso queiramos adicionar novas buscas precisamos adicionar novos métodos. Uma outra possibilidade seria recorrer ao paradigma funcional, para receber o critério de busca como parâmetro, já que o Scala também suporta essa abordagem. Porém, a ideia é tentar resolver da mesma forma que o Rails, queremos dar a possibilidade de alguém conseguir invocar na nossa agenda métodos como: findByNome, findByEmail ou qualquer outra. O primeiro passo a fazer é herdar de uma trait chamada Dynamic. É uma trait apenas de marcação, assim como Serializable no Java. Em seguida implementamos um método applyDynamic. O código é o que segue:

   class Agenda extends Dynamic {
       def applyDynamic(fakeMethodName: String)(args: Any*) = {
           "metodo %s com parametros %s".format(fakeMethodName,args)
       }
   }

Agora já podemos chamar qualquer método na nossa classe, existindo ou não. Vamos realizar a implementação usando o padrão findByPropriedade. Vamos usar um pouco de expressões regulares para conseguir identificar a propriedade que está sendo usada para realizar a busca. Também precisaremos de reflection para invocar o método que retorna o valor da propriedade na nossa classe:

   class Agenda extends Dynamic {
       def applyDynamic(fakeMethodName: String)(args: Any*) = {
          val FindBy = """(findBy)(\w+)""".r
          val found = fakeMethodName match {
              case Like(_, property) => {
               val realMethodName = lowerFirstLetter(property)
               contatos.filter(c => invokeMethod[String](c,realMethodNAme).(c,realMethodName).startsWith(args(0).toString))
              }
          }
          found
      }
   }

Ainda podemos evoluir nossa implementação de method missing para suportar mais buscas. O exemplo completo do código pode ser encontrado aqui. Usamos uma implementação baseada em listas, mas a mesma poderia ser levada para dentro de um DAO permitindo buscas diretamente no banco de dados. Importante notar que precisamos tratar o caso que nenhum padrão for encontrado, para dar feedback para quem fez a invocação informando que aquele método não existe. Nesse caso lançamos uma exception. Um outro ponto a ser observado é a perda da checagem em tempo de compilação, agora só descobrimos que um método não existe quando rodamos o programa, explicitando mais ainda a importância dos testes de unidade.

E vocês, o que acham dessa feature? O que acham dessa aproximação do estaticamente tipado ao dinâmico?

O Mirror é um projeto que tem por objetivo facilitar o uso da Java Reflection API, removendo boa parte da burocracia (como as diversas checked exceptions que são lançadas) e utilizando uma DSL para melhorar a legibilidade do código.

Com essa remoção de burocracia e a DSL, é possível transformar o seguinte código:

Field toSet = null;
for (Field f : target.getClass().getDeclaredFields()) {
    if (f.getName().equals("field")) {
        toSet = f;
    }
}
if (toSet != null && ((toSet.getModifiers() & Modifier.STATIC) == 0)
        && ((toSet.getModifiers() & Modifier.FINAL) == 0)) {
    toSet.setAccessible(true);
    toSet.set(target, value);
}

em algo mais legível e expressivo:

Mirror.on(target).set().field("fieldName").withValue(value);

Atualmente o Mirror possui suporte para lidar com as operações reflectivas mais comuns (como instanciar objetos, invocar métodos, ler ou escrever atributos, etc). Ele foi desenvolvido por Adriano Almeida, Diego Feitosa e eu, todos consultores/instrutores aqui da Caelum, enquanto enfretavamos problemas comuns no dia a dia.

Esperamos que possa ser útil para vocês também!

Depois de aprender bem o Java, uma pergunta comum de alunos e de usuários do GUJ é: como adquirir experiência e boas práticas? Com esse intuito criamos um novo treinamento, onde desenvolvemos uma aplicação desktop com Swing, que faz análise técnica da bolsa de valores, através de gráficos, usando como fonte uma base XML. É o FJ-16: Laboratório Java com Swing, XML e Testes.

O mais interessante é que, durante o desenvolvimento da aplicação, aprendemos a aplicar diversos design patterns (como o Decorator entre indicadores), utilizamos testes unitários com JUnit, conhecemos as ferramentas Ant e Maven, aplicamos reflection e anotações, além de sempre estar refatorando o código inúmeras vezes.

Nesse treinamento, são colocados em prática também diversos conceitos da linguagem que usamos no dia-a-dia, como manipulação de datas, de XML, classes anônimas, classes internas, uso do log4J, entre outros.

Veja a ementa completa na página do treinamento. Temos turmas agendadas para final de agosto e começo de setembro. Entre em contato conosco para mais informações.

Eu já havia postado sobre isso quando falei de reificação de tipos parametrizados, mas de uma maneira mais geral.

A questão básica é a seguinte: Se eu tenho um tipo genérico, que recebe um tipo parametrizado T como argumento, eu posso instanciar T de alguma forma?

Quem sabe tentar assim:

class Dao<T> {
  public T cria() {
    return new T();
  }
}

Essa forma não funciona. Você não tem garantias sobre os construtores que o tipo T possui. E então se tentarmos assim:

class Dao<T> {
  public T cria() {
    return T.class.newInstance();
  }
}

Aqui a sintaxe até poderia ser possível, mas infelizmente o java não sabe quem é T nem mesmo em tempo de execução. Nem mesmo com manipulação de bytecode ou qualquer outro recurso. Isso porque o compilador “apaga” essa informação depois de utilizada: é a tal da mal falada erasure.

Qual seria a vantagem da erasure?

Antes de mais nada: erasure não serve para poder rodar código do Java 5 em VMs Java 1.4 ou menor! Não é esse o objetivo.

Quando a JSR14 do generics foi proposta, eles queriam mais que compatibilidade para trás em relação a compilação, eles queriam também a possibilidade de migrar o código antigo para poder usar código novo: uma ArrayList precisa poder ser passada como argumento para alguém que receba List<QualquerClasse> como argumento!

Para ilustrar a situação, imagine que eu tenho uma aplicação grande X que usasse a classe ArrayList em muitos lugares (como a grande maioria das aplicações). Essa aplicação X usa a biblioteca B, que recebe List como argumento em muitos de seus métodos. Se um dia a bibioteca B passasse a usar List genérica, gostaríamos que a aplicação X atualizasse B sem maiores problemas: sem precisar recompilar nada, nem trocar nada no código fonte. O Neal Gafter escreveu muito sobre isso pouco antes da release do Java 5, dada as inúmeras críticas que eles estavam recebendo.

Se o Java tivesse optado por outra maneira de implementar generics, teria ou quebrado compatibilidade com o uso não genérico de classes que viraram genéricas, ou precisaria criar classes paralelas as atuais, praticamente copiadas e coladas, só que estas genéricas, tornando as antigas deprecated ou legadas.

Como o .NET resolveu o mesmo problema?

O .NET seguiu essa segunda forma, e criou uma hierarquia quase que paralela de coleções dentro do name space System.Collections.Generic.

A IList é a interface que define as operações em uma lista não genérica, e a ArrayList é sua implementação mais comumente usada. Quando entrou generics no .NET eles criaram uma outra interface para a lista, com mesmo nome, só que genérica: a IList<T>.

A classe List já é a implementação da interface genérica, e é ela quem você vai usar em vez de ArrayList. Ela possui uma definição bem estranha:

public class List : IList, ICollection, IEnumerable, IList, ICollection, IEnumerable

Ela implementa tanto a lista genérica como a não genérica. O .NET tem um recurso que nós não temos, que faz com que apesar dessa lista também implementar a interface não genérica, você só consegue invocar os métodos não genéricos (que trabalham com Object) se estiver se referenciando a ela explicitamente como uma lista não genérica, como o código abaixo:

IList x = new List<String>();
x.Add(2);

Apesar desse código compilar, no .NET temos essa informação dos tipos genéricos em tempo de execução, o que fará gerar uma exceção:

System.ArgumentException: The value "2" is not of type "System.String" e cannot be used in this generic collection


No Java teríamos apenas um unchecked warning na linha da declaração da referência, e uma possível ClassCastException mais a frente no código.

Aqui a vantagem é você poder passar uma List genérica para um código .NET antigo, que recebe como argumento uma IList não genérica. Além disso, no .NET você pode sim descobrir quem é T em tempo de execução:

class ClasseGenerica<T> {
  void metodo() {  Console.WriteLine(typeof(T)); }
}

Em resumo: o sistema de generics do .NET é realmente seguro, não temos como burlá-lo através de unchecked casts, como ocorre em Java. O Java novamente sacrificou alguns recursos interessantes em favor a compatibilidade de versões e interoperabilidade entre classes genéricas e as não genéricas já existentes. Cada um com sua vantagem. Como citei no outro artigo, existem algumas idéias de dar suporte a tipos genéricos reificados no Java, ao mesmo tempo que outros ficariam ainda com a erasure, sendo que você pode escolher qual o que te agrada para aquela classe genérica em particular. Talvez ter as duas opções adicione ainda mais complexidade a tipagem genérica do Java, mas eu particularmente gosto da idéia.

Mais uma vez um post que era para ser sucinto ficou longo. Agradeço ao Rafael Steil e Rodrigo Kumpera pela colaboração, e ao Lucas Cavalcanti e Guilherme Moreira pedindo para que fosse elaborado um post mais completo sobre esse assunto tão pertinente.