Arrays von Methoden möglich?

[berndoa]

Hallo,
ich habe mal wieder eine verrückte Frage und mir fällt kein wirklich passender Titel ein.

Hierzu mal ein Beispiel:

public class A{
    double number;

    public static void main(String[] args){
        A a=new A();
// Der wichtige Part
        for(//Methode p:{met1,met2,met3,met4}){
            p();
            System.out.println("new number="+number);
        }

       

    }

    public A(){
        number=1.0;
    }

    public void met1(){
        number=number*3;
    }

   
    public void met2(){
        number=number/4;
    }


    public void met3(){
        number=number+50;
    }

   
    public void met4(){
        number=number-69;
    }


}

Der Kommentarteil ist der, um den es mir geht.
Es kommen 4 verschiedene Methoden vor, die die Variable Number des Objekts verändern können.

Nun will ich irgendwie die Möglichkeit haben, der Reihe nahc alle 4 Methoden anzuwenden.
Also wie in einer for each Schleife durch die Menge der Methoden met1-met4 durchzugehen und jede einmal auszuführen.

Oder auch als andere Idee, per Zufallszahl zu bestimmen, welche der 4 Methoden ausgeführt wird.

Kurzum, so wie ich durch eine Lsite an Arrays durchgehen kann, würde ich auch gerne mit Methoden agieren und bedingungsabhängig eine oder mehrere davon auswählen und ausführen.

Lässt sich sowas irgendwie umsetzen mit irgendeinem Kosntrukt oder Konzept?

Hintergrund, wen es interessiert, ist Folgender:
Ich will beim Blackjack alle möglichen Endspielkonfigurationen durchgehen.
Und das im Sinne einer Tiefensuche, also erst einen "Pfad" zu Ende durchspielen bevor der nächste durchprobiert wird.

Da ich das rekursiv machen will, ist es nötig, jeder der 4 möglichen Spielerhandlungen zu benutzen.

kurzum, ich muss sagen können "benutze jede der 4 Methoden einmal" und bei jeder Ausführung einer solchen methode muss ich, wie im Rumpf einer for each Schleife, von der gewählten Methode abhängig anders agieren können.

 

[Beispiel0]

Nein, geht nicht. Du kannst nur Klassen in Arrays stecken und Methoden auf diesen aufrufen, aber keine Funktionen/Methoden.

 

[LimDul]

Doch das geht über Reflection: https://www.baeldung.com/java-method-reflection

Alternativ geht das auch Lambdas (was hier vermutlich der bessere Weg ist)

Runnable[] runnables = new Runnable[4];
runnables[0] = () -> met1();
runnables[1] = () -> met2();
runnables[2] = () -> met3();
runnables[3] = () -> met4();
(...)
runnables[i].run();

 

[Beispiel0]

new Runnable[4];

Das ist ein neues Array mit Runnable-Klassen

 

[berndoa]

Doch das geht über Reflection: https://www.baeldung.com/java-method-reflection

Alternativ geht das auch Lambdas (was hier vermutlich der bessere Weg ist)

Runnable[] runnables = new Runnable[4];
runnables[0] = () -> met1();
runnables[1] = () -> met2();
runnables[2] = () -> met3();
runnables[3] = () -> met4();
(...)
runnables[i].run();

Wenn ich dann eins dieser Methoden benutzen will, wie mache ich das dann?

runnables[i]();

wird es vermjutlich nicht sein, oder?

 

[Robert Zenz]

Doch das geht über Reflection: https://www.baeldung.com/java-method-reflection

Alternativ geht das auch Lambdas (was hier vermutlich der bessere Weg ist)

Runnable[] runnables = new Runnable[4];
runnables[0] = () -> met1();
runnables[1] = () -> met2();
runnables[2] = () -> met3();
runnables[3] = () -> met4();
(...)
runnables[i].run();

Kannst du auch als Methoden-Referenzen machen:

runnables[0] = this::met1;
runnables[1] = this::met2;
runnables[2] = this::met3;
runnables[3] = this::met4;

 

