Conception : classe intégrateur

Conception : classe intégrateur

par Léonard Georges Théodore Lebrun,
Number of replies: 1

Bonjour,


Dans le cadre de l'implémentation de la classe intégrateur, vous recommandez une méthode prenant en paramètre une référence sur une toupie.

Afin de rendre la classe intégrateur plus portable, pourquoi ne pas faire le contraire, et appeler plutôt un intégrateur au sein d'une méthode "evolue" de la classe toupie? Ainsi la classe intégrateur devient recyclable pour d'autres projets potentiels. De plus, la modification des attributs de la toupie en est rendue plus simple.

Merci d'avance pour votre disponibilité,

Bien à vous

LL et DR

In reply to Léonard Georges Théodore Lebrun

Re: Conception : classe intégrateur

par Jean-Cédric Chappelier,

Question très intéressante ! (voir en 2e partie de message). Et, oui, le but est bien de pouvoir réutiliser les intégrateurs plus tard dans d'autres de vos projets.

Mais, pour clarifier pour tout le monde, commençons par corriger quelques idées fausses ou préciser certains points peut être sous-spécifiés ici :

  • « appeler un intégrateur dans evolue() » : lequel (intégrateur) ? comment la toupie le connaît-il ?
    -> un attribut (d'instance ?/de classe ?) ; modifiable ou fixé au départ ?
    [à voir plus bas]
  • « Ainsi la classe intégrateur devient recyclable pour d'autres projets » : ce n'est pas, en soit, le fait d'appeler l'intégrateur dans evolue() qui va le rendre plus universel ; mais l'idée est bien, en effet, de le rendre plus indépendant des toupies [discuté plus bas] ;
  • « la modification des attributs de la toupie en est rendue plus simple. » : là je ne vois pas comment, à moins, justement, d'augmenter la dépendance entre les deux (comment un intégrateur universel peut il plus facilement modifier des attributs d'une toupie (spécifique) ?)
Il y a donc 2 aspects à la question :
  1. comment augmenter l'indépendance entre toupies et intégrateurs ?
  2. est-ce qu'une toupie a (= possède) un intégrateur ?
    ou est-ce qu'un intégrateur reçoit une toupie (à faire évoluer) ?
Pour le point 1 : il suffit d'abstraire, dans une classe, p.ex Integrable, les propriétés attendues par un intégrateur pour pouvoir fonctionner ; puis de faire hériter Toupie de cette classe.
C'est la 2e question qui est plus ouverte et très pertinente, d'autant plus que « dans la vraie vie » (= dans le monde Physique) les intégrateurs n'existent pas : donc, où les représenter ??

Les 2 points de vues se défendent (à mon avis) et sont liés à la vision globale que l'on a de son projet et a diverses sous-questions :
  • qui est propriétaire de qui ? ou bien a-t-on un propriétaire commun ?
  • quid en cas de plusieurs toupies et plusieurs intégrateurs ? quel sens cela a-t-il ? (p.ex. veut on comparer la même toupie avec plusieurs intégrateurs ? ou veut on comparer plusieurs toupies avec le même intégrateur ?)
  • si plusieurs (sortes de) toupies existent et qu'elles ont un intégrateur, est-ce que toutes les instances ont le même intégrateur ou est-ce que chaque instance peut avoir sont intégrateur ?
  • est-ce que l'intégrateur peut changer en cours de simulation (p.ex. pour voir les effets du changement de tel à tel intégrateur) ?
Donc, pour moi, les 2 sont possibles et si cela vous semble plus naturel d'inverser par rapport à la proposition, libre à vous.
La vue du projet est plus : il existe UN intégrateur (en gros : la façon dont le monde évolue) et cet intégrateur a la responsabilité de faire avancer/évoluer les objets du monde.
Mais, je suis bien d'accord, ce n'est qu'une vision possible parmi plein d'autres.
Merci pour la question !