HeeroYuhi
Messages postés8Date d'inscriptionmercredi 20 mars 2002StatutMembreDernière intervention21 février 2008 21 févr. 2008 à 08:48
Salut,
Je pensais que java faisait comme C++ pour les attributs de classes, qu'il les rendait automatiquement private.
Pour le second point, je ne vois pas en quoi mon loader est dépendant de ma couche métier. Peut-être parles-tu de la classe PlugInStorage. Mais cette classe ne stocke aucune info spécifique à mes plugins, elle permet juste de faciliter le stockage, le tri et la recherche d'élément (cf PlugInStorage.java, dans le zip).
Je pense intégrer le chargement de classe à partir d'un .jar, mais pour mon projet (qui nécessitera des ajouts réguliers de plug-in) il est plus aisé de charger des .class indépendant. Je ne sais pas si je me suis fais comprendre, mais en gros, si on prend l'exemple du PlugedPlane, il faudra que j'ajoute régulièrement de nouveaux avions.
Merci pour tes remarques.
Twinuts
Messages postés5375Date d'inscriptiondimanche 4 mai 2003StatutModérateurDernière intervention14 juin 2023111 20 févr. 2008 à 18:22
Salut,
"Tu pourrais préciser le coup de la restriction de portée?"
> Je parle du qualifieur 'private' sur tes variables globales afin d'éviter les trous de secu
Pour le cas du chargement de plugin bah c'est assez simple:
Tu sépares le chargement du byte code de ta couche métier (chargement du plugin) en mettant au point une sorte de jarloader (chargement des classes d'un jar en fonction d'un entry point du fichier manifest) rien de plus. En gros cette classe permet simplement de charger le byte code des classes java se trouvant dans un jar et de pouvoir créer des instances d'objet, des invoke sur les méthodes de celui-ci, etc...
Ensuite tu peux y ajouter ta couche métier en incluant ton template de plugin... et ainsi éviter une dépendance entre le loader et la couche métier, afin de rendre le loader le plus générique possible.
HeeroYuhi
Messages postés8Date d'inscriptionmercredi 20 mars 2002StatutMembreDernière intervention21 février 2008 20 févr. 2008 à 17:51
Bonjour,
Pour les règles de nommage, je m'excuse mais je commence juste le java et je viens du monde C++.
Tu pourrais préciser le coup de la restriction de portée?
De même pour le type générique?
Il me semble que je n'impose pas de type particulier. Il faut juste que les classes plug-in hérite d'une mère définie en interne dans le programme afin de pouvoir accéder aux méthodes.
J'aurais pu mettre en place un chargement dynamique des méthodes, mais cela ne me sert à rien dans mon projet.
Twinuts
Messages postés5375Date d'inscriptiondimanche 4 mai 2003StatutModérateurDernière intervention14 juin 2023111 20 févr. 2008 à 13:59
Salut,
ne voyant rien d'assez pechu, je repasse le code en débutant
ptites remarques :
1 - Tu aurais quand même pu repsecter un minimum les règles de nommage de sun et ne pas mettre des majuscules à toutes tes méthodes et noms de variables....
2 - Tu aurais pu mettre une restriction sur la portée de tes variables globales...
3 - Tu aurais pu faire en sorte que ton code charge un plugin de type générique, sans imposer une classe précise afin de déléguer la couche métier à un moteur de plugin...
21 févr. 2008 à 09:57
afin de mieux me faire comprendre, regarde sur cette source (1) et interrese toi à la classe JarLoader (2)
(1) -> http://www.javafr.com/codes/MOTEUR-PLUGIN_44098.aspx
(2) -> http://files.codes-sources.com/fichier.aspx?id=44098&f=Moteur+de+plugin\Admin+PlugIn+version\src\com\daedric\lang\jar\JarLoader.java
21 févr. 2008 à 08:48
Je pensais que java faisait comme C++ pour les attributs de classes, qu'il les rendait automatiquement private.
Pour le second point, je ne vois pas en quoi mon loader est dépendant de ma couche métier. Peut-être parles-tu de la classe PlugInStorage. Mais cette classe ne stocke aucune info spécifique à mes plugins, elle permet juste de faciliter le stockage, le tri et la recherche d'élément (cf PlugInStorage.java, dans le zip).
Je pense intégrer le chargement de classe à partir d'un .jar, mais pour mon projet (qui nécessitera des ajouts réguliers de plug-in) il est plus aisé de charger des .class indépendant. Je ne sais pas si je me suis fais comprendre, mais en gros, si on prend l'exemple du PlugedPlane, il faudra que j'ajoute régulièrement de nouveaux avions.
Merci pour tes remarques.
20 févr. 2008 à 18:22
"Tu pourrais préciser le coup de la restriction de portée?"
> Je parle du qualifieur 'private' sur tes variables globales afin d'éviter les trous de secu
Pour le cas du chargement de plugin bah c'est assez simple:
Tu sépares le chargement du byte code de ta couche métier (chargement du plugin) en mettant au point une sorte de jarloader (chargement des classes d'un jar en fonction d'un entry point du fichier manifest) rien de plus. En gros cette classe permet simplement de charger le byte code des classes java se trouvant dans un jar et de pouvoir créer des instances d'objet, des invoke sur les méthodes de celui-ci, etc...
Ensuite tu peux y ajouter ta couche métier en incluant ton template de plugin... et ainsi éviter une dépendance entre le loader et la couche métier, afin de rendre le loader le plus générique possible.
20 févr. 2008 à 17:51
Pour les règles de nommage, je m'excuse mais je commence juste le java et je viens du monde C++.
Tu pourrais préciser le coup de la restriction de portée?
De même pour le type générique?
Il me semble que je n'impose pas de type particulier. Il faut juste que les classes plug-in hérite d'une mère définie en interne dans le programme afin de pouvoir accéder aux méthodes.
J'aurais pu mettre en place un chargement dynamique des méthodes, mais cela ne me sert à rien dans mon projet.
20 févr. 2008 à 13:59
ne voyant rien d'assez pechu, je repasse le code en débutant
ptites remarques :
1 - Tu aurais quand même pu repsecter un minimum les règles de nommage de sun et ne pas mettre des majuscules à toutes tes méthodes et noms de variables....
2 - Tu aurais pu mettre une restriction sur la portée de tes variables globales...
3 - Tu aurais pu faire en sorte que ton code charge un plugin de type générique, sans imposer une classe précise afin de déléguer la couche métier à un moteur de plugin...