[Général] De la compréhension des classes et de la conception

Bonjour,

Cet article vient un peu en complément de ce tutoriel : Tuto RGSS3 n°1: Les bases de la prog et notre 1er script

Et d'autres sûrement. Je vois dans beaucoup d'articles, qu'on parle de classes, de méthodes, d'attributs, mais savez vous exactement ce que c'est et à quoi cela sert ? Cet essai a pour but de démystifier certaines choses, non pas de manière exhaustive mais de manière à ce que la plupart puisse comprendre ce qui se cache derrière tout cela.

J'ai également vu un topic qui parle un peu de choses similaires. Mais j'aimerais apporter ma pierre à l'édifice et le but de cet article est d'abord de permettre à n'importe qui de comprendre en étant le plus pédagogue possible, ce qui fait que cet article est très bien destiné à un public averti, qu'à un débutant.

On va dire que j'expose ici les fondements du scripting ou de la programmation en général mais en essayant de la rendre la plus accessible possible, avec des exemples concrets.

Si vous comprenez tout ce qui suit, alors vous verrez que les scripts Ruby et même le code en général vous paraîtra beaucoup plus simple à assimiler. Oubliez les syntaxes, les “define” ou autre “@variable” ici on ne parle que de principes.

Une classe : qu’est ce que c’est ?

Si je devais donner une définition à une classe, je pourrais dire ceci : Une classe est une entité cohérente qui répond à un paradigme métier bien défini.

Tout ce charabia n’a aucun sens pour vous peut être mais en réalité c’est très simple à comprendre.

Définissons le paradigme ensemble. C’est quoi déjà le paradigme ? en français c’est “une manière de voir les choses et le monde”. Si je prend pour exemple une table, c’est un objet qui vous parle. Et bien voyez un peu :

Pour l’écolier : une table c’est un bureau sur lequel il travaille, et dans lequel il peut ranger ses cahiers (casier)

Pour un restaurateur : Une table est un élément qui définit un ou plusieurs clients qui vient consommer dans son restaurant (table 32, 34 etc….)

Pour un ébéniste : Une table mesure 350 cm / 100 cm, en merisier

Etc…

Alors vous voyez ? Une table peut être vu de tellement de manières différentes, c’est cela le paradigme. C’est pour cela que tout à l’heure j’ai parlé d’entité cohérente, car en fonction de ce que vous voulez faire, votre “classe” devra avoir une bonne raison d’exister et être cohérente avec l’ensemble du projet que vous voulez créer. Donc on ne crée pas une classe au hasard ou à tout va parce que cela fait beau non, on crée une classe parce qu’elle est cohérente par rapport au projet et aussi parce qu’elle permet de le structurer

Structurer ? oui absolument. Prenons l’exemple d’une figurine d’un jeu de rôle. Cette figurine a été dessinée, puis on en a fait un prototype. Une fois que le prototype a été validé, on en a fait des centaines pour les vendre.

Mais croyez vous vraiment qu’on a tout refait à chaque fois pour chacune des figurines ?  non ! On est plus intelligent que cela ! On fait un moule, un patron. Ce moule contient des propriétés propres à notre figurines et grâce à lui on a plus qu’à passer le patron (ou le moule comme vous voulez) dans une machine et la machine est capable de nous en fabriquer des centaines !

Des attributs par ci, des attributs par là...

Et voilà, vous avez compris ce qu’est une classe, et à quoi elle sert (de base du moins). Il s’agit ni plus ni moins d’un patron / moule / template qui va nous permettre de créer pleins de petites figurines identiques (ou presque). Pourquoi presque ? ben, c’est chouette ma figurine est marron mais moi j’en veux une violette ! Faut refaire le moule ? non c’est pour cela qu’une classe c’est chouette. Regardez on va schématiser :

Moule Figurine Orc (c’est ma classe)
couleur
taille
poids

Et voilà une classe toute belle : J’ai ici un moule qui permet de fabriquer une figurine Orc il me suffit de lui donner sa couleur, la taille que je veux, le poids que je veux et hop la machine me crée tout ca, c’est pas magique ? Bon il manque ce qu'on appelle les méthodes mais ca, on verra plus tard.

Voilà, vous venez d’apprendre à quoi correspond les attributs d’une classe. Il s’agit tout simplement de l’ensemble des propriétés qui la composent (couleur, poids etc...). Ainsi notre “patron” va nous permettre d’instancier (c’est le mot exact) des objets.

Attention que ce soit clair : une classe n’est pas un objet, c’est ce qui permet de créer les objets, c’est le moule.

C’est la que la cohérence prend tout son sens. Dans un jeu vidéo par ex de course automobile, la voiture pourrait être une classe, car elle est un éléments cohérent par rapport à mon projet, par contre, pensez-vous que faire une classe “essence” c’est cohérent dans mon jeu de voiture ? est ce une entité ? ne serait ce pas plutôt….un attribut ? (une propriété) comme “le carburant” ?

Vous voyez il faut rester cohérent. Un autre exemple, un garage de voiture. (Là on rentre plus dans une partie “hors jeu”), mais, si je devais par exemple concevoir un logiciel de gestion de parking automobile, est ce que ca serait cohérent de faire des voitures une classe ? La réponse est : “peut être que oui” , “peut être que non”.

Pourquoi ? On en revient à la même question : quel est le paradigme métier ? (on appelle métier les entités (ou classes) qui sont cohérentes avec la question qui se pose, prenez comme exemple l’ébéniste et la table de tout à l’heure) : Est ce que dans mon parking j’ai besoin de savoir que la voiture qui vient de entrer est une Mercedès  ou une Bmw, de couleur grise avec une antenne radio de 10 cm ? On s’en fout un peu non ? tout ce qui importe c’est de savoir si il y a une entrée et si il y a une sortie et combien de sou j’ai gagné, le reste n’a pas d’importance. On aurait donc tendance à mettre en classe les bornes d’entrées et de sorties et non les voitures.

Maintenant si mon but c'était de faire des statistiques pour savoir combien de Bmw viennent se garer chez moi, là effectivement, faire une classe "Voiture" semble plus cohérent.

Tout cela pour dire qu’il faut bien réfléchir à pourquoi je crée une classe et, est ce qu ‘elle est cohérente dans le projet, et surtout, est ce que je vais avoir besoin de créer plusieurs objets du même type ! (n'oublions pas qu'une classe est un patron ou un moule qui permet de créer plusieurs objets du type qu'elle représente !).

[La suite bientôt….]