Discussion :

[professeur shadoko]

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 ?

[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.

[professeur shadoko]

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.

[Logan Mauzaize]

Dans cas j'aurai plutôt vu un truc du genre (inspiré par les patterns Service de Java) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[professeur shadoko]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Logan Mauzaize]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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