funktion per pointer aufrufen?

[jghj]

Hallo wissende,

ich weiß in java gibt es nicht wirklich pointer. Aber intern muss es ja mit pointern arbeiten.

Ich möchte jetzt per pointer eine funktion aufrufen, (also bzw. einfach einer funktion eine funktionsreferenz mitgeben, die aufgerufen werden kann)

Leider kann ich hier auch keine prototypen erstellen auf die ich casten könnte .. jemand ne idee?

danke im voraus

mfg jghj

[Pinhead]

Übergebe deiner Funktion eine Klasse die die auszuführende Funktion beinhaltet

[jghj]

und da gibts keine andere Möglichkeiten? ich mein ich kann ja nit für jede Funktion ne eigene Klasse stricken, da hab ich dann 50 klassen mit fast keinem inhalt..

oder dass man einfach was evaluaten kann?

[Krain]

Andere Frage - Wofür braucht man das? Ich kann mir derzeit kein Anwendungsbeispiel dazu vorstellen.

[Pinhead]

Mir ist nicht genau klar was eigentlich geschehen soll. Daher kann ich auch nicht sagen ob es eine andere Möglichkeit gibt.

Was für Funktionen sollen den übergeben werden.

Wer entscheidet welche Funktion aufgerufen wird.

Warum müssen die Funktionen einer anderen Funktion übergeben werden und werden nicht direkt gestartet ?

[jghj]

alsoooo.... ;-)

ich schreibe mir gerade eine kleine applikation, die ein dynamisches Navigationsmenü haben soll.

Dafür hab ich eine kleine klasse geschrieben und füge die "links" folgendermaßen ein:

nav.add( "Value", [funktionsreferenz] );

so. Jetzt wird die navigation dargestellt mit dem Text "Value", und beim klick darauf soll eben die Funktion der [funktionsreferenz] aufgerufen werden.

[Pinhead]

Ok...wird klarer

In dem Fall würde ich das Interface des ActionListeners empfehlen.

In deinem Navigationmenü weist du dann jedem Eintrag ein ActionCommand zu.

Und die actionPerformed Methode prüft dann das empfangene ActionCommand und führt die entsprechende Funktion aus

[jghj]

an diese möglichkeit hab ich auch schon gedacht. Aber die fand ich eben nicht sehr schön wegen dem overhead durch die extra namensvergabe für aktionen, und dann muss man da wieder durchswitchen und des richte raussuchen ;-)

[Aiun]

du kannst auch, wie oben beschrieben, für jede Funktion eine Klasse schreiben und die mitgeben. Dann musst du eben nicht durchswitchen.

Ein "Funktionsaufruf" durch Pointer ist schlicht keine Objektorientierung. Da kommst du schnell in teufels Küche mit. Also ich würde dir eher empfehlen, jede mögliche Aktion in eine Klasse zu packen.

[Bubble]

kommst du schnell in teufels Küche mit. Also ich würde dir eher empfehlen, jede mögliche Aktion in eine Klasse zu packen.

In C# gäbe für diesen Zweck delegates.

In Java könnte man einen Weg über ein Interface oder eine Klasse gehen, ober eben mittels ActionListener. Alternativ im Web nach Implementierungen für C#-delegate-ähnliches Verhalten in Java suchen.

[ksg9-sebastian]

Über Reflection ist das teilweise machbar...

du könntest eine Klasse erstellen welche nur für die Navigation zuständig ist, diese enthält sämtliche Methoden, z.b. void showIndex, void showForum u.s.w.

Dann erstellst du dir ne ReflectionHelper-Klasse welche ein Objekt der Navigation-Klasse und die Methode die aufgerufen werden soll übergeben bekommt (Die Methode per Name als String).

Und dann eben mit der ReflectionAPI die Methode ausführen, evtl. noch Parameter mitgeben.

Gruß

[perdian]

ich weiß in java gibt es nicht wirklich pointer. Aber intern muss es ja mit pointern arbeiten.

Nein, Pointer sind in richtiger objektorientierter Programmierung unnötig. Letzten Endes ist alles ein Objekt, und daher kann man auch eigentlich alle Abläufe damit behandeln. Das von dir angesprochene Konzept eines Funktionszeigers wird in der objektorientierten Programmierung durch das Delegate Pattern abgebildet. Hierzu wird ein Interface oder eine Klasse als Basisklasse verwendet, die in irgendeiner Art und Weise eine Schnittstelle (= eine Methode) definiert, die von der ausführenden Instanz aufgerufen wird. Durch Vererbung kann dann der Delegate Instanz selber jeder beliebige Ausführungsfluss gegeben werden.

ich mein ich kann ja nit für jede Funktion ne eigene Klasse stricken, da hab ich dann 50 klassen mit fast keinem inhalt..

Das ist durchaus normal. Gerade bei GUI Projekten hast du in der Regel eine ganze Reihe von Klassen, die für sich genommen so gut wie keinen Inhalt haben, allerdings trotzdem vorhanden sind.

Ein Beispiel für so etwas wäre bieten sich immer Zugriffe auf den EventDispatcher Thread, also so etwas in der Art:

package xx;


import java.awt.BorderLayout;


import javax.swing.JFrame;

import javax.swing.JLabel;

import javax.swing.JPanel;

import javax.swing.SwingUtilities;


public class EventDispatcherExample {


  public static void main(String[] args) {


    final JLabel label            = new JLabel("START");

    final JPanel contentPane      = new JPanel(new BorderLayout());

    contentPane.add(label, BorderLayout.CENTER);


    JFrame frame                  = new JFrame();

    frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);

