UML et "penser objet"

Bonjour,

Je débute en POO, et j'ai un peu de mal à penser correctement toutes les liaisons. Je fais un petit projet (sans but) histoire de m’entraîner, une sorte de RPG. Voila ce que j'ai fait actuellement (avec Dia):

Mais je me demandais comment gérer certains trucs. Je poste ici en espérant avoir de l'aide/pouvoir être guidé dans cet… entrainement.

Voila comment je vois la suite : - Je souhaite faire un magasin. Il faudra donc une classe Magasin ? Elle aurait un tableau d'objet comme attribut, et des méthodes supprimerObjet, ajouterObjet. - Si par exemple, on peut aller dans différents endroits, comme la forêt, le désert, l’arène, il faut aussi des classes ? Ou bien ca sera juste des pages php différentes ?

Merci de votre aide !

L'image (https://lh5.googleusercontent.com/aG_FB-24WPDSssmv6PyB-LPG2orfVnT-gbM0moJttegXhPjsVNSu13wA3zZUbj9YAs3n1Wutc4A=w1342-h523) renvoie une 403.

J'ai rehost l'image. C'est bon ?

L'UML ce n'est pas que des diagrammes de classes. Je dirais même que le diagramme de classes n'est pas le plus important et vient généralement après un bon diagramme de cas d'utilisation.

Notons qu'à part le diagramme de classes, l'UML n'est pas nécessairement destiné à de la conception orientée objet.

Ensuite, je pense que tu ne te poses pas les bonnes questions et avec aussi peu d'élements cela va être difficile de t'aider sans faire des hypothèses qui biaiseront nos réponses. Dans un premier temps, par rapport à ton jeu, écrit en bon français ce qui doit se dérouler, dans ton magasin, quelles seront ses intéractions avec le joueur, ce qu'il devra proposer, etc.

Ensuite seulement, à partir de ton analyse tu pourras commencer à réfléchir en terme de conception : quelles sont les entités dont j'ai besoin, les services offerts et les responsabilités de chaque entité, etc.

Il y a tellement de manière de modéliser de magasin qu'il y a de jeux. Dans certains jeux, le magasin a proprement parlé n'est qu'un écran de menu où tu sélectionnes des choses, dans d'autres comme Pokémon, c'est plus ou moins statique dans le sens où à n'importe quel moment tu trouveras la même chose dans le magasin, et dans des jeux comme Skyrim tu as des systèmes plus complexes de gestion des marchandises en fonction de l'environnement et d'autres paramètres, ainsi que de fortes interactions entre le décors et les PNJ.

Tu comprendras donc qu'il n'est pas forcément possible de répondre à ta question aussi facilement du fait qu'elle fait figure de cas isolé.

@Hod : Oui je vois. Tu veux dire que je devrais pas m'occuper de faire des diagrammes de classe pour le moment et juste marquer en français quoi fait quoi. Et ensuite, au cas par cas je poserais des questions si je vois pas comment faire les liens.

J'ai bien compris ?

Après, j'essaye surtout de bien comprendre les notions de POO plutôt que faire un vrai projet.

@artragis : Merci.

Pour les méthodes, je veux bien, pour l'attribut, en fait il est induit car tu as une relation entre le Magasin (qui est bel et bien une classe du coup) et la classe Objet (un lien d'Aggrégation)

Je ne comprend pas bien ce que tu veux dire. Un objet serait un bout du magasin ? :S

Concernant la carte, je comprend la différence, merci beaucoup !

Non, l'agrégation, quand elle est suivie d'une cardinalité (on dit aussi "multiplicité", ça dépend de l'année de naissance de la personne qui t'explique les choses, multiplicité étant plus "moderne") "0-n" signifie "il y a une collection d'Objet dans Magasin".

Je vois. Merci. En créant ce sujet je m'attendais plus à des remarques du genre de artragis.

Je n'arrive pas à voir quelle liaison entre l'inventaire et le personnage. une association ? D'après ce que tu as dit pour l'aggregation entre Objet et Magasin, il y en aurait une aussi entre Objet et Inventaire du coup, non ?

Merci.

Effectivement, il y aurait une composition simple entre un inventaire et un personnage. Typiquement, quand tu as deux objets, disons A et B, pour savoir si tu dois utiliser un héritage ou une composition, tu dois te poser la question:

