Reflection

Se não precisar, não use Reflection - mesmo sendo quase equivalente a chamar o método diretamente nas JVMs atuais (>= 1.4), o uso excessivo de Reflection indica uma falha no projeto - normalmente você tem a idéia de usar Reflection onde uma simples Interface bastaria.
O caso clássico é criar várias classes com um método com um determinado nome e quantidade de parâmetros, que deve ser chamado usando o nome da classe. Nesse caso Class.forName e implementar uma interface bastam.

Certo cara.
Cara vê se minha teória está certa:
Reflection é uma tecnica que permite buscar campos de um objeto qualquer sem ter conhecimentos
de sua implementação, por exemplo se prescisarmos de um objeto que derive uma função
qualquer passando como parâmetro se o usuário vai querer sua derivada 1ª ou 2ª ele percorre
todos objetos até achar aquele que satisfaz determinada função, na teoria é isso mesmo cara…?

Para chamar um metodo via reflection é só fazer assim

Class clazz = Class.forName("pacote.da.minha.classe.NomeDaMinhaClasse");
Object o = clazz.newInstance();
Method method = clazz.getMethod(methodName, new Class[0]);
method.invoke(o, new Object[0]);// objeto que terá o metodo invocado mais array de parametros

Puppets:

Certo cara.
Cara vê se minha teória está certa…

Por exemplo: suponha que vamos escrever um utilitário que pegue um objeto qualquer e salve em arquivo o valor de cada um dos seus campos. Neste caso é indicado o uso de Reflection, pois ao escrever o código não sabemos quais campos terá o objeto recebido. Em tempo de execução, obtemos a lista de campos do objeto e para cada uma delas o valor pode entao ser recuperado.

Valew gomesrod, com sua explicação fico mais claro.

Uma das utilidades de se usar um construtor através de reflection é a criação de plugins.

Você cria na sua aplicação uma interface, de um serviço que você espera que seja implementado por um plugin de terceiros:

public interface AlgoritmoDeCriptografia { String criptografar(String textoPlano, int chave); String descriptografar(String textoCript, int chave); }

Depois… alguém faz uma implementação dessa algoritmo, numa classe externa. Note que esse alguém é um terceiro, pode nem fazer parte da equipe original de desenvolvimento.

Depois, sua aplicação faz o seguinte:

private String criptografar(String texto, int chave, String nomeDaClasseDoAlgoritmo) {
   Clazz clazz = Class.forName(nomeDaClasseDoAlgoritmo);
   AlgoritmoDeCriptografia umAlgoritmo = (AlgoritmoDeCriptografia) clazz.newInstance();
   return umAlgoritmo.criptografar(texto, chave);
}

private void teste()
{
   criptografar("A vaca foi a vila", 0x1E0A, "guj.com.br.exemplo.TriploDES");
}

O nome da classe do algoritmo pode ter sido gravado num arquivo de configuração (como no eclipse), pode estar num servidor de classes, ou pode ainda ter sido fornecido manualmente pelo usuário, baseado em alguma documentação - como no caso dos bancos de dados no java, onde você tem que especificar o nome do driver manualmente.

Isso também mostra a importância das interfaces. Note que no início você criou a interface que simplesmente é um contrato, dizendo o que você espera do serviço de terceiros, no caso, um algoritmo de criptografia qualquer. Outras pessoas (provavelmente empresas especialistas no assunto), implementam o algoritmo que “preenche” sua interface, da maneira que lhes convier.

Assim sua aplicação se mantém flexível para modificações futuras, mesmo que o .jar final já tenha sido empacotado e enviado para o cliente.