Discussion :

[barcelonais59]

Bonjour, dans le cadre de mes études, nous sommes souvent amenés à rencontrer le design pattern singleton, je ne comprends toutefois pas l'intérêt : on pourrait très bien utiliser des attributs et des fonctions statiques non ? Merci d'avance

[thelvin]

Hello,

c'est envisageable mais peu flexible.

Déjà si ton singleton implémente une interface ou étend une classe abstraite qui définit ses méthodes, non tu ne peux pas remplacer par des appels statiques. Ou alors ça t'obligerait à plein de code de glue supplémentaire, et pour quoi ? Ben pour rien.

De manière générale c'est un peu le principe de la programmation orientée objet : manipuler des objets qui ont chacun une mission précise, en lieu et place d'appeler des méthodes statiques ici ou là qui ne sont pas spécialement sous la coupe d'un objet. Pourquoi vouloir faire de la programmation par objet ? Parce que ça marche dans son rôle de garder les choses flexibles, alors que le reste ça marche pas trop. Et puis c'est pas comme si ça coûtait quelque chose de le faire.

Par exemple ton singleton, là maintenant il est implémenté d'une manière précise, par une classe, qui rend le service que tu as besoin que le singleton rende. Bon et supposons qu'un jour tu aies besoin que ton programme puisse fonctionner en deux ou trois "modes" différents, configurables au lancement du programme, qui chacun demandent une implémentation différente du singleton, genre il y en a un qui se base sur les float, l'autre les double et l'autre les BigDecimal ? Eh bien avec un singleton dont l'implémentation est choisie au démarrage, c'est tout simple. En faisant autrement... Pas trop.

C'est aussi un raisonnement qui facilite le contrôle qualité sur le domaine des tests unitaires : garder la flexibilité permet de tester chaque partie indépendante. Et le singleton peut être remplacé par une implémentation fantoche pour les besoins des tests, qui t'aidera à tester le composant qui s'en sert comme ça t'arrange.

Bref utiliser de la programmation orientée objet, ça te garde toutes les portes de flexibilité ouvertes pour le futur, et ça ne coûte rien. Même quand on ne suspecte pas à l'avance comment ça va servir plus tard, en général ça ne change rien au fait que ça sert bel et bien plus tard. Garder des portes ouvertes est une stratégie efficace dans tous les domaines de la vie. (Cela dit dans la vraie vie en général on doit faire face à des choix qui obligent à fermer des portes. Ici, non... Alors abusons-en joyeusement.)

[professeur shadoko]

la réalisation d'un singleton est souvent un piège.
Toi, programmeur "réalisant" du code tu sais qu'il n'y a qu'une seule instance qui réalise un service ...
mais les autres programmeurs "clients" doivent-ils le savoir?
Ma réponse est (généralement) NON!
combien de fois tu t'aperçois que , finalement, il peut y avoir plusieurs objets qui rendent service ? vas-tu courir après les autres pour qu'ils changent leur code?
Dans de nombreux cas la bonne réalisation est un objet "normal" (avec constructeur et tout le toutim) qui délègue ses méthodes à un singleton connu de toi seul ... comme ça le jour où tu changes d'avis les codes "clients" n'en ont pas conscience.
je vote pour l'encapsulation des singletons.

edit: Oups je vois que je me répète: https://java.developpez.com/telechar...vec-delegation