Discussion :

[ToTo13]

Bonjour,

comme le titre l'indique, je souhaiterai instancier dynamiquement des classes.
J'ai donc un fichier Xml qui contient (par exemple) le nom (complet) de la classe à instancier ainsi que la valeur des paramètres à utiliser.

J'ai donc commencé par lire ces tutoriels pour apprendre la programmation Java (dont l'incontournable jmdoudoux en java) : http://java.developpez.com/cours/

Mais le dernier exemple me laisse perplexe, car dans l'appel

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
MaClasse instance = constructeur.newInstance(new Object[] {Boolean.FALSE, "nom instance" }) ;

il semblerait que cette instanciation se fasse en connaissant déjà la nature de la classe. Si c'est le cas, on perd totalement en généricité et je ne veux pas cela.

Donc mes questions sont :
- est ce que je n'ai pas compris du tout l'exemple en question ?
- si tel est le cas, comment pourrais je instancier la classe suivante ? Par exemple :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

<malib.monpackage.maclasse Param1="val1" Param2="val2" />

Si ce que je veux faire n'est pas possible de manière générique, alors la seule solution que je vois, c'est d'avoir une méthode dans chaque classe qui retournerait une instance en fonction du noeud correspondant dans le fichier Xml. Mais comme je ne connais pas les classes en question, il faudrait que ces classes aient toutes un constructeurs vide/inutile servant juste à une instanciation bidon, pour pouvoir appeler la méthode qui génèrerait la bonne instance en fonction des paramètres.
Mais je trouve cette histoire d'instanciation bidon, vraiment bidon ! Bien que cela se fasse d'instancier une classe en attendant d'avoir ses paramètres et donc de la définir réellement.

Merci par avance pour votre aide.

[joel.drigo]

Salut,

Tu peux obtenir une classe à partir de son nom sous forme de String avec la méthode forName() de Class, comme dans cet exemple de principe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
String nomDeClasse=...  // que tu lis par exemple dans ton xml
try {
   Class<?> clazz = Class.forName(nomDeClasse);
 
   // ensuite on peut récupérer un constructeur :
 
   Class<?>[] parameterTypes = ... // on créer un tableau de classes, toujours avec Class.forName() et les types lus dans le xml
    try {
           Constructor<?> constructeur = clazz.getConstructor(parameterTypes);
 
           // on crée ensuite la liste des paramètres du constructeur
           Object[] initargs = ...;  // la il faudra appeller le même type de code que celui ci, pour créer dynamiquement les instances, et éventuellement faire des fabriques pour les types standards de java, en particulier les types primitifs
           try {
	        Object instance = constructeur.newInstance(initargs);   
 
                // on a une instance de la classe, constructible entièrement à partir de String
 
 
           } catch (InstantiationException | IllegalAccessException
						| IllegalArgumentException | InvocationTargetException e) {
                 // erreur si on ne peut instancier
                 e.printStackTrace();
          }
 
      } catch (NoSuchMethodException | SecurityException e) {
           // erreur si on ne peut récupérer le constructeur
           e.printStackTrace();
      }
 
 
} catch (ClassNotFoundException e) {
   // ERREUR si la classe n'a pas été trouvée
   e.printStackTrace();
}

Ensuite, pour la problématique des paramètres du constructeur, il vaudrait mieux indiquer leur type dans le xml. Mais, si ce n'est pas le cas, il faudrait procéder par recherches successives : tu récupères tout les constructeurs, et tu cherches celui qui matche le mieux tes paramètres en fonction des possibilités de conversion. Le problème est s'il y a plusieurs possibilités et aucune condition de priorité.

[ToTo13]

Merci pour la réponse et l'exemple.
J'avais fait tourner (avec succès) quelque chose de similaire, mais j'avais bloqué au niveau de la généricité pour les paramètres du constructeur.

J'ai l'impression que mettre le type des paramètres dans le Xml rend la chose lourde :s. De plus, certains paramètres peuvent être des pointeurs vers des classes.

[joel.drigo]

Oui, je suis d'accord que ça peut rendre lourd le xml d'indiquer les types, mais, à l'inverse, cela peut rendre l'instanciation assez lente de tenter de résoudre la conversion de chaque paramètre pour tenter de matcher un des constructeurs possibles.

Je pense également à un problème possible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class MaClasse {
 
   public MaClasse(String s) {
   }
   public MaClasse(int i) {
   }
 
}

<MaClasse param1="123">

Malgré le fait que le paramètre soit manifestement un int, on peut vouloir absolument instancier par le constructeur avec argument String. Le type du paramètre pourrait être optionnel, afin d'évier d'alourdir systèmatiuement, mais pour permettre le cas.

