bonjour à tous, ici j'aimerai poser une question qui concerne tous les langages permettant l'OO.

Perso moi j'en fait en Python et en C++.

J'aimerai savoir une chose :

j'ai une class Personnage.

j'ai une class Inventaire.

j'ai une class Mana (qui gere ET la mana ET les sorts).

dois je faire une class Vie qui gererai la vie et les degats pris, ou bien intégrer cela à Personnage ?

merci à vous

Lu'!

Une première idée importante est que dans le cadre d'un RPG, le modèle orienté objet est, pour être politiquement correct, atrocement limité (quand est politiquement incorrect, on dira "tout perrave"). On préférera se diriger vers les modèles à composants car ils permettent de créer des entités répondant à de très nombreuses variations de comportements assez facilement (une fois le système implémenté) et en limitant la duplication de code. Voir cette longue discussion sur le forum C++ (le début est ce qu'il ne faut pas faire).

Ensuite concernant l'approche orienté objet de manière plus générale, je vais commenter les idées que tu introduits par ces deux points :

Lubzorg a écrit:

j'ai une class Mana (qui gereET la mana ET les sorts).

dois je faire une class Vie qui gererai la vie et les degats pris, ou bien intégrer cela à Personnage ?

Le mot gérer. Il ne veut strictement rien dire. Ou plutôt, il veut dire tout et n'importe quoi (et surtout n'importe quoi). Dans pas mal de langage le choix des mots est hyper important parce qu'ils nous en disent beaucoup plus sur la sémantique des éléments que l'on manipule. Et donc, le mot "gérer" n'est pas précis, il n'a aucune substance. Plus d'informations à propos de la notion de gestion en programmation : Emmanuel Deloget - De la gestion des gestionnaires.

En l'occurrence, la "gestion" ça implique un certain nombre de tâches, et une classe ne doit avoir qu'une et une seule responsabilité. C'est le premier principe SOLID, le principe SRP pour Single Responsibility Principle. Et donc typiquement :

Lubzorg a écrit:

j'ai une class Mana (qui gere ET la mana ET les sorts).

C'est une erreur de conception. Ta classe à plusieurs tâches différentes alors qu'elle ne doit en assurer qu'un.

J'en viens finalement à mon dernier point au sujet de ton post :

Lubzorg a écrit:

dois je faire une class Vie qui gererai la vie et les degats pris, ou bien intégrer cela à Personnage ?

Petite piqûre de rappel : les classes sont des fournisseurs de services. Pour savoir si ta classe est justifiée, il faut que tu te demandes quel service elle te rend. Et force est de constater que c'est plutôt pas mal que la vie soit un objet, la vie du personnage c'est l'élément qui nous permet de déterminer (passivement et activement) l'état vital du personnage qu'on lui a associé à la construction. Passivement par des fonctions membres comme "mort()" et activement avec des modifieurs comme "altérer(valeur)".

Finalement, j'en viens au points généraux à la programmation orientée objet, dans les principes SOLID, j'ai déjà parlé du SRP.

On a ensuite l'OCP pour Open Closed Principle, une classe doit être ouverte aux extensions (on doit pouvoir créer des classes exploitant son comportement mais en modifiant une partie) mais fermé à la modification : une fois la classe validée on ne veut pas que le besoin d'extension du programme nous demande de la modifier (au risque d'introduire des bugs).

Puis le LSP (un des plus important) pour Liskov Substitution Principle qui nous dit que B ne peut hériter de A que si B est effectivement un A et donc que si dans le programme, je remplace un objet A par un objet B ça doit continuer à fonctionner. Autrement dit : B doit respecter l'invariant de A et pour chaque fonction membre sa pré-condition doit être au moins aussi permissive et sa post-condition au moins aussi restrictive.

L'ISP pour Interface Segregation Principle, nous dit qu'il vaut mieux privilégier des interfaces spécifiques (et donc peu fournies) plutôt que des interfaces généralistes qui font la pluie et le beau temps (ça rejoint en partie le SRP).

Et finalement le DIP pour Dependency Inversion Principle nous dit qu'il faut dépendre non pas des implémentations des classes (leur fonctionnement interne) mais des abstractions qu'elles définissent : leurs interfaces. C'est très important car c'est ce qui nous permet de modifier intégralement le code d'une classe si besoin (pour les performances par exemple) sans que les utilisateurs n'aient à faire la moindre modification dans leur code.

On peut rapprocher ce principe de la loi de Demeter, qui nous dit que l'on ne doit dialoguer qu'avec quatre catégories d'objets : nous même, nos composants, les variables locales que l'on crées et les variables que l'on reçoit en paramètre. Typiquement, on ne doit pas aller chercher un composant interne d'un paramètre pour dialoguer avec lui.

L'exemple le plus courant est le traditionnel combo dégueux getter/setter. La la loi de Demeter nous dit que faire un truc comme machin.getBidule().setTruc(42) c'est moche, et elle a raison parce qu'en se limitant à dialoguer avec nos voisins directs on limite énormément la portée des effets de bord.

Qu'on soit clair : les effets de bord peuvent être nécessaires, mais doivent être effectués par l'intermédiaire des interfaces prévues car de cette  manière elles sont bien plus clairement définie et beaucoup plus prévisibles. Après, les getters ne sont pas nécessairement atroces, s'ils sont effectivement un service fournit par la classe (comme l'accès à la case d'un tableau) mais quand on a besoin d'un getter, prendre le temps de se demander "est ce que c'est une bonne chose ?" est important. Les setters sont bien pires parce qu'ils modifient carrément l'objet de manière intrusive. Voir les liens de ce message.

wouah

merci pour cette réponse tres complete, je pense carrément la mettre en favori

dans ce cas, j'ai quelques lignes à modifier