[LimDul]

Wenn ich dann eins dieser Methoden benutzen will, wie mache ich das dann?

runnables[i]();

wird es vermjutlich nicht sein, oder?

Die run-Methode aufrufen, siehe die letzte Zeile in meinem Beispiel

Das ist ein neues Array mit Runnable-Klassen

Mit Reflection ginge auch ein

Method[] methods = new Method[4];

Allerdings ist das signifikant unhandlicher.

 

[berndoa]

Kannst du auch als Methoden-Referenzen machen:

runnables[0] = this::met1;
runnables[1] = this::met2;
runnables[2] = this::met3;
runnables[3] = this::met4;

Wusste gar nicht dass das geht.
Offensichtlich ordnet sowas wie

runnables[0] =this::met1

die met1 Methode de aktuellen Objekts zu.

Aber was hat es eigentlich mit dem sonst üblicherweisen nicht vorkommenden :: auf sich?
Hätte jetzt eher was mit einem Punkt dazwischen erwartet.
Wiede rwas, was ich noch nicht kenne?

 

[Robert Zenz]

Methoden Referenzen.

 

[Beispiel0]

Kannst du auch als Methoden-Referenzen machen:

runnables[0] = this::met1;
runnables[1] = this::met2;
runnables[2] = this::met3;
runnables[3] = this::met4;

Das sind immernoch Klassen und keine Methoden.

 

[berndoa]

Ist es dabei, egal ob jetzt die Lambda Variante oder die Variante mit den Methoden Referenzen, eigentlich egal ob die Methoden static oder nicht sind?

 

[Beispiel0]

Aber was hat es eigentlich mit dem sonst üblicherweisen nicht vorkommenden :: auf sich?
Hätte jetzt eher was mit einem Punkt dazwischen erwartet.

Das ist nur eine Lambda Kurzschreibweise.

 

[Beispiel0]

Ist es dabei, egal ob jetzt die Lambda Variante oder die Variante mit den Methoden Referenzen, eigentlich egal ob die Methoden static oder nicht sind?

Du hast immer noch ein Array von Runnable-Klassen. Du kannst keine Methoden-Arrays erstellen. Die Lambda-Schreibweise ist einfach nur syntaktischer Zucker...

 

[mrBrown]

Das sind immernoch Klassen und keine Methoden.

Klassen sind es auf jeden Fall nicht.

Und auch wenn es nach JSL keine Methode ist, macht es trotzdem Sinn, die auf einem höheren Abstraktionslevel so zu zu bezeichnen.

 

[Beispiel0]

Klassen sind es auf jeden Fall nicht.

Und auch wenn es nach JSL keine Methode ist, macht es trotzdem Sinn, die auf einem höheren Abstraktionslevel so zu zu bezeichnen.

? Rede anscheinend Chinesisch, keiner versteht mich

 

[berndoa]

Na, egal wie das Ganze nun technisch korrekt bezeichnet wird, ich merks mir einfach mal dass man auf die 2 Arten sozusagen Methoden als Objekte (wie Strings, Lists, etc.) benutzen kann, mehr oder weniger

 

[temi]

? Rede anscheinend Chinesisch, keiner versteht mich

Doch schon, aber die Frage war:

Nun will ich irgendwie die Möglichkeit haben, der Reihe nach alle 4 Methoden anzuwenden

Und die ist doch wohl beantwortet.

 

[berndoa]

Doch schon, aber die Frage war:

Und die ist doch wohl beantwortet.

Habe auch nie was Anderes behauptet.

Konrad und Co. empfinden sowas vielleicht als Lapalie aber für mich und Ähnliche ist es sprichwörtlih "mind blowing" dass man hier, anstatt dass man ein Array/Liste/etc. von Integers/String oder so hat, dass man genauso gut hier eine Liste von Methoden auf die gleiche Weise benutzen kann.

Das macht manche Sachen einfach sehr viel einfacher!

 

[httpdigest]