J'ai fait une classe qui permet de convertir une chaîne de caractères en valeur pour les types primitifs, leur type classe correspondant, les enums, et le type String : on peut utiliser cette classe par essais successifs pour tenter de matcher les types des paramètres de chaque constructeur, afin de détecter les constructeurs susceptibles d'être utilisés pour la liste de paramètres fournis, dans un code du type suivant, par exemple (la méthode decodeParameters() faisant ce travail) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
/**
 * 
 */
package proj1;
 
import java.lang.reflect.Constructor;
import java.util.HashMap;
import java.util.Map;
 
/**
 * @author Joël
 *
 */
public class POCFabriqueDynamique {
 
	public Object createInstance(String className, String[] params) throws ClassNotFoundException {
 
		Class<?> klazz = Class.forName(className);
 
		Map<Constructor<?>,Object[]> compatibleConstructors = new HashMap<>();
		for(Constructor<?> constructor : klazz.getConstructors()) {
 
			if ( constructor.getParameterTypes().length==params.length ) {
				// constructeur possible
				// on cherche si les types sont compatibles :
				Object[] parameterValues = decodeParameters(params, constructor.getParameterTypes());
				if ( parameterValues!=null ) {
					// constructeur compatible
					compatibleConstructors.put(constructor, parameterValues);
				}
			}
 
		}
 
		if ( compatibleConstructors.isEmpty() ) {
			// aucun constructeur compatible
			throw new NoSuchMethodException();
		}
		else if ( compatibleConstructors.size()==1 ) {
			// un constructeur compatible : on utilise celui là
			for(Map.Entry<Constructor<?>,Object[]> entry : compatibleConstructors.entrySet() ) {
				return entry.getKey().newInstance(entry.getValue());
			}
		}
		else {
			// plusieurs constructeurs compatibles
			// déterminer un algo de choix (ou erreur, ou autre...)
		}
 
	}
 
	public static void main(String[] args) {
 
		Object instance = createInstance("java.lang.String", new String[]{"value"});
 
	}
 
}

Pour les types qui ne sont pas "standard", je pense qu'il faudrait au moins ajouter une sorte d'id dans la définition d'une instance.

J'ai travaillé sur un serveur qui fonctionnait par injection, dans lequel chaque instance était identifiée par un nom (dans un espace de nom), qu'on pouvait référencer soit directement pour utiliser l'instance, soit indirectement, pour obtenir un clone, ou avoir un fonctionnement de type fabrique, ou pool.

Le xml de définition d'une instance pourrait devenir :

<malib.monpackage.maclasse instanceId="xxx" Param1="val1" Param2="val2" />

et un xml de référence pourrait faire :

<malib.monpackage.maclasse2 instanceId="yyy" Param1="val1" Param2="truc:malib.monpackage.maclasse/xxx" />

L'uri est indicative, bien sûr Reste à bien penser à la gestion des dépendance (gestion de l'ordre d'instanciation).

Cela dit, personnellement je préférerais avoir le nom de la classe en attribut, plutôt qu'en nom d'élément. En particulier si tu veux pouvoir référencer des classes internes statiques, qu'il faudra référencer sous la forme malib.monpackage.maclasse2$classeinterne : or le $ ne passera pas dans le nom d'élément.



Je peux te fournir le source de cette classe de conversion, si cela t'intéresse.

[tchize_]

En gros, tu refait ce que spring fait déjà: créer des classe à partir de leur nom avec des paramètres pour les constructeurs

C'est pas une mince affaire:

1) tu dois identifier le type de tes paramètres dans le xml et les possibilité de convertion
2) tu dois identifier tous les constructeurs (Class.getConstructors()) ayant le même nombre de paramètres (getParameterTypes()). Heureusement, en général, il y en a qu'un poignée
3) tu dois discriminer entre ces constructeur pour trouver celui qui s'adapte le mieux à tes paramètres, idéalement en suivant les même règles que dans le java language specifications


PS: définir les type des paramètres directement dans le xml risque d'être de toutes façons plus complexe que d'analyser dynamiquement

[ToTo13]

Merci pour vos réponses / exemples.
C'est effectivement un peu lourd au niveau des paramètres et de leurs types.

