Singleton avec délégation

Version imprimable

16/05/2012, 16h43
professeur shadoko

Singleton avec délégation

Bonjour,

Je vous propose un nouvel élément à utiliser : 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 ....

Qu'en pensez-vous ?
22/05/2012, 13h57
Logan Mauzaize

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.
08/06/2012, 12h07
professeur shadoko

Citation:

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.

Ici principe d'encapsulation: le code client demande un service et n'a pas à savoir comment il est implanté. Si au cours de l'évolution des codes le responsable de ce code se rend compte qu'il n'a plus affaire à un Singleton les codes clients ne sont pas impactés.
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:

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:
Code:

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) ; } }
On a ici un singleton qui exécute dans un contexte particulier au client.

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).
Code:

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); } }