Polymorphie Funktion als Parameter

[G12112012]

Grüße zusammen!

Ich arbeite grade an einem Projekt in Java, und dabei benötige ich eine Möglichkeit eine Art Callback Mechanismus zu implementieren.

Ganz einfach umschrieben:
Ich habe ein paar Parameter. Für diese Parameter habe ich eine Funktion die irgendwas mit ihnen macht. Der Haken ist dass ich eine Möglichkeit suche um eine neue Funktion auf diesen Parameter laufen zu lassen, und zwar anstelle der alten Funktion. Die Idee wäre jetzt eine Funktion als Parameter mitzugeben die dann auf die Parameter angewendet wird.

Mir wurde gesagt sowas nennt man Callback und das würde in Java mit "Functors" gehen. Ich habe dazu gegooglet aber die Beispiele verwirren mich ehrlich gesagt nur.

Ich bin in Java eher Einsteiger und in anderen Sprachen wenn eher noch weniger bewandert.

Könnte mir jemand ein ganz simples Beispiel geben wie man sowas umsetzen kann?

 

[nillehammer]

Die "Funktion" kann man in Java (anders als in anderen Sprachen) nicht direkt übergeben. Was man aber machen kann, die gewünschte Methode mit return-Value und Parametern in einem Interface definieren. Stellen wir uns also eine Methode vor, die drei String-Parameter entgegennimmt "irgendwas" damit macht und einen String zurück gibt. Als Interface sähe das dann so aus:

// Das ist Deine "Callback-Funktion". Durch Verwendung eines Interfaces
// machst Du sie austauschbar.
public interface StringProcessor {

   public String process(String str1, String str2, String str3);
}

Jetzt soll die Funktion mit Leben gefüllt werden. Dazu brauchen wir Implementierungen des Interfaces. Wenn es reine Service-Methoden sind, die nur auf ihren Parametern arbeiten, mach ich das gerne mit enums, geht aber natürlich auch mit Instanzen von Klassen:

// Der Implementierungscode ist zugegebenermaßen weder schön noch sinnvoll.
// Es geht hier nur um die Erklärung des Prinzips
public enum StringProcessorImpls implements StringProcessor {

  CONCAENATOR {

    @Override
    public final String process(String str1, String str2, String str3) {

      return str1 + str2 + str3;
    }
   },
   FIRST_LAST {
          @Override
    public final String process(String str1, String str2, String str3) {

      return str1 + str3;
    }
  }
}

Mit den verschiedenen Implementierungen hast Du jetzt eine Auswahl von process-"Funktionen". Das ist so eine Art call-back (finde den Begriff nicht sehr passend, aber egal). Verwenden tust Du es dann so:

public static String processThree(String str1, String str2, String str3, StringProcessor sp) {
  // Hier wird die process-Methode des Interfaces aufgerufen
  // Wie dese tatsächlich funktioniert (welche "Funktion" sich dahinter verbirgt)
  // wird durch die Implementierung festgelegt, die der caller übergibt.
  return sp.process(String str1, String str2, String str3);
}

...
// Hier wird eine Implementierung übergeben, die zu einer konkatonierung führt
processThree("erster", "zweiter", "dritter", StringProcessorImpls.CONCATENATOR);

// Hier wird andere Implementierung übergeben, die zu einer konkatonierung von
// first und last führt.
processThree("erster", "zweiter", "dritter", StringProcessorImpls.FIRST_LAST );

Wie gesagt, der Code ist weder schön noch sinnvoll, aber so schaffst Du es verschiedene Funktionen in eine andere Methode zu bringen und sie dort zu benutuzen.

 

[Marco13]

Öhm... das mit den enums würde ich so nicht direkt empfehlen... Man kann sich z.B. eine eigene Klasse erstellen

public class ConcatStringProcessor implements StringProcessor {
   @Override
   public String process(String str1, String str2, String str3) { return ... }
}

oder besser die Implementierung verstecken und sich sowas von einer Methode liefern lassen - dann z.B. auch einfach als anonyme Klasse, wenn's ein Einzeiler ist:

class StringProcessors
{
    public static StringProcessor concatenating()
    {
        return new StringProcessor()
        {
           @Override
           public String process(String str1, String str2, String str3) { return ... }
        };
    }
}

 

[nillehammer]

Öhm... das mit den enums würde ich so nicht direkt empfehlen...

Da bin anderer Meinung. Unter bestimmten Voraussetungen finde ich die verwendung Enums als Interface-Implememtierung seeehr sinnvoll (Comparator- und Filter-Implementierungen mache ich fast immer so). Können wir gerne diskutieren (vielleicht in einem anderen Thread?)

oder besser die Implementierung verstecken und sich sowas von einer Methode liefern lassen

Da widerrum stimme ich Dir zu. Code, der direkt die Enum als Implementierung veröffentlicht, wirst Du in von mir erstelltem Produktivcode auch nicht finden. Das geht immer über package private Impls und dann Factories oder DI-Module. Ich wollte aber nicht mehr Code schreiben, als nötig war, um das Prinzip "Callback-Interface" zu erklären.

 

[G12112012]

Ich danke euch, ihr habt mir sehr geholfen! Jetzt macht das ganze schon wesentlich mehr Sinn.

 

[mvitz]

Da bin anderer Meinung. Unter bestimmten Voraussetungen finde ich die verwendung Enums als Interface-Implememtierung seeehr sinnvoll (Comparator- und Filter-Implementierungen mache ich fast immer so). Können wir gerne diskutieren (vielleicht in einem anderen Thread?)

Da widerrum stimme ich Dir zu. Code, der direkt die Enum als Implementierung veröffentlicht, wirst Du in von mir erstelltem Produktivcode auch nicht finden. Das geht immer über package private Impls und dann Factories oder DI-Module. Ich wollte aber nicht mehr Code schreiben, als nötig war, um das Prinzip "Callback-Interface" zu erklären.

Hat vor allem den Vorteil, dass man bei Funktionen, wie "alwaysTrue", etc. sich das implementieren von Equals spart ;-) (das macht sogar Gooogle Guava für diese Funktionen so).

 

[Marco13]

@nillehammer: Wenn man es sowieso versteckt, besteht auch kein Grund mehr, es als enum zu schreiben (aber genaugenommen auch keiner, das NICHT zu tun, deswengen ... :bahnhof: )

 

[nillehammer]

deswengen ... :bahnhof:

Ok, dann nicht Ich hab überlegt, darüber mal einen Blog mit Code zu schreiben. Wenn's soweit ist, freue ich mich auf Kommentare von Dir.

 

[bygones]

mit enums erspart man sich die Factory, die man sonst anbieten wuerde um die Implementierungen zu verstecken.

bei enums bekommt man halt noch zusatzfunktionen, die man vielleicht nicht unbedingt haben muss, wie values() oder valueOf(). Bei konstanten implementierungen machen diese nicht sehr viel sinn imho.

Von daher finde ich erstmal eine simple Factory besser.