Wenn du weißt, was eine anonyme Klasse ist, dann sind Lambdaausdrücke und auch Methodenreferenzen prinzipiell dasselbe wie:

Runnable[] methods = new Runnable[] {
  new Runnable() {
    public void run() {
      met1();
    }
  },
  new Runnable() {
    public void run() {
      met2();
    }
  },
  new Runnable() {
    public void run() {
      met3();
    }
  },
  new Runnable() {
    public void run() {
      met4();
    }
  },
};

In diesem Fall wird das Array einfach nur bei Deklaration vorinitialisiert.
Und wenn du anonyme Klasse (noch) nicht kennst, dann hättest du aus jeder der obigen vier anonymen Klassen auch echte top-level oder nested Klassen machen können.
Lambdaausdrücke und Methodenreferenzen können das nur sehr viel präziser und mit weniger "Java-Zeremonie" ausdrücken.

 

[berndoa]

Wenn du weißt, was eine anonyme Klasse ist, dann sind Lambdaausdrücke und auch Methodenreferenzen prinzipiell dasselbe wie:

Runnable[] methods = new Runnable[] {
  new Runnable() {
    public void run() {
      met1();
    }
  },
  new Runnable() {
    public void run() {
      met2();
    }
  },
  new Runnable() {
    public void run() {
      met3();
    }
  },
  new Runnable() {
    public void run() {
      met4();
    }
  },
};

In diesem Fall wird das Array einfach nur bei Deklaration vorinitialisiert.
Und wenn du anonyme Klasse (noch) nicht kennst, dann hättest du aus jeder der obigen vier anonymen Klassen auch echte top-level oder nested Klassen machen können.
Lambdaausdrücke und Methodenreferenzen können das nur sehr viel präziser und mit weniger "Java-Zeremonie" ausdrücken.

Also ich finde, was ich bisher so sehe, die Lambda Ausdrücke, geschweigedenn dieses

this::Methodenname

einfach nur sau praktisch! :O
Wobei ich bei den Lambdaausdrücken noch nicht immer üebrall die Syntax durchblicke weils halt ungewohnt ist, eine Methode zu übergeben.

Hätte ich shcon früher gewusst dass es das gibt, hätte ich das schon immer überall benutzt



Rein rehcnerisch , wenn man Arrays von Methoden/Runnables benutzen kann, dann kann man doch auch bestimmt ArrayLists und ähnliches damit ebenso nutzen? :O

 

[LimDul]

Ja klar. Es sind ja formal - wie @Beispiel0 drauf hingewiesen hat, ja keine Methoden, sondern quasi anonyme Klassen.

Sprich, der Code

class MyClass {
....
Runnable r = this:method();
...
}

ist semantisch "quasi" identisch zu (wenn man die anonyme Klasse durch eine explizite ersetzen würde):

class MyRunnableClass implements Runnable {
private MyClass myClassInstanz;
public MyRunnableClass(MyClass myClassInstanz) {
  this.myClassInstanz = myClassInstanz;
}

public void run() {
  myClassInstanz.method();
}
}

class MyClass {
....
Runnable r = new MyRunnableClass(this);
...
}

Es ist halt nur viel viel weniger Overhead beim schreiben. (Und ja, der Code ist nicht exakt gleich - aber vom Verständnis her hilft es evtl.)

 

[httpdigest]

Also ich finde, was ich bisher so sehe, die Lambda Ausdrücke, geschweigedenn dieses

this::Methodenname

einfach nur sau praktisch! :O

Da gebe ich dir Recht.
Es ist aber immer sinnvoll, dass man auch _versteht_, was man da eigentlich tut bzw. was man da hat.

Folgender Code funktioniert z.B. nicht:

public class Test {
  public static void methode() {
    System.out.println("Hello, World!");
  }
  public static void main(String[] args) {
    Object method = Test::methode; // <- Compilerfehler hier! Zieltyp "Object" inkompatibel zur Methodensignatur!
  }
}

