Discussion :

[lvr]

Bonjour,

J'écris une petite application type FatClient. J'ai besoin de garder au niveau central certaines méthodes (obtention connexion à la db, traduction des libellés, config utilisateur, ...).
Quelle est la meilleure manière de procéder ?
Une classe singleton qui possède toutes ces méthodes:

Code :

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

MyApp.getInstance().translate("LIBELLE")

ou des méthodes static et des variables static ?

Code :

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

MyApp.translate("LIBELLE")

Quelle est la manière la plus propre de travailler ?

Merci,

[Mopmop]

Je pencherais pour la solution utilisant le Singleton, plus flexible, plus "objet", donc selon moi, plus propre.

Question performance, je ne sais pas laquelle est la meilleure.

[Ivelios]

Bonjour,

Je pencherais aussi pour le Singleton pour les mêmes raisons.
Cependant, s'il s'agit de constantes, tu peux aussi faire une classe abstraite avec des variables statiques.
Après il y a plusieurs écoles...

[_skip]

Ces deux méthodes sont assez mauvaises et présentent le même inconvénient, soit l'introduction de dépendances qui rend un code hypersensible au contexte et intestable.

La meilleure solution dans ces cas là, c'est de fournir ces informations à la classe dont tu as besoin :

par exemple :

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
 
public class Xxxx
{
       private Traducteur trad;
 
       public Xxxx(Traducteur trad)
      {
         this.trad = trad
       }
 
 
       public void print()
       {
             String hello = trad.translate("bonjour");
             println(hello);
        }
}

Comme ça, tu sais que ta classe, pour fonctionner à besoin d'une objet de traduction.
Et dans l'autre cas que tu as cité, c'est à dire la configuration utilisateur, tu as l'énorme avantage de pouvoir, à l'aide des tests unitaires ou d'un simple main(), tester facilement différentes configuration. Il te suffit de fabriquer de toute pièce un objet configuration et de le fournir à la classe et observer ce qui se passe.

Bref, c'est plus propre, plus testable et plus clair à la relecture.

[tchize_]

Je rajouterais même: vous emmerdez pas à utiliser un objet "Traducteur", utilisez directement un objet "Ressourcebundle"

[lvr]

Merci pour les réponses.
@_skip et tchize_: en effet si je n'avais que les traductions, c'est que je ferais, mais j'ai ici une dizaine de propriétés générale de l'application que je veux pouvoir récupérer à peu prêt partout sans devoir les passer dans chaque classe.
Car les mettre dans chaque classe, ça m'oblige à les sérializer quand je les sérialize, ou si je les mets en transient elles manquent à la désérilisation !

[thelvin]

En même temps les objets qui utilisent ce genre de choses n'ont pas à être sérialisés. La sérialisation c'est pour les données, c'est pas pour simuler un dump de la mémoire du programme.

[lvr]

Bon c'est ma 1ère application avec une DB. Donc je ne l'ai probablement pas écrite idéalement.
Au niveau de mon application, j'ai un objet connexion qui permet a tout un chacun de faire ses update, select, insert, ...

Auparavant, je passais cette connexion dans tous mes objets db, mes objets gui (devant déclencher de nouvelles interactions db) et tout-partout. Ca marchait presque nickel (ça ne marche pas que je veux sérializer un objet db pour le sauver dans fichier de préférence par exemple). Donc je viens de supprimer ce mécanisme et je mets cette connexion à disposition de qui veut s'en servir au niveau d'une classe static de l'application. D'où ma question: est-ce que je mets cette connexion à disposition via un Singleton ou via des méthode statique ?

J'ai pour le moment opté pour le Singleton, mais passer vers des méthodes statiques ne serait rien comparé au refactoring que je viens de me taper !

[Logan Mauzaize]

Dans son cas on en est assez loin ...

[lvr]

Conclusion: Singleton et bien veiller à tout ré-initialiser convenablement entre chaque test JUnit ?