Comme indiqué dans l'introduction de cette série de laboratoires, nous voulons peupler une fenêtre graphique avec des entités d'aspect et de comportement différents.
Pour le moment, pour simplifier, nous n'avons travaillé que sur des carrés.
Comment pouvons nous introduire de nouvelles formes graphiques ?
Faire des copies du type Entity en le changeant de nom et en réadaptant un petit peu le code pour avoir des cercles, des rectangles, des triangles, etc. pourrait sembler une solution rapide.
Pourtant, elle est certainement la solution la moins facile à écrire proprement et à maintenir.
En effet, en répétant le code plusieurs fois, des erreurs deviennent inévitables.
En outre, ce code ne garantirait en aucun cas que toutes les entités graphiques offrent les mêmes fonctionnalités (en cas d'oubli d'une fonction dans une nouvelle classe, par exemple).
De plus, ajouter une nouvelle forme impliquerait plusieurs modifications dans le code existant, notamment dans la classe Window qui devrait alors invoquer les fonctions de chaque type de forme graphique pour dessiner, animer et faire réagir au clic.

Ce dont nous aurions besoin c'est d'un mécanisme qui permettrait de spécifier le comportement que tout objet graphique doit garantir et qui permettrait à la classe Window de traiter tous ces objets de la même façon.
La classe Window les traiterait comme s'ils étaient tous du même type sans avoir besoin de savoir s'il s'agit d'un cercle, d'un rectangle, ou d'un triangle, etc. et donc d'écrire du code spécifique pour chaque type d'objet graphique qu'elle contient.
En d'autres termes, nous avons besoin pour tous ces objets graphiques d'une abstraction commune qui fixe une fois pour toutes le comportement que tout objet graphique fournit.

Cela tombe bien, la programmation orientée objet nous offre précisément un tel mécanisme qui s'appelle une interface.
Pour rappel, l'interface en POO spécifie le comportement (ensemble de fonctions) que toute classe qui l'implémente doit garantir.
L'interface déclare alors un ensemble de fonctions abstraites, qui ne possèdent pas d'implémentation, ou de fonctions concrètes avec une implémentation par défaut.
Tout type implémentant l'interface s'engage à fournir une définition pour chaque fonction abstraite, peut aussi redéfinir les fonctions default ou les hériter telles quelles. Un type implémentant une interface hérite aussi du type de l'interface même.
Par exemple, supposons que nous ayons une interface I et trois classes A, B et C qui l'implémentent.
Toute instance de A sera à la fois de type A et I, tout instance de B sera à la fois de type B et I... En d'autres termes, toutes les instances de A, B et C sont aussi de type I, ce qui assure qu'elles ont un type abstrait commun et ont toutes le même comportement.
Ce comportement se décline différemment selon les besoins, les classes A, B et C implémenteront à leur façon les fonctions de l’interface, qui sont donc polymorphes.
Ce polymorphisme est un des concepts fondamentaux de la POO.

L'interface est désormais un mécanisme fondamental de la programmation orientée objet et les langages orientés objet fournissent des moyens et des mot clefs pour les déclarer.

Pour notre problème, nous allons nous servir de ce mécanisme et nous allons modifier l’architecture de notre code pour suivre le diagramme de classes suivant :

Le type Entity ne s'occupera plus directement de son dessin, en revanche, il sera lié par une composition à 1 composant à l'interface Shape.
Cela veut dire qu'Entity pourra posséder un objet de n’importe quel type qui implémente Shape.

Commencez alors par fournir l’interface Shape. En Rust, une interface s’écrit en déclarant un trait.
Pour rappel : un trait définit un ensemble de fonctionnalités que différents types (implémentant le trait) possèdent et partagent.

Déclarez le trait Shape dans le fichier simu.rs (après la classe Entity, par exemple).
Ce trait doit déclarer toutes les fonctionnalités que n’importe quel type de forme graphique doit fournir, on parle aussi de comportement partagé (shared behavior).
En analysant attentivement la classe Entity dans son état actuel, nous remarquons que savoir se dessiner et fournir le rayon de son cercle englobant sont deux comportements strictement liés à sa forme graphique.
Le trait Shape doit alors déclarer deux fonctions abstraites : Évidemment, le trait Shape ne peut pas fournir d’implémentation pour ces deux fonctions, il ne possède aucune information spécifique à une quelconque forme graphique.

L’implémentation de ces fonctions ne pourra être fournie que par les types implémentant le trait.
Le diagramme de classes nous montre déjà le premier type implémentant le trait Shape que vous devrez fournir : la classe Rectangle.

