Du genre tableau de pointeur sur fonctions du C ou C++

Pas de pointer en Java  
Fait un tableau d'objet

Oui, on peut, sinon, mais bon, c'est un peu galère...Les objets Class, Method, etc, existent das l'API Java, mais tu devrais pouvoir t'en passer en utilisant l'héritage, les interfaces, etc, non??  
C'est pour quoi faire, que tu voulais stocker ça??

J'ai essayé avec un tableau d'Object mais sans succès ? :
 
ex :  
 
private Object [] monTableau = {Employe.getNomEmp()};
 
Ne passe pas la compilation :  
d:\javasrc\societe\ihm\NewEmploye.java:60: non-static method getNomEmp() cannot be referenced from a static context
 private Object [] monTableau = {Employe.getNomEmp()};
 
L'intérêt est d'économiser du code :
J'ai un tableau de composants(widgets) Object [m][n] composants dans lequel sont renseignés toutes les caractéristiques de mes composants à créer et afficher.
 
Les composants sont essentiellement des Labels et TextField que je crée ainsi :
 
...
while(n != composants.length){
        panelRow.add(new  Label((String)composants[n]) );
 panelRow.add(new  TextField( ((Integer)composants[++n]).intValue() ) );
 n++;
}
...
m étant l'indice de la 2ème dimension de mon tableau, composants  
 
Jusque la pas de problème mais maintenant je dois mettre dans mes TextField des attributs d'objets.      
Pour ce faire chaque objet hérite d'une classe mère, des méthodes qui renvoyent les attributs communs à tous les objets et ce sont ces méthodes que je désirerais stocker et appeler en fonction de l'indice m de mon tableau composants.
 
Est ce clair ?

non ce n'est pas clair.
 
par contre, ce qui est clair c'est que le problème à la compile, c'est une erreur de débutant : tu essayes d'apeller une méthode d'instance comme une méthode static. Le message du compilo est plutot clair ...
 
sinon, regarde du côté de java.lang.Class (pour récupérer les méthodes d'un objet) et java.lang.reflect.Method (pour les utiliser)

Et bêtement, tu peux pas faire une méthode de ta classe mère qui serait, par exemple :  
 
Object getAttribute (int m)
(et éventuellement setAttribute(int i, Object o);
 
Ca me paraît beaucoup moins compliqué (et beaucoup plus performant) que d'utiliser la reflexivité, non?

oui

Ok pour le pb de stockage de méthodes dans un tableau. J'ai essayé sans réfléchir, je viens de me fouetter 15 fois !  
 
Sinon faire une méthode générique pour obtenir mes attributs me paraît effectivement beaucoup + simple.
J'y avais même pensé ce matin, je vous jure que c'est vrai !
 
Merci

moi j'aime pas trop.
 
Une bonne introspection et ca roule ! qu'est ce que tu en as à péter de l'eficacité : tu fais du swing !

Pourquoi donc ?
Introspection ?
Sinon mon projet, cas d'école, n'est pas en swing mais awt(pas le choix).

benou a écrit a écrit :   moi j'aime pas trop.   Une bonne introspection et ca roule ! qu'est ce que tu en as à péter de l'eficacité : tu fais du swing !

 
Ouais, enfin bon...De toutes façons, il sera toujours embêté pour faire l'association numéro-> méthode ou attribut..Et à moins de stocker ces associations dans uyn fichier de config, et donc, de pouvoir la modifier sans recompiler, le reflexivité n'a pas vraiment d'intérêt : entre mettre des nms de méthode en dur (parce que TOUTES les méthodes de son objet ne sont peut être pas à associer à un index), et créer une méthode qui récupère le bon attribut à partir de l'index, y'a pas de différence fondamentale de quantité de code à pondre..
 
Perso, je suis partisan de la reflexivité, uniquement dans des cas où on ne connaît pas une classe à instancier, ou une méthode à appeller, et que cette info est susceptible de changer en fonction de l'utilisation...Par exemple, j'ai fait un serveur de chat, qui peut utiliser différents protocoles...Ben, le nom de la classe qui gère le protocole à utiliser par le serveur (c'est une class qui implémente l'interface Protocol, comme ça, je me fait pas chier) , est mise en configuration, et au démarrage, le serveur fait un p'tit :  
 
Protocol protocol = Class.forName(ServerConf.getProperty("Protocol" )).newInstance();
 
et le tour est joué : je modifie la conf, je redémarre mon serveur, et hop, il a changé de protocole...En dehors de ce genre de cas, franchement, je vois pas bien l'interet de la reflexivité, surtout vu la lenteur du machin!

bof : ce qu'il peux faire par exemple c'est rpednre une convenssion. Par exemple : tous les attributs qu'il souhaite afficher auront une méthode display.
ex pour l'attribut 'machin' :
 
public String displayMachin();
 
ca peut être sympa ...