Das liegt daran, dass jeder Lambdaausdruck und auch jede Methodenreferenz von sich aus keinen statischen Typ besitzt, sondern erst im Kontext eines "Zieltyps" bzw. "Zielinterfaces" nutzbar wird. Java bzw. das Typsystem der JVM selbst ist eben rein objektorientiert und Methoden sind keine first-class citizen. Methoden an sich sind also keine Werte/Objekte mit einem statischen Typ.

Stattdessen muss aus dem Kontext (wie wird ein Lambdaausdruck bzw. eine Methodenreferenz benutzt) - also wie ist der statische Typ der Variable, der der Lambdaausdruck bzw. die Methodenreferenz zugewiesen wird oder wie ist der formale Parametertyp des Parameters, der der Lambdaausdruck bzw. die Methodenreferenz bei einem Methodenaufruf als Argument übergeben wird - der Zieltyp ermittelt werden.

Nur aus dieser Kontextinformation, die die JLS den "Zieltyp" nennt, kann der Compiler letztlich eine anonyme Klasse zur Laufzeit generieren und eine Instanz dieser Klasse erzeugen.

Folgendes z.B. würde gehen:

public class Test {
  public static void methode() {
    System.out.println("Hello, World!");
  }
  public static void main(String[] args) {
    Runnable method = Test::methode; // <- alles okay. Signatur der Methode "methode" ist _kompatibel_ mit der einzigen Methode im Interface "Runnable"
  }
}

 

[berndoa]

Da gebe ich dir Recht.
Es ist aber immer sinnvoll, dass man auch _versteht_, was man da eigentlich tut bzw. was man da hat.

Folgender Code funktioniert z.B. nicht:

public class Test {
  public static void methode() {
    System.out.println("Hello, World!");
  }
  public static void main(String[] args) {
    Object method = Test::methode; // <- Compilerfehler hier! Zieltyp "Object" inkompatibel zur Methodensignatur!
  }
}

Das liegt daran, dass jeder Lambdaausdruck und auch jede Methodenreferenz von sich aus keinen statischen Typ besitzt, sondern erst im Kontext eines "Zieltyps" bzw. "Zielinterfaces" nutzbar wird. Java bzw. das Typsystem der JVM selbst ist eben rein objektorientiert und Methoden sind keine first-class citizen. Methoden an sich sind also keine Werte/Objekte mit einem statischen Typ.

Stattdessen muss aus dem Kontext (wie wird ein Lambdaausdruck bzw. eine Methodenreferenz benutzt) - also wie ist der statische Typ der Variable, der der Lambdaausdruck bzw. die Methodenreferenz zugewiesen wird oder wie ist der formale Parametertyp des Parameters, der der Lambdaausdruck bzw. die Methodenreferenz bei einem Methodenaufruf als Argument übergeben wird - der Zieltyp ermittelt werden.

Nur aus dieser Kontextinformation, die die JLS den "Zieltyp" nennt, kann der Compiler letztlich eine anonyme Klasse zur Laufzeit generieren und eine Instanz dieser Klasse erzeugen.

Folgendes z.B. würde gehen:

public class Test {
  public static void methode() {
    System.out.println("Hello, World!");
  }
  public static void main(String[] args) {
    Runnable method = Test::methode; // <- alles okay. Signatur der Methode "methode" ist _kompatibel_ mit der einzigen Methode im Interface "Runnable"
  }
}

Also letztlich, solange ich den Lambdaausdruck einem Runnable "Objekt" zuweise, passt Alles

Wobei runnable technisch gesehen keine objekte haben kann, weil interface...

Aber nur so als Merkregel.

 

[httpdigest]

Du kannst einen Lambdaausdruck immer im Kontext eines "funktionalen" Interfaces benutzen, wenn die einzige Methode in diesem "funktionalen" Interface kompatibel zur Signatur des Lambdaausdrucks (oder der Methodenreferenz) ist.
Runnable ist ein Interface, ja, aber der _Wert_, zu dem der Lambdaausdruck bzw. die Methodenreferenz zur Laufzeit auswertet, ist natürlich kein Interface, sondern eine Instanz einer (synthethisch zur Laufzeit erzeugten) Klasse, die das Interface implementiert.

