[conception] gestion d'un objet omnipresent

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?

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.

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

Citation:

---

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.

Citation:

---

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.

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++?

Citation:

---

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 ?

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.

Citation:

---

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.

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� :question:)
• "killer" -> collection de session (unregisterSession(SessionId) ) (amiti� :question:)
• goNoGo
  
  • collection de session findSession(SessionId) ->Session
  • BDD
  • RequestType
• tout le reste ->goNoGo

Citation:

---

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

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

Citation:

---

Envoy� par r0d

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

Citation:

---

Envoy� par r0d

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.