[conception] gestion d'un objet omnipresent

**r0d** · 03/11/2009, 14h52

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** · 03/11/2009, 15h03

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é · 03/11/2009, 21h48

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** · 04/11/2009, 10h40

Envoyé par fcharton

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.

Envoyé par fcharton

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** · 04/11/2009, 10h40

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** · 04/11/2009, 10h43

Envoyé par r0d

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** · 04/11/2009, 10h45

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** · 04/11/2009, 11h04

Envoyé par 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.

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

**koala01** · 04/11/2009, 11h36

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:

"enregistrer" les nouvelles sessions (qui lui sont envoyées par une fabrique)
"désenregistrer" les sessions finies (qui sont indiquées comme telles par un "killer")
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é · 04/11/2009, 18h47

Envoyé par r0d

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