Méthodes static vs classe Singleton

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:

---

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

---

ou des méthodes static et des variables static ?

Code:

---

MyApp.translate("LIBELLE")

---

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

Merci,

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.

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... :mouarf:

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:

---

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.

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

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 !

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.

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 !

Idéalement, il faudrait fournir la connexion à la classe qui en a besoin mais je vois autre chose. Tu souhaites utiliser une seule connexion pour toute ton application?

Oui j'utilise une seule connexion.... C'est un problème ?:oops:
C'est une petite application fat-client mono-user qui tourne avec une db java embarquée (H2). Je n'ai pas programmé d'accès concurrents (on fait un ajout à la fois, on fait une recherche à la fois)

1. Stubber un singleton ca prend 2 secondes
2. Il vaut mieux optimiser la simplicité d'utilisation que le design.
3. C'est pas mieux que de passer toutes ces classes utilitaires en paramètre de celles qui en ont besoin.

Pour résumer fais comme c'est plus lisible et rapide à écrire !
Le seul problème des singletons et/ou méthode static, c'est que ca repose sur des ressources static qui ne sont pas libérables.

Et que c'est la galère avec les test unitaire, l'évolutivité de l'application, ...

Je vois pas le problème avec les tests unitaires :

1. Créer une version stubbée
2. Ajouter une méthode "protected" qui permet de modifier l'instance
3. Les API dédiés Mockito, etc.
4. Toutes APIs fonctionnant sur BCEL comme AspectJ

C'est certes pas le plus simple mais il faut voir aussi le besoin en test.

Surtout que tester l'i18n en JUnit ... Ca reste pour moi un composant technique/utilitaire et dont le code est tellement simple/nécessaire/triviale/executé XXXX fois qu'il sera impossible de passer à côté d'un bug.


Concernant l'évolution, ca prendra autant de temps de le faire maintenant que plus tard, sauf que si tu le fais maintenant le reste de l'application reste en stand-by.
Ensuite remplacer :

Code:

---

1 2 3 4 5 6 7 8 9

public class MySingleton { private static MySingleton singletonInstance = null; public static MySingleton getInstance() { if (singletonInstance == null) { singletonInstance = new MySingleton(); } return singletonInstance; } }

---

par

Code:

---

1 2 3 4 5 6 7 8 9 10

public class MySingleton { private static ThreadLocal<MySingleton> singletonInstance = ThreadLocal<MySingleton>() { public MySingleton initialValue() { return new MySingleton(); } } public static MySingleton getInstance() { return singletonInstance.get(); } }

---

Ca mange moins de pain que d'ajouter des attributs/constructeurs à tous les controlleurs/actions/autres... Sans oublier d'initialiser et stocker une référence quelques parts (dans un singleton Application ?)

Le problème n'est pas trop de tester le singleton, le problème et de pouvoir proprement réinitialiser tous les états statiques entre chaque test. Quand on commence à cumuler les singleton / états statiques, y en a toujours un larvé quelque part non documenté dans une librairie que tu utilise qui viens f*** la merde :)

Dans son cas on en est assez loin ...

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

Citation:

---

Envoyé par Nemek

Ca mange moins de pain que d'ajouter des attributs/constructeurs à tous les controlleurs/actions/autres... Sans oublier d'initialiser et stocker une référence quelques parts (dans un singleton Application ?)

---

Il y a sans doute des situations où c'est plus facile. Cependant, travaillant sur des bases de code trop grosses pour être maîtrisée en intégralité, je préfère éviter que toutes les classes commencent à utiliser des méthodes statiques magiques pour obtenir des dépendances au milieu de chaque fonction car très vite ça peut tourner au spaghetti.

Donc je préfère toujours qu'une classe soit indépendante, et que l'application lui fournisse ce qu'il lui faut pour travailler. Ca me paraît plus maintenable sur mes projets et ça rend chaque classe facilement compréhensible et facilement testable. Maintenant je dis pas que pour des cas d'utilisation plus simple il soit faux de considérer un singleton.

exact skip, de plus pour les grosse bases de code, de l'IOC couplé à aspectJ permet en général de passer tout ça automatiquement sans surcharger de traval non plus l'appelant ;)

+1 pour les AspectJ et les injecteurs de dépendance en général.

Après ça dépend de chaque classe utilitaire.
Pour la base de données, je préfères avoir un package avec des interfaces de manager pour accéder aux données, que je filerais aux classes nécessaires.
Les implémentations se chargeront de partager convenablement la récupération l'accès à la base de données en fonction des contraintes du projet : plugin, bundle OSGi, API tierce, application web, etc.

Cependant pour des trucs un peu bateau comme l'i18n, manipulation de chaînes de caractères (cf: StringUtil), de flux (cf: IOUtil), etc. Le singleton est pratique.

Bon après je travailles sur des petites applications web qui font des choses très précises, qui sont beaucoup en maintenance mais qui n'évoluent pas trop.
Je privilégie donc tout ce qui facilite la maintenance au-delà de l'évolutivité.