Discussion :

[r0d]

Bonjour à tous,

Ce que j'appelle un "objet omniprésent" c'est une instance d'une classe dont on va avoir besoin quasiment partout dans le programme. Cela arrive assez fréquemment. Par exemple un logger, ou une classe de gestion de session sur les applis de type serveur, etc.

Pour gérer cela, je vois deux solutions:
1. Le singleton, bête et bourrin
2. Le pointeur que l'on va se trimbaler partout

Ca doit se sentir dans la forme de ma prose: aucune de ces 2 solutions ne me plaît. Mais je n'en vois pas d'autre. Auriez-vous d'autres idées à proposer?

[Cheps]

Si il est omniprésent et logiquement instance unique, alors je pense que le singleton est la solution la plus propre.
En tous cas, avoir ton objet passé par pointeur dans tous les sens je trouve vraiment pas mieux.

[Invité]

Je mettrais un bête objet global. Ou si tu n'as pas besoin de le construire, une classe avec des fonctions statiques.

L'avantage de l'objet global, c'est si, à un moment, ton objet omniprésent doit exister en deux exemplaires (genre deux loggers, vers des logs différents: tu peux bien sur ajouter un paramètre à tous tes appels de log, si tu as du temps libre, mais...)

Francois

[3DArchi]

Je mettrais un bête objet global. Ou si tu n'as pas besoin de le construire, une classe avec des fonctions statiques.

Ou tout simplement des fonctions libres avec éventuellement accès à un singleton si pertinent.

L'avantage de l'objet global, c'est si, à un moment, ton objet omniprésent doit exister en deux exemplaires (genre deux loggers, vers des logs différents: tu peux bien sur ajouter un paramètre à tous tes appels de log, si tu as du temps libre, mais...)

On peut aussi, si c'est adéquat utiliser un pattern Chaîne de responsabilité dans ce cas.

[r0d]

Oui en fait, je me suis un peu emmêlé les pinceaux dans mon premier post. Je voulais parler d'un objet omniprésent, mais dont on peut avoir plusieurs instances.

L'exemple des sessions dans un serveur me semble un bon exemple.
Prenons un programme définit ainsi:
- il reçoit en entrée des requête provenant d'un client distant
- pour traiter ces requêtes, il va effectuer des recherches sur une bdd, faire des calculs, puis renvoyer le résultat au client
- il doit gérer les connections multiples (plusieurs clients connectés en même temps)

Définition assez classique d'un serveur quelconque.
Bien souvent, nous aurons besoin d'une petite classe, que l'on appelera Session, qui contient les données d'un client (ce concept existe en natif dans certains langages "orienté réseau" comme php par ex.).
Pour chaque client, on aura donc une Session. Et on en aura besoin à peu près partout.

Existe-t-il un idiome pour gérer cela de façon élégante en c++?

[3DArchi]

Et on en aura besoin à peu près partout.

C'est cette phrase qui me fait tiquer. La question que je me pose est plutôt de savoir si les responsabilités entre les classes ont bien été définies pour faire apparaître ce besoin de voir Session partout dans la gestion du client ?

[Cheps]

Pourquoi pas un SessionManager (qui lui serait un singleton), qui te permet de gérer l'ouverture, la fermeture, l'accès, etc, de tes sessions.

[3DArchi]

Pourquoi pas un SessionManager (qui lui serait un singleton), qui te permet de gérer l'ouverture, la fermeture, l'accès, etc, de tes sessions.

Ca me fait penser à l'intervention d'Emmanuel Deloget sur les 'god classes' dans la discussion sur Demeter.

[koala01]

Salut,

Ceci dit, je ne serais pas très loin de proposer, effectivement, un singleton (à défaut d'une classe essentiellement composée de membres et fonctions statiques) mais servant de "collection de sessions", regroupant les différentes sessions qui, pour suivre plus ou moins l'intervention d'Emmanuel, se chargerait de:

1. "enregistrer" les nouvelles sessions (qui lui sont envoyées par une fabrique)
2. "désenregistrer" les sessions finies (qui sont indiquées comme telles par un "killer")
3. retrouver une session donnée parmi les sessions existantes

La session contiendrait juste ce qu'il faut pour déterminer si un acces donné est autorisé ou non à l'utilisateur qu'elle représente.

Une fonction libre prendrait en paramètre la session, la base de données à laquelle tentative d'acces est faite et le type de la requete (select, update, delete, add) et donnerait un go / no go.

Les dépendances seraient (dépendant -> dépendance)

• Fabrique -> collection de session (registerSession(Session ) ) (amitié )
• "killer" -> collection de session (unregisterSession(SessionId) ) (amitié )
• goNoGo
  
  • collection de session findSession(SessionId) ->Session
  • BDD
  • RequestType
• tout le reste ->goNoGo

[Invité]

Existe-t-il un idiome pour gérer cela de façon élégante en c++?

Là je mettrais un conteneur global, contenant des objets sessions... Typiquement, si ta session est associée à un identifiant, un tableau associatif (map ou autre). Pour récupérer une session tu fais juste conteneur_global[ma_session].

Il te faut ensuite deux fonctions, une pour créer une session, une pour la fermer. Si la création est très simple, tu peux la mettre dans le constructeur, qui sera appelé si tu appelles conteneur_global[ma_session] sur un identifiant inconnu... Pour la fermeture, ca peut être une fonction de l'objet Session (mais alors elle restera dans le conteneur), ou une fonction membre du tableau associatif.

Francois

[3DArchi]

Probablement qu'une variable globale pour le log est adéquat, pour les sessions, j'en suis moins persuadé.

L'exemple des sessions dans un serveur me semble un bon exemple.

J'ai l'impression que chaque exemple génère sa solution spécifique (cf ci-dessus et discussion forkée sur le log).
D'où :

Existe-t-il un idiome pour gérer cela de façon élégante en c++?

Il semblerait que chaque cas ait son type de solution et qu'on peut difficilement généraliser.