Also letztlich, solange ich den Lambdaausdruck einem Runnable "Objekt" zuweise, passt Alles

Das ist unpräzise formuliert. Wir weisen hier den Lambdaausdruck keinem Runnable Objekt zu, sondern einer Variablen vom (statischen bzw. Compilezeit-)Typ Runnable.

 

[Neumi5694]

Anm: Diese Schreibweise funktioniert neben Runnable auch bei Consumer oder Function.

 

[berndoa]

Kurze dumme Frage:
ANgenommen ich benutze die Variante von oben:

Runnable[] runnables = new Runnable[4];
runnables[0] = () -> met1();
runnables[1] = () -> met2();
runnables[2] = () -> met3();
runnables[3] = () -> met4();
(...)
runnables[i].run();

Wie verhält es sich da wenn eine der Methoden Parameter übergeben bekommt?

Schreibt man da dann sowas wie

runnables[2].run(parameter1,parameter2);

Oder wie geht das?

 

[yfons123]

TJA da würden deine gehassten interfaces hilfreich sein um das zu lösen

 

[LimDul]

Grundsätzlich müssen die Methoden alle die gleiche Signatur haben (Vor allem Parameter). Ein Mischen einer Methode met1(int, int) mit einer Methode met2(int) geht nicht.

Man kann dann nicht mehr Runnable verwenden, sondern muss ggf. sein eigenes Interface definieren

@FunctionalInterface
public MyMethodInterface

public void doSomething(int parameter1, int paremeter2);
}

Und dann anstelle von Runnable entsprechend dein Interface nehmen:

MyMethodInterface[] myArray= new MyMethodInterface[4];
myArray[0] = (p1, p2) -> met1(p1, p2);
...
myArray[0].doSomething(parameter1, parameter2);

 

[berndoa]

TJA da würden deine gehassten interfaces hilfreich sein um das zu lösen

Nur über meine verrottete LEICHE! ;-)

Grundsätzlich müssen die Methoden alle die gleiche Signatur haben (Vor allem Parameter). Ein Mischen einer Methode met1(int, int) mit einer Methode met2(int) geht nicht.

Man kann dann nicht mehr Runnable verwenden, sondern muss ggf. sein eigenes Interface definieren

@FunctionalInterface
public MyMethodInterface

public void doSomething(int parameter1, int paremeter2);
}

Und dann anstelle von Runnable entsprechend dein Interface nehmen:

MyMethodInterface[] myArray= new MyMethodInterface[4];
myArray[0] = (p1, p2) -> met1(p1, p2);
...
myArray[0].doSomething(parameter1, parameter2);

Hm, und da braucht es dann kein "implements", so wie ja normalerweise klassen interfaces implementieren?

 

[Neumi5694]

Nur über meine verrottete LEICHE! ;-)


Hm, und da braucht es dann kein "implements", so wie ja normalerweise klassen interfaces implementieren?

Wie Functional Interfaces funktionieren, sollte mittlerweile klar sein. Da geht's um Methoden, nicht um Klassen.

Anstatt dem MyMethodInterface kannst du auch einen BiConsumer<Integer,Integer> verwenden, der macht genau das Gleiche, nur halt eben mit Integer und nicht int.

Sofern du die Parameter eh nur 1:1 durchreichst, kannst du die Methoden sogar ohne p1 und p2 zuweisen

myArray[0] = this::met1;

 

[berndoa]

Grundsätzlich müssen die Methoden alle die gleiche Signatur haben (Vor allem Parameter). Ein Mischen einer Methode met1(int, int) mit einer Methode met2(int) geht nicht.

Man kann dann nicht mehr Runnable verwenden, sondern muss ggf. sein eigenes Interface definieren

@FunctionalInterface
public MyMethodInterface

public void doSomething(int parameter1, int paremeter2);
}

Und dann anstelle von Runnable entsprechend dein Interface nehmen:

