Signaux Godot : réduire le couplage tout en gardant explicite la durée de vie des connexions

Choisir le type de relation voulu

L'ouverture d'une porte et la demande d'ouverture d'une porte sont deux interactions différentes. La demande suppose un destinataire responsable, capable de l'accepter ou de la refuser. L'ouverture une fois effectuée peut intéresser indépendamment le son, les objectifs et le code de l'interface. Il faut distinguer ces deux types de relation avant de choisir un mécanisme de communication. La fonctionnalité en devient plus facile à comprendre le jour où un autre système voudra l'observer.

Les signaux annoncent des événements

Les signaux de Godot permettent à des objets de réagir à des changements sans que l'émetteur ait à connaître chaque récepteur. [1] Utilisez un signal pour annoncer un changement d'état achevé, avec assez de contexte pour que les écouteurs puissent l'interpréter. Préférez un appel de méthode direct lorsque l'appelant possède déjà la cible et a besoin d'un résultat immédiat. Aucun des deux mécanismes ne dispense de définir clairement à quel moment l'état change.

Les connexions ont une durée de vie

Une connexion de signal ordinaire vers un callable est perdue lorsque l'objet de ce callable est libéré. is_connected() permet de vérifier si une connexion existe avant de connecter ou de déconnecter. [2] Masquer un panneau ou le retirer temporairement de l'usage actif n'équivaut pas à le libérer. Il faut donc définir si son abonnement dure pendant toute la vie de l'objet ou seulement tant qu'il participe à la fonctionnalité.

Exemple : le panneau de commande d'un sas

Imaginons un panneau qui demande l'ouverture d'un sas par une méthode directe. Le sas vérifie ses verrouillages, met à jour son état et n'émet airlock_opened qu'une fois l'ouverture réellement effectuée. Un écouteur sonore et un écouteur de mission s'abonnent chacun de leur côté. Un panneau d'état temporaire s'abonne pendant qu'il est affiché, lit un instantané de l'état initial, puis se déconnecte à la fin de sa période d'observation. La réouverture de ce panneau doit produire un seul abonnement actif, et non une couche supplémentaire de callbacks. Si le sas s'ouvre pendant que le panneau est absent, l'instantané affiche l'état correct à son retour ; le panneau n'a pas besoin qu'on lui rejoue tous les signaux antérieurs.

Limites et vérification

Les signaux sont des notifications, pas un historique d'événements automatique ni un système de propriété. Pour les opérations sensibles à l'ordre, gardez un coordinateur explicite unique plutôt que de compter sur des écouteurs indépendants qui s'exécuteraient dans un ordre favorable. En C#, les lambdas capturantes et les signaux personnalisés connectés avec += font exception à la déconnexion automatique ; suivez les règles de nettoyage documentées. [3] Testez l'ouverture répétée du panneau, la destruction d'un écouteur, le remplacement de scène et un événement émis pendant le démontage. Vérifiez à la fois les mises à jour manquées et les réactions en double. Adaptez les API de connexion et le comportement de durée de vie propre à chaque langage à la version de Godot utilisée par le projet.

Sources

1. Using signals — Godot Engine contributors.
2. Signal class reference — Godot Engine contributors.
3. C# signals — Godot Engine contributors.