Kevin Kofler (./1248) :

Jyaif (./1246) :
Quand aux différent types de constructeurs et la surcharge de '=', je n'en vois pas trop l'utilité dans un singleton.

Ça évite que quelqu'un recopie l'objet.

Pour moi, dans pas mal de langages, en particulier ceux où on permet la copie implicite, le singleton est bon sur le principe mais pas dans son concept exact d'un objet unique/pointeur unique. Je vois deux solutions propres : par délégation, on a accès à un objet alloué qui délègue à un objet unique (pour etre clair : interface A, implantation réelle B : A qui fait les traitement et encapsule les données, et classe visible C : A, qui accède à l'unique instance de B et lui délègue ses traitements, et qui peut le cas échéant être alloué plusieurs fois, copié...). Mais je pense que le mieux, c'est comme propose Kevin, d'utiliser la partie procédurale du langage quand on traite de problèmes procéduraux.

./1245 Les deux se défendent. Un problème c'est le bruit pour pouvoir annuler un traitement en encodant la programmation réactive/évènementielle dans du passage de messages comme ça, il va falloir un signal "envoyer du bois", dans un slot "recevoir du bois", et à l'inverse un signal "bois reçu" dans un slot "valider réception bois" mais aussi un signal "bois reçu mais tout pourri" dans un slot "réessayer envoi bois", etc... (j'ai employé la terminologie Qt parce qu'elle est plus facile à écrire et comprendre je trouve mais je parle en général). D'un autre côté, pour encoder des opérations asynchrones (qui prennent du temps, qui ont besoin que d'autres choses se produisent avant de se terminer, etc.) c'est bien plus pratique.
Et puis tu es obligé d'envoyer ton signal en fin de méthode, et attendre sa réception dans une autre méthode, donc en plus tout ton état doit être dans des variables membres plutôt que locales ce qui ne fait que compliquer la vérification. Dans d'autres langages (dits réactifs) tu pourrais faire "answer = send message(args)", et le compilo se charge de découper ton code tout seul, gérer les envois de messages, etc.
Du coup effectivement, il faut je pense bien réfléchir aux parties que tu fais par passage de messages, et aux parties que tu fais par appel de méthodes, mais ce n'est pas impossible que certaines parties du jeu lui-même soient intéressantes à faire en passage de messages.