MyMethodInterface[] myArray= new MyMethodInterface[4];
myArray[0] = (p1, p2) -> met1(p1, p2);
...
myArray[0].doSomething(parameter1, parameter2);

Aber wenn ich konsequent nur Methoden habe, die bspw. alle genau 2 int werte als Input annehmen, dann kann ich das mit Runnables und so machen?

Würde das dann so oder so ähnlich aussehen?

Runnable[] runnables = new Runnable[4];
runnables[0] = (int x, int y) -> met1(x,y);
runnables[1] = (int x, int y) -> met2(x,y);
runnables[2] = (int x, int y) -> met3(x,y);
runnables[3] = (int x, int y) -> met4(x,y);
(...)
runnables[2].run(1,2);

 

[yfons123]

public interface Runnable
{
    public void run();
}

das ist das interface von runnable... kannst du mal sachen verwenden wie functional interfaces die in den letzten 30 jahren mal erfunden wurden ?

 

[berndoa]

mir ist nur noch nicht ganz klar, wo ich die parameter genau einbringe bei der ganzen geschichte
Pff, Interfaces... ;-)

 

[Neumi5694]

mir ist nur noch nicht ganz klar, wo ich die parameter genau einbringe bei der ganzen geschichte
Pff, Interfaces... ;-)

Die Antwort steht schon in mindestens zwei Vorposts, einmal hardcodiert mit 2 mal int und einmal frei definierbar.

Neben spezialisierten funktionalen Interfaces (wie Actionlistenern, die einen gewissen Typ als Parameter erwarten) bietet Java noch ein paar flexiblere an: Runnable, Consumer, BiConsumer, Function, BiFunction, TriConsumer und TriFunction.
Edit: Man kann sich natürlich noch eigene anlegen, aber diese hier sind vorgegeben.

 

[temi]

Neben spezialisierten funktionalen Interfaces (wie Actionlistenern, die einen gewissen Typ als Parameter erwarten) bietet Java noch ein paar flexiblere an: Runnable, Consumer, BiConsumer, Function, BiFunction, TriConsumer und TriFunction.
Edit: Man kann sich natürlich noch eigene anlegen, aber diese hier sind vorgegeben.

Hier sind sie mal alle zusammen: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/function/package-summary.html

 

[Neumi5694]

Hier sind sie mal alle zusammen: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/function/package-summary.html

Ein paar davon kannte ich gar nicht, sind aber größtenteils eh nur so was wie Wrapper
Ein UnaryOperator<T> z.B. ist genau das Gleiche wie eine Function<T,T>
(edit: und das steht sogar in der API, doh! Ok, es gibt eine zusätzliche Methode)

 

[berndoa]

Ich kann also schlicht Runnables nicht nehmen wenn meine Methode einen oder mehrere Parameter annimmt :-/
Sondern muss was eigenes Basteln oder irgendwo ein fertiges functional interface, das passt, finden

 

[LimDul]

Korrekt. Du brauchst ein Interface was genau eine nicht implementierte Methode, deren Signatur bzgl. der Parameter genau der Signatur entspricht, die du verwenden willst.

 

[temi]

Ich kann also schlicht Runnables nicht nehmen wenn meine Methode einen oder mehrere Parameter annimmt :-/
Sondern muss was eigenes Basteln oder irgendwo ein fertiges functional interface, das passt, finden

Ja, aber das ist ja eigentlich völlig egal, ob das Runnable heißt oder sonst wie. Runnable ist halt einfach ein Interface, das genau eine parameterlose Methode run() definiert (und normalerweise im Kontext von Threads verwendet wird), siehe https://docs.oracle.com/javase/7/docs/api/java/lang/Runnable.html

Wenn es passt, dann nimm eines der o. g. funktionalen Interfaces oder deklariere dir selbst ein passendes Interface, wie in #28 gezeigt. Das sind gerade mal vier Zeilen Code. So schlimm ist das auch nicht.

 

[berndoa]

