Implementei o retorno de chamada / delegar suporte em Java usando reflexão. Detalhes e fonte de trabalho estão disponíveis no meu site .
Como funciona
Há uma classe de princípio chamada de retorno de chamada com uma classe aninhada chamada WithParms. A API que precisa do retorno de chamada terá um objeto de retorno de chamada como parâmetro e, se necessário, criará um Callback.WithParms como uma variável de método. Como muitas das aplicações desse objeto serão recursivas, isso funciona muito bem.
Com o desempenho ainda sendo uma alta prioridade para mim, eu não queria ser obrigado a criar uma matriz de objetos descartáveis para armazenar os parâmetros de cada chamada - afinal, em uma grande estrutura de dados, poderia haver milhares de elementos e no processamento de mensagens cenário, poderíamos acabar processando milhares de estruturas de dados por segundo.
Para ser thread-safe, a matriz de parâmetros precisa existir exclusivamente para cada chamada do método API e, para eficiência, o mesmo deve ser usado para cada chamada do retorno de chamada; Eu precisava de um segundo objeto que seria barato criar para vincular o retorno de chamada a uma matriz de parâmetros para invocação. Mas, em alguns cenários, o invocador já teria uma matriz de parâmetros por outros motivos. Por esses dois motivos, a matriz de parâmetros não pertence ao objeto de retorno de chamada. Além disso, a escolha da chamada (passar os parâmetros como uma matriz ou como objetos individuais) pertence às mãos da API usando o retorno de chamada, permitindo que ela use a chamada que melhor se adequar ao seu funcionamento interno.
A classe aninhada WithParms, portanto, é opcional e serve para dois propósitos, contém a matriz de objetos de parâmetro necessária para as chamadas de retorno de chamada e fornece 10 métodos invoke () sobrecarregados (com de 1 a 10 parâmetros) que carregam a matriz de parâmetros e, em seguida, invocar o destino de retorno de chamada.
A seguir, é apresentado um exemplo usando um retorno de chamada para processar os arquivos em uma árvore de diretórios. Este é um passe de validação inicial que conta apenas os arquivos para processar e garante que nenhum exceda um tamanho máximo predeterminado. Nesse caso, apenas criamos o retorno de chamada em linha com a chamada da API. No entanto, refletimos o método de destino como um valor estático, para que a reflexão não seja feita sempre.
static private final Method COUNT =Callback.getMethod(Xxx.class,"callback_count",true,File.class,File.class);
...
IoUtil.processDirectory(root,new Callback(this,COUNT),selector);
...
private void callback_count(File dir, File fil) {
if(fil!=null) { // file is null for processing a directory
fileTotal++;
if(fil.length()>fileSizeLimit) {
throw new Abort("Failed","File size exceeds maximum of "+TextUtil.formatNumber(fileSizeLimit)+" bytes: "+fil);
}
}
progress("Counting",dir,fileTotal);
}
IoUtil.processDirectory ():
/**
* Process a directory using callbacks. To interrupt, the callback must throw an (unchecked) exception.
* Subdirectories are processed only if the selector is null or selects the directories, and are done
* after the files in any given directory. When the callback is invoked for a directory, the file
* argument is null;
* <p>
* The callback signature is:
* <pre> void callback(File dir, File ent);</pre>
* <p>
* @return The number of files processed.
*/
static public int processDirectory(File dir, Callback cbk, FileSelector sel) {
return _processDirectory(dir,new Callback.WithParms(cbk,2),sel);
}
static private int _processDirectory(File dir, Callback.WithParms cbk, FileSelector sel) {
int cnt=0;
if(!dir.isDirectory()) {
if(sel==null || sel.accept(dir)) { cbk.invoke(dir.getParent(),dir); cnt++; }
}
else {
cbk.invoke(dir,(Object[])null);
File[] lst=(sel==null ? dir.listFiles() : dir.listFiles(sel));
if(lst!=null) {
for(int xa=0; xa<lst.length; xa++) {
File ent=lst[xa];
if(!ent.isDirectory()) {
cbk.invoke(dir,ent);
lst[xa]=null;
cnt++;
}
}
for(int xa=0; xa<lst.length; xa++) {
File ent=lst[xa];
if(ent!=null) { cnt+=_processDirectory(ent,cbk,sel); }
}
}
}
return cnt;
}
Este exemplo ilustra a beleza dessa abordagem - a lógica específica do aplicativo é abstraída no retorno de chamada, e o trabalho árduo de percorrer recursivamente uma árvore de diretórios fica bem escondido em um método utilitário estático completamente reutilizável. E não precisamos pagar repetidamente o preço de definir e implementar uma interface para cada novo uso. Obviamente, o argumento para uma interface é que ela é muito mais explícita sobre o que implementar (é aplicada, e não simplesmente documentada) - mas, na prática, não achei um problema obter a definição de retorno de chamada correta.
Definir e implementar uma interface não é tão ruim (a menos que você esteja distribuindo applets, como eu, onde é importante evitar a criação de classes extras), mas o que realmente brilha é quando você tem vários retornos de chamada em uma única classe. Não apenas está sendo forçado a colocá-los em uma classe interna separada, adicionada no aplicativo implementado, mas também é tedioso de programar, e todo esse código da placa da caldeira é realmente apenas "ruído".