• Est-ce que B est un A ? Si oui, alors il y a très fort à parier qu'il s'agisse d'un héritage.
• Est-ce que B possède un A ? Si oui, alors il y très fort à parier qu'il s'agisse d'une composition.

Pour illustrer ces questions voyons Personnage et Joueur:

• Est-ce qu'un Joueur est un Personnage ? Oui !
• Est-ce qu'un Joueur possède un Personnage ? Vraisemblablement non.

La relation d'héritage est bien plus pertinente.

Voyons dans le cas d'un Inventaire et d'un Joueur :

• Est-ce qu'un Inventaire est un Joueur (et inversement) ? Vraisemblablement non.
• Est-ce qu'un Joueur possède un inventaire ? Oui !

Donc il faut privilégier ici une relation de composition.

Maintenant, pour savoir si la composition se fait au niveau du Joueur ou du Personnage il faut se reposer la question. En général il faut se reposer la question pour chacune des niveaux d'héritage pour savoir où placer la composition.
Et là on rejoint mon propos sur le fait que l'on n'a pas assez d'information pour critiquer ce choix:

• Est-ce qu'un Joueur a un Inventaire ? Oui, sans trop de question !

Donc on regarde au dessus: est-ce qu'un Personnage possède un Inventaire ? Cela va dépendre de IA (et donc des personnages non joueurs). Dans le cas de Pokémon ou d'autres jeux, les NPC n'ont pas besoin d'un inventaire et n'en possèderont pas. Dans d'autres jeux comme Skyrim, ils en ont un, même accessible par le joueur (par exemple en volant), et enfin dans d'autres jeux comme les Final Fantasy, certains en ont mais ne sont pas accessibles par le joueur.

Dans les deux derniers il est donc préférable de faire la composition au niveau de la classe Personnage, alors que dans le premier cas on pourrait se contenter de le faire au niveau du Personnage. Sans analyse de tes besoins, il est difficile donc de répondre avec certitude à cette question.

Donc, si je comprend bien, plutot que de faire un attribut loot (type array) dans l'IA (qui representerait une liste d'objets qu'on peut avoir en tuant cet IA) ce serait mieux de faire une composition d'inventaire avec l'IA. Et ainsi vu que le joueur aussi a un inventaire, faire la composition avec la classe Personnage. C'est bien ca ? Je sais pas si je suis clair.

Merci.

Lu'!

D'abord quelques notions importantes à propos de l'orienté objet :

• SOLID.
• Loi de Demeter

Ensuite, concernant ce type d'architecture. L'objet n'est généralement pas très adapté pour les jeux types RPG (j'ai vu la mention de Skyrim plus haut, c'est typiquement pas ce qui y est fait). Généralement le choix porte pour les architectures à composants (le plus répandu étant l'Entity Component System), c'est plus flexible et moins lourd en code (un fois la structure de l'ECS implémentée : donc il faut que ça vaille le coût).

Concernant l'architecture actuellement, j'aurai tendance à dire les choses suivantes.

Tes objets sont actuellement plus des objets de stockage que des objets de services, et on veut éviter cela. Typiquement ton inventaire : pourquoi as-tu un getter (déjà j'aime pas les getters : voir les liens de @lmghs plus bas.) qui te renvoie le contenu sous forme de tableau ? Pourquoi les objets ont autant de getters ? Ils ne rendent approximativement aucun service (je ne cherche pas à te dire que tous tes getters sont invalides, mais à te pousser à repenser aux services que te rendent les objets … Objet, groumf).

Rappel : un objet est un fournisseur de services, pas de stockage.

Pour l'héritage au niveau du personnage, je ne suis que moyennement d'accord. En l'occurrence, si on veut être très générique, la seule différence entre un monstre/ennemi et le personnage joueur, c'est leur centre de décision, et concrètement pas besoin d'un héritage pour ça : le centre de décision dans un cas c'est un IA, dans l'autre c'est le contrôleur (clavier/souris) et on pourrait même imaginer que ce soit le réseau parce qu'on en a rien à carrer : on veut juste qu'un élément déclenche des actions sur le Personnage. Donc c'est juste un composant (qui lui peut être polymorphique) qui a une fonction membre "faitQuelqueChose()" (et qui reçoit l'objet dont il a la charge à sa construction).

Bon pratique pour penser la structure de ton programme. Ne met aucun champ interne dans tes objets (aucun) : juste leurs interfaces, et regarde si les dialogues te semblent cohérent.