Bonsoir,
Il faut savoir que le Singleton n'est rien d'autre conceptuellement qu'une variable globale déguisée (mais sur lequel contrairement à une variable globale, on peut gérer les accès concurrents de manière intrinsèque grâce à l'encapsulation).
A fuir le plus possible car rendant global un état qui pourrait être modifié, soit à plusieurs endroit du programme (ce qui le rend quasi intestable), soit par plusieurs Thread/Process (ce qui pose des problèmes d'accès concurrents).
Pour les exemples d'utilisation :
- la gestion d'un cache est souvent implémentée sous forme de singleton. Par exemple dans un logiciel de jeu, on va avoir un ResourceManager qui va charger les ressources (texture, mesh, scénario du niveau...) à partir d'un fichier (local ou distant). Les accès disques/réseaux sont couteux, on met donc en cache les données lues pour éviter de le refaire.
- les contrôleurs HTTP, sont aussi parfois des singletons par besoin de performance. La création d'un objet ayant un coût (variable selon les langages, en Java, c'est assez rare d'utiliser un Singleton pour un contrôleur HTTP, on utilise d'autres mécanismes), ça peut-être nécessaire (mais on évitera dans la mesure du possible d'avoir un état au sein du singleton).
A noter que ce genre d’optimisation ne doit jamais être fait avant d'avoir rencontré et localisé un soucis de performance sur la partie du code en question.
premature optimization is the root of all
evil-- DonaldKnuth
qu'on pourrait traduire par : l'optimisation prématurée est à l'origine de tous les maux.
Dans le cas que vous proposez, l'utilisation d'un singleton pour gérer une connexion BDD, pose un problème. Votre application utilisera une seule connexion BDD.
S'il s'agit d'une application standalone, ça ne posera pas de problème.
S'il s'agit d'un webservice, tous les utilisateurs se retrouveront à utiliser la même connexion à la BDD, ce qui causera un goulot d'étranglement car les traitements seront effectués en série (un client devant attendre que le précédent ait complété sa requête). Généralement on utilisera ce qu'on appel un pool (groupe) de connexions (créées au démarrage de l'application ou à la demande), dimensionné en fonction du besoin, qui seront réutilisées.
Je viens de voir que votre DAO ne stock pas la connexion (ce qui évite le goulot d'étranglement mentionné plus haut mais perd la main sur le nombre de connexions créées). Dans le contexte, vous ne gagnez rien à remplacer :
bddConnection = new ConnectDAO().connection()
par :
bddConnection = ConnectDAO().getInstance().connection()
Vous complexifiez inutilement le code et vous introduisez un état global qui comme dit plus haut rend l'application plus compliquée à tester.
Une remarque sur votre code :
JOptionPane.showMessageDialog(null, "Erreur driver mysql: " + ex);
Ce type de code n'a rien à faire dans votre DAO. Celui-ci n'est pas censé savoir qu'il est utilisé au sein d'une application SWING.
En faisant ça, non seulement vous mélanger au même endroits des notions qui n'ont rien à voir (gestion BDD et de l'UI), mais en plus votre DAO ne pourra pas être réutilisé dans une application qui n'aurait pas d'interface graphique (ou qui utiliserai une interface Web). Vous devez remonter l'erreur à l'appelant qui s'il est légitime la traitera (sinon la remontera à son appelant etc).
Partager