En attendant les réponses, j'avais fait une solution (hybride ?) :
- toutes mes classes potentiellement instanciables ont un constructeur vide (qui ne fait qu'une instance basique) et un constructeur complet (tous les paramètres).
- elles ont également une méthode Parameters(Object[] parameters) qui prend les mêmes paramètres que le constructeur complet et qui peut terminer l'instanciation. Donc Constructor()+Parameters(...) = Constructor(...)
- toutes ces classes implémentent une interface Xml qui a une méthode Xml(Element element), qui analyse le noeud, connaît le type des paramètres (en fonction de leur nom ou autre), etc. et appelle Parameters() (donc qui finit l'instanciation).
- donc je peux alors appeler dans l'ordre :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
     Class<?> clazz = Class.forName(nomDeClasse) ;
     Object instance = clazz.newInstance() ;
     ((Xml)instance).Xml(monelementjdom) ;

Je n'ai qu'une seule instanciation par classe, c'est générique car définit grace à une interface.
Est ce que cela paraît cohérent ?

[tchize_]

alors, on ne nomme pas une méthode en commençant par une majuscule, donc ca devrais être xml(....) et pas Xml(....)

Ensuite, si tu veux faire comme ça, le plus simple serait de forcer toutes tes classes à avoir un constructeur prenant en paramètre le xml, non?

La question que je me pose surtout c'est de connaitre ton but. Parce que là, tu redéfinit soit la manière dont spring charge (=> utilise spring beans) soit la manière dont bxml charge des arbres d'objet (=> utilise bxml)

[ToTo13]

alors, on ne nomme pas une méthode en commençant par une majuscule, donc ca devrais être xml(....) et pas Xml(....)

Ou pas... j'ai pris l'habitude de mettre des majuscules partout...

Ensuite, si tu veux faire comme ça, le plus simple serait de forcer toutes tes classes à avoir un constructeur prenant en paramètre le xml, non?

Oui, mais pour cela il faudrait que je passe par une classe abstraite car je ne peux faire ce genre de forcing avec une interface (ce que j'utilise actuellement).

La question que je me pose surtout c'est de connaitre ton but.

Je viens de créer une Convolutional Neural Network (CNN). Comme il a besoin d'être entrainé et que c'est TRES long, il me faut absolument sauvegarder son état (architecture + poids) à la fin de l'entrainement. Ce que j'ai fait au format Xml.
Puis pour l'utiliser, il me faut charger le fichier Xml et reconstruire exactement le même CNN. Mais je veux faire des instanciations génériques, car 1/ je n'aime pas les usines à gaz spécifiques et 2/ j'ai de nombreuses couches/architectures différentes.

[tchize_]

Oui, mais pour cela il faudrait que je passe par une classe abstraite car je ne peux faire ce genre de forcing avec une interface (ce que j'utilise actuellement).

De la même manière que tu ne peux pas forcer l'existence du constructeur vide Et même avec un class abstraite, on hérite pas des constructeurs donc....
Ce n'est pas un problème de poser ça comme convention à priori.

Je viens de créer une Convolutional Neural Network (CNN). Comme il a besoin d'être entrainé et que c'est TRES long, il me faut absolument sauvegarder son état (architecture + poids) à la fin de l'entrainement. Ce que j'ai fait au format Xml.

Pourquoi tu ne passe pas par xstream ou jaxb dans ce cas? Ca permet de sérialiser tes classe sans avoir à créer toute l'usine pour sérialiser / désérialiser. tu réinvente la roue. Xstream est souple, tu peux sans grande difficulter même renommer les tags qui te plaisent pas, ignorer certains attributs, etc...

[joel.drigo]

Il y a la solution mise en place dans Eclipse RCP qui peut être intéressante à regarder à ce sujet.

• Avantages
  
  • très simple à mettre en oeuvre (il suffit d'implémenter une ou 2 interfaces, ayant chacune une méthode)
  • très simple à paramétrer (une instance se paramètre par exemple : monpackage.maclasse:1,2,truc,bidule
• Inconvénients
  
  • oblige le développeur de la classe à implémenter le décodage des paramètres, et certaines conditions d'instanciation dans des cas particuliers
  • oblige d'avoir un constructeur sans paramètre, (mais permet , quand même, éventuellement d'avoir un moyen de faire des instances non mutable),

Le système est fondé sur 2 interfaces :

• org.eclipse.core.runtime.IExecutableExtension
• org.eclipse.core.runtime.IExecutableExtensionFactory

La première permet l'initialisation d'une instance avec des paramètres.
La seconde permet d'instancier (en fait l'objet est instancié une première fois, par le constructeur sans paramètre, puis la méthode de l'interface est appelée pour créer l'instance finale, ce qui permet de soit la renvoyer telle qu'elle, soit la modifier avant, soit d'en faire un clone, la wrapper dans un proxy, de retourner un singleton, etc.).

[ToTo13]

Merci pour vos réponses.
On dirait que j'ai tout ce qu'il me faut.

[ToTo13]

XStream semble faire parfaitement le travail souhaité !