Téléchargé 1 fois
Vote des utilisateurs
0
0
Détails
Licence : Freeware
Mise en ligne le 16 mai 2012
Langue : Français
Référencé dans
Navigation
singleton avec délégation
singleton avec délégation
le code "client" d'un singleton ne devrait pas savoir qu'il a affaire à un singleton.
de plus ce code peut évoluer et le singleton disparaitre ....
de plus ce code peut évoluer et le singleton disparaitre ....
Est-ce que tu pourrais donner un peu plus d'explication pourquoi utiliser un singleton derrière ?
Autrement, je suis pas trop d'accord sur le fait "de ne pas se soucier". S'il y a des ressources partagées autant le savoir et utiliser 'l'instance correctement.
Autrement, je suis pas trop d'accord sur le fait "de ne pas se soucier". S'il y a des ressources partagées autant le savoir et utiliser 'l'instance correctement.
Est-ce que tu pourrais donner un peu plus d'explication pourquoi utiliser un singleton derrière ?
Autrement, je suis pas trop d'accord sur le fait "de ne pas se soucier". S'il y a des ressources partagées autant le savoir et utiliser 'l'instance correctement.
On aura alors un peu l'équivalent d'une Fabrique: en fonction de circonstances qui échappent au code client on aura un code différent qui rend le service.
Dans cas j'aurai plutôt vu un truc du genre (inspiré par les patterns Service de Java) :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | public interface QuelqueChose { void faisLe(String argument); } public class QuelqueChoseImpl { void faisLe(String argument) { System.out.println(this + " fais quelque chose"); } } public class QuelqueChoseBuilder { private static final QuelqueChose qqch = new QuelqueChoseImpl(); public static QuelqueChose newInstance() { return qqch; } } |
non ... encore une fois le newinstance implique que le code client sache qu'on aie un singleton ... ce que l'on cache.
le code client demande un service et il le fait comme d'habitude: crée un objet et on lui rend des services .... derrière il n'y a qu'un seul objet actif mais il n'est pas censé le savoir.
C'est vrai que le plus souvent cette forme du pattern est hybride: on crée un constructeur avec paramètres qui constituent des variables d'instance. le singleton derrière exécute une méthode avec des paramètres.
genre:
On a ici un singleton qui exécute dans un contexte particulier au client.
le code client demande un service et il le fait comme d'habitude: crée un objet et on lui rend des services .... derrière il n'y a qu'un seul objet actif mais il n'est pas censé le savoir.
C'est vrai que le plus souvent cette forme du pattern est hybride: on crée un constructeur avec paramètres qui constituent des variables d'instance. le singleton derrière exécute une méthode avec des paramètres.
genre:
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | class Machin { static final Chose chose = new Chose() ; // classe statique interne si besoin String etat1; int etat2 ; public Machin(String st1, int it2) { this.etat1= st1 ; this.etat2 = it2 ; } public int execute(int arg3) { return chose.exec(etat1, etat2, arg3) ; } } |
Je comprends mieux dans ce cas Il faudrait peut-être màj l'exemple.
Ex : Un bus de communication (commun à plusieurs clients) mais chaque client envoie son propre id (initialisé au début) et le message (spécifique à chaque envoie).
Ex : Un bus de communication (commun à plusieurs clients) mais chaque client envoie son propre id (initialisé au début) et le message (spécifique à chaque envoie).
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | public class Messenger { private static final Channel channel = new Channel(); private static int nextId = 1; private int id = nextId++; public void send(String msg) { channel.send(id, msg); } } |
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.