Discussion :

[Jaxofun]

Bonjour !

Problème :
Dans mon application j'utilise une classe statique, c'est à dire qu'elle ne contient que méthodes et attributs statiques.
Depuis mon application à évoluée, et je me rend compte de la nécessité de divisée cette classe en une interface et son implémentation.
Cependant, je voudrais conserver l'appel à des méthodes statiques et c'est ça mon problème, car une méthode abstraite ne peut pas être statique.

Solution trouvée :
Pour resoudre cela j'ai trouvé une solution, j'ai divisé ma classe en deux classes :

Une classe abstraite contenant :
Des méthodes abstraites.
Des méthodes statiques faisant appel aux méthodes abstraites correspondantes.
Un attribut statique, instance de cette classe, utilisé pour l'appel aux méthodes abstraites et instancié avec la classe d'implémentation choisie.

Une classe d'implémentation implémentant les méthodes abtraites de la classe précèdement citée.


Questions sur la solution :
Cette solution vous parait-elle propre ?
Y a -t-il une meilleur façon de faire ?


Merci d'avance !

[divxdede]

[quote="Jaxofun"]Bonjour !

Problème :
Dans mon application j'utilise une classe statique, c'est à dire qu'elle ne contient que méthodes et attributs statiques.
Depuis mon application à évoluée, et je me rend compte de la nécessité de divisée cette classe en une interface et son implémentation.
Cependant, je voudrais conserver l'appel à des méthodes statiques et c'est ça mon problème, car une méthode abstraite ne peut pas être statique.

Solution trouvée :
Pour resoudre cela j'ai trouvé une solution, j'ai divisé ma classe en deux classes :

tu peu utiliser un singleton pattern + interface

genre

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
 
public interface EuroFrancsConverter
{
     public double francToEuro(double franc);
 
     public double euroToFranc(double euro);
}
 
public class EuroFrancManager
{
 
   private static EuroFrancsConverter instance = new DefaultEuroFrancsConverter();
 
   private static EuroFrancsConverter getInstance()
   { return instance; }
 
   private static void setInstance(EuroFrancsConverter converter)
   { instance = converter; }
}
 
public class DefaultEuroFrancsConverter implements EuroFrancsConverter
{
 
     public double francToEuro(double franc)
     { return franc / 6.55957; }
 
     public double euroToFranc(double euro)
     { return euro * 6.55957; }
}

tu peu ensuite utiliser simplement comme ceci

Code :

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

1
2
 
EuroFrancManager.getInstance().francToEuro(3.6);

[Jaxofun]

Merci de ta suggestion divxdede ! De plus cette méthode est très académique apparement !
Ton principe est un peu semblable au mien sauf que moi je mélange l'interface et la classe de singleton en une seule classe abstraite et qu'au lieu d'utiliser getInstance() je passe par des méthodes statiques.
Je reprend ton exemple avec ma façon de faire pour m'expliquer :

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
 
public abstract class EuroFrancManager { 
 
   private static EuroFrancsManager instance = new DefaultEuroFrancsConverter(); 
 
   private static double francToEuro(double franc){
      return instance.francToEuroImpl(franc);
   } 
   public abstract double francToEuroImpl(double franc); 
 
   private static double euroToFranc(double euro){
      return instance.euroToFrancImpl(euro);
   } 
   public abstract double euroToFrancImpl(double euro); 
 
} 
 
public class DefaultEuroFrancsConverter extends EuroFrancsManager{ 
 
     public double francToEuroImpl(double franc) 
     { return franc / 6.55957; } 
 
     public double euroToFrancImpl(double euro) 
     { return euro * 6.55957; } 
}

Inconvenient :
Ton code plus lourd à l'utilisation.

Code :

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

EuroFrancManager.getInstance().francToEuro(3.6);

au lieu de

Code :

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

EuroFrancManager.francToEuro(3.6);

Avantage :
Ton code est beaucoup moins lourd au niveau de ces classes et donc plus facile à faire évoluer.

En fait ce que je me demande c'est s'il vaut mieux que je fasse un code lourd dans ces classes, mais qui le devient moins dans son utilisation dans le reste de l'application (surtout dans le cas ou ces méthodes sont utilisées 1 fois minimum dans chaque méthode des classes de l'appli), ou l'inverse !

[TabrisLeFol]

Le principe est que ton code dois pouvoir etre lu et modifié avec le moins de modification sur le code externe. donc le plus tu met dans ta class, le mieux c'est .

[Jaxofun]

Le principe est que ton code dois pouvoir etre lu et modifié avec le moins de modification sur le code externe.

Dans les deux cas de figure, une modification de l'implémentation ne change rien dans le code externe puisque l'on utilise des interfaces et méthodes abstraites. Ou alors j'ai pas compris ce que tu as voulu dire !

[TabrisLeFol]

Oui cette sentence est pas tres explicite. Le but premier est que ton code soit facile d'acces (propre) pour la maintenance et que de l'exterieure toute modification soit invisible. Apres la maniere dont tu veux l'implementer depend de toi.
Avec ta solution initiale il faut a chaque fois creer une fonction "fantôme" (oui c'est un nouveau type ) static qui apelle la fonction de meme nom sur une instance sauvegarder.
Il est vrai dans ce cas la que la solution du singleton est plus propre. Et l'inconvenient de devoir appeler le singleton n'est pas enorme. Cette solution est bien si tu souhaite plus tard eventuellement rajouter des attributs mais sinon une Interface (contrat de methode) ne serait pas suffisante?

[Jaxofun]

Ouais, j'ai finalement décidé d'utiliser la solution de divxdede car l'utilisation du singleton est plus propre et surtout je n'ai plus besoin de créer de methode "fantome".

Merci divxdede et TabrisLeFol pour votre aide et vos suggestions !