Ja, aber das ist ja eigentlich völlig egal, ob das Runnable heißt oder sonst wie. Runnable ist halt einfach ein Interface, das genau eine parameterlose Methode run() definiert (und normalerweise im Kontext von Threads verwendet wird), siehe https://docs.oracle.com/javase/7/docs/api/java/lang/Runnable.html

Wenn es passt, dann nimm eines der o. g. funktionalen Interfaces oder deklariere dir selbst ein passendes Interface, wie in #28 gezeigt. Das sind gerade mal vier Zeilen Code. So schlimm ist das auch nicht.

Muss ich aber für jedes Interface eine eigene Datei anlegen, oder?

Oder kann ich das Interface auch in der Datei definieren wo ich es für Methodenreferenzen benutze, innere Klasse und sowas?

 

[Neumi5694]

Muss ich aber für jedes Interface eine eigene Datei anlegen, oder?

Oder kann ich das Interface auch in der Datei definieren wo ich es für Methodenreferenzen benutze, innere Klasse und sowas?

Schau dir doch erinfach mal den Quellcode eines Functional Interfaces an. So muss deines auch ausschauen.

Du machst dir da Probleme, wo keine sind, bzw. gehst in die falsche Richtung.

Die Frage ist nicht, wie du irgendwas in deine Arraystruktur reinquetschen kannst, sondern was du eigentlich machen willst.

HAST du zu verwendende Variablen? Falls ja, welche? Was soll damit passieren?
Sobald du das weißt, DANN entscheide dich für ein Interface oder auch nicht.

Runnable ist eine Methode ohne Parameter und ohne Rückgabewert. Consumer haben einen oder mehrere Parameter und keine Rückgabewert. Functions haben Parameter und Rückgabewerte, Supplier haben keine Parameter, aber einen Rückgabewert.

Wenn du weißt, was du eigentlich willst, ergibt sich der Rest von selbst.

Für "void function(int,int)" wurden bereits 2 Lösungen gepostet, nimm dir mal die Zeit, dir die Antworten auch durchzulesen.

 

[berndoa]

Schau dir doch erinfach mal den Quellcode eines Functional Interfaces an. So muss deines auch ausschauen.

Du machst dir da Probleme, wo keine sind, bzw. gehst in die falsche Richtung.

Die Frage ist nicht, wie du irgendwas in deine Arraystruktur reinquetschen kannst, sondern was du eigentlich machen willst.

HAST du zu verwendende Variablen? Falls ja, welche? Was soll damit passieren?
Sobald du das weißt, DANN entscheide dich für ein Interface oder auch nicht.

Runnable ist eine Methode ohne Parameter und ohne Rückgabewert. Consumer haben einen oder mehrere Parameter und keine Rückgabewert. Functions haben Parameter und Rückgabewerte, Supplier haben keine Parameter, aber einen Rückgabewert.

Wenn du weißt, was du eigentlich willst, ergibt sich der Rest von selbst.

Für "void function(int,int)" wurden bereits 2 Lösungen gepostet, nimm dir mal die Zeit, dir die Antworten auch durchzulesen.

Nach etwas Googeln lautet wohl die Antwort:
Ist egal ob das Interface in einer eigenen Datei oder in der gleichen Datei wie der Rest definiert wird

 

[yfons123]

Nach etwas Googeln lautet wohl die Antwort:
Ist egal ob das Interface in einer eigenen Datei oder in der gleichen Datei wie der Rest definiert wird

ich bezweifle höchst gradig dass irgendwer da ggeschrieben hat dass es egal ist..

 

[Neumi5694]

Wenn es dir wirklich nur um eine Funktion wie oben beschrieben geht, brauchst du kein neues Interface anzulegen, es reicht, wenn du die oben genannten Antworten liest.

 

[temi]

Muss ich aber für jedes Interface eine eigene Datei anlegen, oder?

Verwende eine IDE, die übernimmt die meiste Arbeit für dich. Dann ist es auch kein Problem, wenn man sauber programmiert und für jede Klasse/Interface eine Datei hat.

Aber das wurde dir ja schon zig mal gesagt....