A présent, déclarez la classe Rectangle dans un nouveau fichier shapes.rs (ce fichier fournira toutes les types de formes graphiques).
Un rectangle représente un concept bien concret, donc il doit contenir les données membres qui le caractérisent (vous pouvez les voir écrites explicitement dans le diagramme).
Dans le bloc impl de la classe, définissez un constructeur, new().

Ensuite, il faut fournir une implémentation du trait Shape pour le type Rectangle.
Dans ce deuxième bloc impl, vous devez définir les deux fonctions abstraites déclarées dans le trait.
Leur implémentation est très faciles à faire.
Pour ce qui concerne la fonction bounding_radius(), rappelez vous que le rayon du cercle englobant d'un rectangle est la moitié de sa diagonale.
Pour la fonction draw(), vous ne devez que déplacer le code implémenté dans la fonction homonyme de la structure Entity et l'adapter un petit peu.
En effet, dans Entity, cette fonction était conçue pour un carré.
Heureusement, la différence entre un carré et un rectangle est assez évidente !

Remarquez aussi que la fonction draw(), pour dessiner la forme graphique, a besoin d'en connaître la position.
Si cette information était directement accessible quand la fonction draw() appartenait à la classe Entity, cela n'est plus le cas maintenant.
C'est pour cette raison que le prototype de la fonction draw() a changé lorsqu'elle a été déclarée dans l'interface Shape.
À présent, pour qu'elle puisse obtenir la position de l'entité, elle doit recevoir une référence sur l'entité même et, évidement, la classe Entity doit fournir un accès en lecture à la donnée membre kinetics et à sa couleur.
Remarquez aussi que la classe Rectangle contient la donnée membre filled.
Cette donnée indique si le rectangle doit être plein ou vide. Prenez-la en compte dans la fonction draw().

Maintenant que le trait Shape et une première classe qui l’implémente sont disponibles, modifiez la classe Entity afin de suivre le diagramme de classes.

Le type Entity ne s'occupera plus directement de son dessin, en revanche, il sera lié par une composition à 1 composant à l'interface Shape.

Évidement, Shape ne représente pas un type concret mais seulement un ensemble de comportements partagés par plusieurs types.
Cela implique que la donnée membre shape de la classe Entity ne peut qu'être un pointeur.
En effet, la seule chose qui nous intéresse ici, c’est que la donnée possédée par Entity soit d’un type fournissant une implémentation du trait Shape et pas du tout un type spécifique.
Rappel : du moment où Rectangle implémente le trait Shape, toute instance de la classe Rectangle est aussi de type Shape.
En Rust, il faudra utiliser le smart pointer Box<dyn T>.
En particulier, dans Entity il faudra un smart pointer capable de pointer n’importe quel type qui implémente le trait Shape :

Tout ce qui concerne la forme graphique sera dès à présent géré en passant par le pointeur shape.
Cela veut dire que la classe Entity n'a plus besoin de contenir les données membres concernant sa taille ou le rayon du cercle englobant.
Remarquerez qu'effacer ces données membres impactent plusieurs fonctions de la classe Entity :

Dans l’état actuel, le code présente des erreurs… en effet, le constructeur de la classe Entity a changé et la façon d’instancier des objets de ce type dans la fonction populate_window() du fichier lib.rs n’est plus correcte.
Il faudra, notamment, passer au constructeur un smart pointer Box pointant sur un objet dont le type implémente le trait Shape.

Pour cela, avant tout instanciation d’une entité, déclarez un Box<dyn Shape> pour qu’il pointe sur un rectangle dont la largeur et l’hauteur sont des valeurs aléatoires entre 50 et 100.
Passez ce pointeur au constructeur du type Entity.
Faites en sorte que des 16 objets instanciés la moitié soit des rectangles pleins et une moitié des rectangle pas pleins.

Si votre code est correct, le lancement de l’application montrera une fenêtre graphique contenant 8 rectangles pleins et 8 rectangles vides de couleur, dimensions et position aléatoires.
Ces objets graphiques se déplacent, tournent, restent toujours visibles et réagissent au clic.

Classe Circle En vous inspirant du code écrit pour la création de la classe Rectangle, ajoutez une classe Circle.
Pour vous aider dessinez-la avant dans le diagramme de classes, ce qui vous permettra de réfléchir aux données membres que ce type doit avoir pour représenter un cercle.
Pour dessiner un cercle, il faudra utiliser la fonction ellipse() fournie par le type s5::Screen.
Remarquez que cette fonction doit recevoir un Rect : ceci est le rectangle qui englobe l’ellipse à dessiner.
Pour un cercle, ce rectangle doit être un carré dont le côté mesure deux fois le rayon du cercle.

Modifiez la fonction populate_window() du fichier lib.rs pour que la fenêtre graphique contiennent : chacun avec sa propre dimension et cinématique.

Testez votre code, vous devriez voir apparaître les cercles avec les rectangles.