Avant d’ajouter les nouveaux Animator à notre code, il faut adresser une grosse difficulté inhérente au problème.
Pour permettre une interaction entre les entités pendant leur animation, la fonction animate() des deux nouveaux Animator doit accéder simultanément à l’entité en modification et à l’ensemble des autres entités dont elle fait partie.
Cela implique de conserver à la fois une référence exclusive (mutable) et une référence partagée (non-mutable) vers la même séquence d’éléments.
Bien que cela soit possible dans la majorité des langages de programmation, ce ne l’est pas en Rust.
En effet, même si le programmeur prend toutes les précautions dans son code, le borrow-checker n’est pas capable à la compilation d’assurer que la même donnée ne sera pas lue et en modifiée au même moment.
Rust n’accepte aucun risque de corruption de données.

La solution consiste à forcer le contrôle de la cohérence de l’accès aux données à l’exécution (et non plus à la compilation car c’est impossible).
En Rust, l’analyse au moment de l’exécution est possible grâce à la notion de l’exclusivité dynamique (interior-mutability), proposé à travers le type std::cell:RefCell✍.
L’interior-mutability propose de n’utiliser que des références partagées (non-mutables) sur les données et de ne demander un accès (exclusif ou partagé) qu’au moment où nous voulons accéder à la donnée.
Si à l’exécution, il se vérifie la coexistence d’une référence exclusive (mutable) avec d’autres références sur la même donnée, une erreur irrécupérable serait signalée avec panic!().

Procédons alors à la modification de notre code pour bénéficier de la notion d’exclusivité dynamique sur l’ensemble des entités possédées par la fenêtre.
Tout d’abord, le type du membre entities de la classe Window n’est plus Vec<Entity> mais Vec<std::cell::RefCell<Entity>>, qui offre l’interior-mutability.

Évidemment, partout où nous manipulions un vecteur d’entités, maintenant il faudra manipuler un vecteur de RefCell d’entités, notamment dans la fonction add_entity().
Assurez vous d’ajouter au vecteur un RefCell d'Entity.

L’accès aux éléments du vecteur entities doit se faire uniquement par références partagées (non-mutables) et vous demanderez un accès explicite exclusif ou partagé au moment précis où il faudra y accéder :

Faites fonctionner votre application, vous devez avoir le même résultat qu’avant.

Nous ne sommes pas encore prêts pour ajouter les animators Collide et Repulse.
En effet, les deux auront besoin d’accéder à l’ensemble des entités de la fenêtre.
En conséquence, le type Window doit fournir un accès en lecture à l’ensemble des entités qu’elle contient.
Accédez à cet ensemble par le biais d’une slice.

Un dernier changement nécessaire dans le type Window consiste à sortir stay_inside() de la boucle des fonctions Window::animate() et Window::click() car désormais n'importe quelle entité pourra modifier n'importe quelle autre.
Il faut théoriquement contrôler les invariants de toutes les entités pas seulement celle qui vient d’être animée ou cliquée.
Pour bien organiser le code, déplacez ce contrôle vers une fonction dédiée de Window et invoquez-la après le clic et l’animation de toutes les entités.
Appelez la fonction adjust().
Elle doit simplement invoquer la fonction stay_inside() du type Entity sur chaque entité contenue par la fenêtre.

Enfin, il faut intervenir sur la fonction animate() du trait Animator.
En effet, elle attend en paramètre la taille de la fenêtre d’appartenance.
Ceci était correct avant mais il ne l'est plus maintenant, vu que les entités contenues dans la fenêtre seront modifiées par les nouveaux animators que nous voulons ajouter.
Il faut alors passer toute la fenêtre et pas seulement sa taille.
Étant donné que nous nous appuyons sur la notion de l’exclusivité dynamique dans Window, l’accès à la fenêtre devra se faire par référence partagée (non-mutable).
En suite, comme expliqué précédemment, l’accès aux éléments du vecteur d’entités sera demandé explicitement grâce aux fonctions borrow() et borrow_mut().
Adaptez bien votre code pour partout où la fonction animate() doit être invoquée afin de passer la fenêtre entière à la place de sa taille.

À présent, nous sommes prêts pour faire collisionner et se repousser les entités.

Déclarez une classe Repulse dans le fichier animators.rs.
Cette classe a besoin d’une donnée membre réelle coef qui représente le coefficient de répulsion.
Son bloc impl doit fournir un constructeur.
Ensuite, il faut implémenter le trait Animator pour le type Repulse.
Dans ce deuxième bloc impl, vous devez définir la fonction abstraite animate().
Cette fonction doit passer en revue les entités de la fenêtre✍ et pour choique entité elle doit : Lisez le prototype de la fonction repulse() pour comprendre comment l’invoquer.
Évidemment, la distance entre deux entités est la somme de leurs rayons du cercle englobant.

Testez ce nouveau Animator en utilisant 100.0 comme coefficient de répulsion.

Déclarez une classe Collide dans le fichier animators.rs.
Cette classe a besoin d’une donnée membre réelle elasticity qui représente le coefficient d’élasticité.
Son bloc impl doit fournir un constructeur.
Ensuite, implémentez le trait Animator pour le type Collide.
Dans ce deuxième bloc impl, vous devez définir la fonction abstraite animate().
Cette fonction doit suivre presque les même étapes que celle que vous venez de coder pour le type Repulse.
La seule différence est qu’il y aura interaction entre deux entités seulement si leur distance1 est inférieure à la somme de leurs rayons du cercle englobant.
L’interaction se fera à l’aide de la fonction collide() fournie par le type KineticState.
Lisez le prototype de cette fonction pour comprendre comment l’invoquer.
La masse d’une entité est égal à son rayon au cube.

Testez ce nouveau Animator en utilisant 0.75 comme coefficient d’élasticité.