Discussion :

[vinzzzz]

Hello,

Dans un projet JAVA que j'ai récupéré et que je vais continuer de développer sous netbeans, il y a une erreur que j'aimerai faire disparaitre. Je m'explique:

Suivant la présence ou non d'un certain package P, on instancie une classe A si celui ci est présent, B si non.

Le problème se situe dans le fait que dans le code définissant la classe A, on utilise les packages, classes et méthodes existantes dans le package P. Or lorsque celui-ci est absent, une erreur est (assez logiquement je trouve) renvoyée par netbeans m'informant qu'il ne trouve pas tel package, telle classe, telle méthode etc...

Bref, manifestement, ca n'a pas du poser problème a l'ancien développeur pour faire marcher le soft... mais j'aimerai bien éviter d'avoir ce genre de chose, et ma question est la suivante:

y'a t-il un moyen d'éviter ce genre d'erreur? Je pense par exemple a un équivalent du #define en C, ou tout autre méthode existante...

Je viens de me remettre au JAVA, j'en ai beauocup fait avant mais je ne me souviens pas d'une telle possibilitée...

Merci d'avance!

[dinobogan]

Il faut faire une instance dynamique. Par contre, pour une meilleure souplesse d'utilisation, il faut une interface commune entre A et B.

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
Class<MonInterfaceCommune> clazz = null;
 
try
{
  clazz = (MonInterfaceCommune)Class.forName( "package.complet.A" );
}
catch( ClassNotFoundException exc )
{
  try
  {
    clazz = (MonInterfaceCommune)Class.forName( "package.complet.B" );
  }
  catch( ClassNotFoundException exc )
  {
    ... traitement de l'erreur car ni A ni B ne sont dispo ...
  }
}
 
if( clazz != null )
{
  MonInterfaceCommune instance = clazz.newInstance();
  instance.uneMethode();
}

Il reste encore à catcher les autres exceptions, mais le principe est là.
Si tu ne veux pas utiliser une interface commune, il faut appeler les méthodes dynamiquement via "getMethod" sur ton instance.

[vinzzzz]

Hum oui je vois le genre... A la base mes deux classes A et B héritent d'une classe mère, mais par contre elles ont des méthodes différentes.

En tout cas le problème subsiste si par exemple je déclare une variable d'instance provenant du package de la classe A non? Si par exemple la classe A appartient au package P.p1 et qu'elle contient une variable d'instance appartenant a P.p2...

Merci de ton aide en tout cas...


Edit: En effet c'est plutôt ca mon problème je me suis mal exprimé: mes classe A et B ont été crée par le développeur et sont bien instanciées comme je l'ai indiqué, sous condition. Simplement pour A, il existe des variables qui appartiennent au package qui n'est pas suceptible d'être présent, et donc lorsque ce n'est pas le cas, les noms de classes ainsi que les méthodes associés a ces variables ne sont pas reconnues...

[dinobogan]

Edit: En effet c'est plutôt ca mon problème je me suis mal exprimé: mes classe A et B ont été crée par le développeur et sont bien instanciées comme je l'ai indiqué, sous condition. Simplement pour A, il existe des variables qui appartiennent au package qui n'est pas suceptible d'être présent, et donc lorsque ce n'est pas le cas, les noms de classes ainsi que les méthodes associés a ces variables ne sont pas reconnues...

Il faut supprimer toutes les références en dures aux classes A et B. Si A et B dérivent d'une même classe, alors tu peux caster l'instance dynamique par cette classe mère, et utiliser les méthodes ce la classe mère.

[vinzzzz]

Hum je crois que je ne me suis aps bien fait comprendre. Exemplifions ma classe A:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Class A extends Top 
{
    private p.p1.c1 var ;   // Ici, si P est inconnu, il y a une erreur
    ...
 
    public A ()
    {
        ...
        var = new p.p1.c1() ;  // Erreur, connait pas la classe...
        var.method(15) ;       // Idem, comme il ne sait pas ce qu'est var, il ne connait pas methode
    }
}

Voilà concrètement à quoi ressemble mon problème: j'aimerai garder ce principe, en supprimant les erreurs.

J'ai regardé du coté de la classe Class. Est-ce que ce genre de chose pourrait régler le problème:

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
 
Class A extends Top 
{
    private Object var ;   // On le met en tant qu'objet
    ...
 
    public A ()
    {
        ...
        // On l'instancie de manière indirecte
        var = Class.forName("p.p1.c1").newInstance() ; 
 
        // On appele les méthodes de c1 de cette manière
        var.getClass().getMethod("method", Integer.class).invoke(var, 15) ;
    }
}

Comme ceci ca me semblerai bon, mais le fait qu'on assigne a var le type Object me chifonne... Qu'en pense-tu?

[dingoth]

J'en pense que c'est laid.

Faire des method.invoke à tout bout de champ, c'est bon pour certains frameworks utilisant des fonctions avancées, mais je doute sincèrement que ce soit vraiment ton besoin.

Tu dois repenser ta manière de procéder et utiliser une méthode semblable à celle que Dinogoban propose.