Ich habe Callback / Delegate-Unterstützung in Java mithilfe von Reflection implementiert. Details und Arbeitsquelle finden Sie auf meiner Website .
Wie es funktioniert
Es gibt eine Hauptklasse namens Callback mit einer verschachtelten Klasse namens WithParms. Die API, die den Rückruf benötigt, verwendet ein Callback-Objekt als Parameter und erstellt bei Bedarf einen Callback.WithParms als Methodenvariable. Da sehr viele Anwendungen dieses Objekts rekursiv sind, funktioniert dies sehr sauber.
Da die Leistung für mich immer noch eine hohe Priorität hat, wollte ich nicht verpflichtet sein, ein Wegwerfobjektarray zu erstellen, das die Parameter für jeden Aufruf enthält - schließlich kann es in einer großen Datenstruktur Tausende von Elementen geben und in einer Nachrichtenverarbeitung In diesem Szenario könnten wir am Ende Tausende von Datenstrukturen pro Sekunde verarbeiten.
Um threadsicher zu sein, muss das Parameterarray für jeden Aufruf der API-Methode eindeutig vorhanden sein, und aus Effizienzgründen sollte für jeden Aufruf des Rückrufs dasselbe verwendet werden. Ich brauchte ein zweites Objekt, dessen Erstellung billig wäre, um den Rückruf mit einem Parameterarray zum Aufrufen zu binden. In einigen Szenarien verfügt der Aufrufer jedoch aus anderen Gründen bereits über ein Parameterarray. Aus diesen beiden Gründen gehört das Parameterarray nicht zum Callback-Objekt. Auch die Wahl des Aufrufs (Übergabe der Parameter als Array oder als einzelne Objekte) liegt in den Händen der API, die den Rückruf verwendet, um den Aufruf zu verwenden, der für das Innenleben am besten geeignet ist.
Die verschachtelte WithParms-Klasse ist also optional und dient zwei Zwecken: Sie enthält das für die Rückrufaufrufe erforderliche Parameterobjektarray und bietet 10 überladene invoke () -Methoden (mit 1 bis 10 Parametern), die das Parameterarray laden und dann Rufen Sie das Rückrufziel auf.
Es folgt ein Beispiel für die Verwendung eines Rückrufs zur Verarbeitung der Dateien in einem Verzeichnisbaum. Dies ist ein erster Validierungsdurchlauf, bei dem nur die zu verarbeitenden Dateien gezählt werden und sichergestellt wird, dass keine eine vorgegebene maximale Größe überschreitet. In diesem Fall erstellen wir den Rückruf nur inline mit dem API-Aufruf. Wir reflektieren die Zielmethode jedoch als statischen Wert, sodass die Reflexion nicht jedes Mal erfolgt.
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;
}
Dieses Beispiel zeigt die Schönheit dieses Ansatzes: Die anwendungsspezifische Logik wird in den Rückruf abstrahiert, und die Plackerei, einen Verzeichnisbaum rekursiv zu durchlaufen, ist in einer vollständig wiederverwendbaren statischen Dienstprogrammmethode versteckt. Und wir müssen nicht wiederholt den Preis für die Definition und Implementierung einer Schnittstelle für jede neue Verwendung bezahlen. Natürlich das Argument für eine Schnittstelle ist dass es viel expliziter ist, was implementiert werden soll (erzwungen, nicht einfach dokumentiert) - aber in der Praxis habe ich es nicht als Problem empfunden, die Rückrufdefinition richtig zu machen.
Das Definieren und Implementieren einer Schnittstelle ist nicht wirklich so schlecht (es sei denn, Sie verteilen wie ich Applets, bei denen das Vermeiden des Erstellens zusätzlicher Klassen tatsächlich wichtig ist), aber dies ist wirklich der Fall, wenn Sie mehrere Rückrufe in einer einzelnen Klasse haben. Es ist nicht nur gezwungen, sie jeweils in eine separate innere Klasse zu verschieben, was den Overhead in der bereitgestellten Anwendung erhöht, sondern es ist geradezu mühsam zu programmieren, und der gesamte Code auf der Kesselplatte ist wirklich nur "Rauschen".
