Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
via Reflections art der verarbeitung der parameter prüfen
ist es möglich herauszufinden ob ein Methodenparameter IN oder OUT-Parameter ist? Zur erklärung: In einer Api sind viele Methoden mit vielen Parametern. Einige von diesen Parametern erwarten einen Input der verarbeitet wird, andere einen Output in dem das verarbeitete gespeichert wird (eine Variable).
Auf die Bibliothek kann ich keinerlei einfluss nehmen.
Ist es nun möglich herauszufinden ob ein Parameter im laufe der Methode verändert wird/etc?
nein, zumindest nicht mit Standardmitteln, könntest dir höchstens einen eigenen Analyser schreiben,
dass ein Parameter geändert wird muss übrigens auch gar nicht mal als OUT zählen,
kann nur zur internen Verarbeitung dienen, Objekt danach vom Aufrufer nicht mehr verwendet
Das ist echt schade. Dann werde ich wohl alle Parameter als inputfelder machen.
Es geht nämlich darum das ein benutzer eine Methode aus der Liste der verfügbaren wählt, testwerte eingibt und die Methode (in diesem fall eher funktion) aufruft und die ergebnisse ausgespuckt bekommt. Gibt es sowas evtl schon beispielhaft?
Wie ich bereits sagte kann ich an der Bibliothek nichts ändern, da sie mir nicht zugänglich ist und das auch nicht Sinn des Programms ist. Neben Java gibt es, seit 100 Jahren oder mehr, auch andere Programmiersprachen und da ist es teilweise üblich als return nur einen Fehler/erfolgswert ausgeben zu lassen. Außerdem kann eine Methode (oder in anderen Sprachen Funktion) ja mehr als nur einen Output liefern.
Das heist der return-Wert ist im normalfall immer 'nur' ein Integer 0/1/2/3 und für mich nicht von Nutzen.
Ich konkretisiere nochmal mein Vorhaben:
Ein User will sehen was Funktionen machen und evt. schnell Testwerte eingeben (Gehen wir davon an der User probiert eine pow-Methode aus). Dafür wählt er aus dem Methodenpool die Methode pow. Das Programm gibt nun ein Fenster aus in dem pow ( INPUTFIELD, INPUTFIELD ) steht. Der Benutzer tippt munter seine Werte ein und klickt auf solve. Solve gibt dann das Ergebnis aus.
Sinn der Applikation ist es, das wenn sie einmal funktioniert nicht mehr geändert werden muss und für alle zukünftigen Methoden funktioniert. Der User gibt immer die gewünschte Funktion, sowie die gewünschten parameter an und das prog sagt ihm was raus kommt.
Neben Java gibt es, seit 100 Jahren oder mehr, auch andere Programmiersprachen und da ist es teilweise üblich als return nur einen Fehler/erfolgswert ausgeben zu lassen.
Sinn der Applikation ist es, das wenn sie einmal funktioniert nicht mehr geändert werden muss und für alle zukünftigen Methoden funktioniert. Der User gibt immer die gewünschte Funktion, sowie die gewünschten parameter an und das prog sagt ihm was raus kommt.
Wie ihr gemerkt hab ist die Bibliothek die ich nutze ursprünglich in C entstanden und wurde nur für Java umgeschrieben. Allerdings habe ich mit der Bibliothek nichts zu tun, nur sollte die Anwendung in möglichst vielen Fällen/Situationen funktionieren und genau deswegen dieser Umstand.
Wenn die Methode komplexe Objekte erwartet und diese nicht bekommt oder generell Objekte des falschen Typs, so werden halt die Errors angezeigt. Genau darum geht es ja auch. Der Benutzer hat und muss keine Ahnung von Java haben. Er probiert einfach nur aus.
Wenn man so will wird das Programm, wenn es denn noch wird ^^, ein Methodenanalyser bzw ein IDE für einzeilne Java-Befehle.
Das verfehlt den Sinn meines Programms komplett, da der Ablauf dann nicht mehr voll automatisch ist und ich dem Programm direkt selbst die Klassen beibringen könnte und somit Fake-Methoden mach könnte, aber wenn sich dann was an der einzulesenden API ändert muss ich mein Programm auch wieder ändern und das ist "doof".
Wenn es echt keinen Weg gibt *schnief* habe ich wohl pech gehabt. Was mir übrig bleibt ist:
1. Bibliothek laden
2. Methoden auslesen
3. Methode vom Nutzer aussuchen lassen
4. für jeden der Parameter der gewählten Methode ein JTextField erstellen
5. Auf Eingabebestätigung warten
6. Methode mit von user eingegebenen Parametern ausführen
7. Methodenresult ausgeben sowie alle zuvor eingegebenen Parameter (vlt hat sich ja an denen was geändert)
Wenn ich das hinbekomme fresse ich nen Besen ^^ Ich bin bei Punkt 3. Bei 4 werde ich die TextFields wohl erst erstellen (pauschal 20 Stück oder so) und je nach Parameteranzahl TextFields sichtbar werden lassen.
Wenn die Argumente nach der Verarbeitung modifiziert sein sollen, dann bedeutet das doch, dass es nicht um primitive Typen und auch nicht um sonstige Immutables wie Strings oder die Wrapper-Typen gehen kann; das funktioniert ja nur mit komplexeren Objekten oder Arrays der einfachen Typen. Wie soll der Anwender denn solche Parameter generisch über ein JTextField eingeben können?
1. Wenn der Nutzer die benoetigten Parameter eingeben soll folgt das er wissen muss, welche Bedeutung diese Parameter haben, dann sollte er auch Wissen, was die Methode macht.
2. Das Verhalten einer Methode kann vom Zustand der Applicationabhaengig sein. Stichwort: Statepattern.
3. Mit Hilfe von try und Error die Funktionsweise einer Methode herauszufinden ist irgendwie nicht besonders sinnvoll.
4. Wenn die API benutzt werden soll und in Java geschrieben wurde muessten die Entwickler doch auch Java Code lesen koennen (sie muessen ihn ja auch schreiben...)
5. Dekompilieren erscheint mir deswegen sinnvoll. Allerdings kenne ich dort nicht die rechtlichen Bestimmungen. Reverse Engineering ist z.B in den meisten Faellen gesetzlich untersagt !!!!!
Also wenn ich recht verstehe ist das Problem das du eine API hast, die weder dokumentiert ist noch sprechende Namen fuer die Funktionen verwendet und die Entwickler dieser API sind auch nicht mehr ansprechbar. Mein dringender Rat tritt die API in die Tonne und suche eine Alternativ API !!!!
