Discussion :

[Invité]

Bonsoir
Je développe actuellement un serveur de jeu en C#. J'essaie actuellement de le rendre le plus testable unitairement que possible.

Pour l'instant, le pattern que j'ai commencé ressemble à ceci :

Une classe Server est instanciée:
- Sert à démarrer et à stopper le serveur

Elle instancie une classe d'instance ConnectionsManager
- Contiens une instance de la classe ConnectionsPool (en gros une classe de gestion de liste)
- Sert à accepter de façon asynchrone les connexions (TCPListener.BeginAcceptSocket)
- Lorsque un socket est accepté une instance une instance de la classe ClientConnection est créée et ajouté à la liste de ConnectionsPool

La classe Clientconnection :
- Responsable de recevoir les donnés via Socket.BeginReceive
- Lorsque tout est reçu une instance de la classe SocketHandler est créée (sert en gros à traiter le packet selon son ID)

Donc le schéma ressemble à ça:

Server -> ConnectionManager -> ConnectionsPool -> ClientConnection -> SocketHandler

La problématique : lorsque je suis dans le SocketHandler, comment je fais pour pouvoir affecter un autre joueur ? (par exemple une autre instance de Clientconnection dans ConnectionsPool puisque ça semble le plus simple à faire ici), ou même affecter le serveur lui même (comme fermer le serveur par exemple).

J'assume avoir trois choix :
- Passer les classes importances (Serveur + ConnectionsPool) en classe statique et les utiliser comme tel
- Passer les classes importances en singleton
- Injecter dans les constructeur les instances des classes importantes

Le but ici est de rendre le tout testable unitairement de façon pas trop compliqué tout en gardant un code clair et fonctionnel utilisant les "best practices".

J'ai eu une suggestion d'injecter des delegates, mais je ne suis pas exactement certain du résultat de la méthode (entres autres pour les tests).

Quel serait le meilleur choix d'architecture ici selon vous ?

Merci