He implementado el soporte de devolución de llamada / delegado en Java usando la reflexión. Los detalles y la fuente de trabajo están disponibles en mi sitio web .
Cómo funciona
Hay una clase principal llamada Callback con una clase anidada llamada WithParms. La API que necesita la devolución de llamada tomará un objeto de devolución de llamada como parámetro y, si es necesario, creará un Callback.WithParms como una variable de método. Dado que muchas de las aplicaciones de este objeto serán recursivas, esto funciona de manera muy limpia.
Dado que el rendimiento sigue siendo una gran prioridad para mí, no quería que se me pidiera que creara una matriz de objetos desechables para contener los parámetros para cada invocación; después de todo, en una estructura de datos de gran tamaño podría haber miles de elementos y un procesamiento de mensajes escenario podríamos terminar procesando miles de estructuras de datos por segundo.
Para ser seguro para subprocesos, la matriz de parámetros debe existir de manera única para cada invocación del método API, y para mayor eficacia, se debe usar el mismo para cada invocación de la devolución de llamada; Necesitaba un segundo objeto que sería barato de crear para vincular la devolución de llamada con una matriz de parámetros para la invocación. Pero, en algunos escenarios, el invocador ya tendría una matriz de parámetros por otros motivos. Por estos dos motivos, la matriz de parámetros no pertenece al objeto Callback. Además, la elección de la invocación (pasando los parámetros como una matriz o como objetos individuales) pertenece a la API utilizando la devolución de llamada que le permite utilizar la invocación que mejor se adapte a su funcionamiento interno.
La clase anidada WithParms, entonces, es opcional y tiene dos propósitos: contiene la matriz de objetos de parámetros necesarios para las invocaciones de devolución de llamada, y proporciona 10 métodos invoke () sobrecargados (con 1 a 10 parámetros) que cargan la matriz de parámetros y luego invocar el objetivo de devolución de llamada.
Lo que sigue es un ejemplo usando una devolución de llamada para procesar los archivos en un árbol de directorios. Este es un pase de validación inicial que solo cuenta los archivos a procesar y garantiza que ninguno exceda un tamaño máximo predeterminado. En este caso, simplemente creamos la devolución de llamada en línea con la invocación de la API. Sin embargo, reflejamos el método de destino como un valor estático para que la reflexión no se realice siempre.
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 ejemplo ilustra la belleza de este enfoque: la lógica específica de la aplicación se abstrae en la devolución de llamada, y el trabajo pesado de recorrer recursivamente un árbol de directorios está bien escondido en un método de utilidad estática completamente reutilizable. Y no tenemos que pagar repetidamente el precio de definir e implementar una interfaz para cada nuevo uso. Por supuesto, el argumento para una interfaz es que es mucho más explícito sobre qué implementar (se aplica, no simplemente se documenta), pero en la práctica no he encontrado que sea un problema obtener la definición correcta de devolución de llamada.
Definir e implementar una interfaz no es realmente tan malo (a menos que esté distribuyendo applets, como yo lo hago, donde evitar crear clases adicionales realmente importa), pero donde esto realmente brilla es cuando tiene múltiples devoluciones de llamada en una sola clase. No solo se está forzando a empujarlos a cada uno en una clase interna separada agregada sobrecarga en la aplicación implementada, sino que es francamente tedioso programar y todo ese código de placa de caldera es realmente solo "ruido".