    frame.setSize(200, 150);

    frame.setContentPane(contentPane);

    frame.setLocationRelativeTo(null);

    frame.setVisible(true);


    // Thread starten und Zeit ausgeben

    new Thread() {

[color=blue]      public void run() {

        while(true) {

          try {


            // GUI updaten

            SwingUtilities.invokeLater(new Runnable() {

[color=green]              public void run() {

                label.setText(new java.util.Date().toString());

              }[/color]

            });


            // Warten

            Thread.sleep(1000);


          } catch(InterruptedException e) {

            // Ignore

          }

        }

      }[/color]

    }.start();


  }


}

Alles definiert in einer Klassendatei. Durch die Verwendung von anonymen inneren Klassen (der Thread + die Runnable Impementierung zum Zugriff auf den EDT) erzeugen folgende Klassen (die Farben zeigen dabei an, welcher Codebereich durch welche Klasse hinterher im Bytecode repräsentiert wird).

EventDispatcherExample.class

EventDispatcherExample$1.class

EventDispatcherExample$1$1.class

Über Reflection ist das teilweise machbar...

Machbar ja - aber kilometerweit am eigentlichen Ziel vorbei. Bei jeder Verwendung von Reflection sollte man sich vorher immer überlegen: Geht das nicht auch anders? Durch Reflection-Aufrufe verliert das Programm nämlich nicht nur an Performance (das ist in der Regel zu verschmerzen) sondern an allererster Stelle massiv an Übersichtlichkeit. Reflection ist ein Feinmechanikerwerkzeug und sollte daher auch nur fein dosiert eingesetzt werden und nicht bei jedem Problem direkt als "damit kann man das auch machen" Lösung präsentiert werden.

[ksg9-sebastian]

Machbar ja - aber kilometerweit am eigentlichen Ziel vorbei. Bei jeder Verwendung von Reflection sollte man sich vorher immer überlegen: Geht das nicht auch anders? Durch Reflection-Aufrufe verliert das Programm nämlich nicht nur an Performance (das ist in der Regel zu verschmerzen) sondern an allererster Stelle massiv an Übersichtlichkeit. Reflection ist ein Feinmechanikerwerkzeug und sollte daher auch nur fein dosiert eingesetzt werden und nicht bei jedem Problem direkt als "damit kann man das auch machen" Lösung präsentiert werden

Ääähm..ja, natürlich ist Reflection die letzte Lösung die ich benutzen würde, aber so wie er es beschrieben hat die einzige Möglichkeit.

Interfaces will er nicht(ich nehm mal an dass er mit nem Prototyp ein Interface meinte) und deshalb bleibt nichtmehr viel übrig.

Folgende Lösung würde ich vorschlagen:

Ein Interface (Action) welches nur ne actionPerformed(x, y, z)-Methode hat. Für jeden Navigationspunkt eine eigene Klasse welches das Action-Interface implementiert. Eine Mapping-Datei, in der nur drinsteht welcher String auf welche Klasse gemappt wird (notfalls auch direkt im Code per Map realisierbar).

Map mapping = new HashMap();

mapping.put("index", de.navi.IndexAction);

mapping.put("forum", de.navi.ForumAction);

.

.

Und dann eben eine Klasse um die Mappings aufzulösen (MappingResolver). Die Klasse erhält die angeforderte Seite als String und holt sich aus der Mapping-Map/Mapping-Datei die entsprechende Klasse. Dann ein Objekt dieser gefundenen Klasse erzeugen, das ganze auf auf "Action" casten (das Interface) und eben die performAction vom Interface ausführen.

private Map<String, Class> mapping = new HashMap<String, Class>();

.

.

public void gotoPage(String target){

   Class clazz = null;

   if((clazz = mapping.get(target)) != null){

      Action iAction = (Action)clazz.newInstance();

      action.performAction();

   }

}

Ist zwar am anfang bissl komisch, grade weils viele "leere" Klassen gibt, aber ist die einzige wirklich saubere Lösung. Auserdem ist es von der Wartung her klasse. Neue Sachen hinzufügen u.s.w. hast du kaum Aufwand, lediglich

- Neue Klasse erzeugen (implements Action)

- String in Mapping-Map/Mapping-Tabelle eintragen

- Navigationspunkt hinzufügen

Das ist wunderbar so...mach ich auch fast immer so.

Gruß

seb

[perdian]

die ich benutzen würde, aber so wie er es beschrieben hat die einzige Möglichkeit.

Das sehe ich anders. Es geht hier um Planung und Strukturierung zur Entwicklungszeit. Reflection macht allerdings nur dann wirklich Sinn, wenn sich erst zur Laufzeit bestimmte Parameter ändern bzw. erst ergeben, die einen Einfluss auf die Klassengestaltung an sich haben. Wie gesagt: Es gibt viel weniger Fälle, wo man tatsälich Reflection einsetzen muss, als es auf den ersten Blick den Anschein macht.

Interfaces will er nicht

Woraus folgerst du das denn?

Und selbst wenn jemand etwas auf den ersten Blick nicht will heisst doch noch lange nicht, dass man nicht durch eine überzeugende Argumentation rüberbringen kann: "Doch, genau das ist der richtige Weg". Wenn mir ein neuer Kollege ankommt und aufgrund von mangelnden Designkenntnissen und mangelnder Kenntnis von objektorientierter Programmierung alles direkt mit Reflection erschlagen will, der kann direkt vergessen irgendwelche verantwortungsvollen Aufgaben an einem Projekt übertragen zu bekommen, bis er nicht die nötigen Grundlagen beherrscht.