UML et "penser objet"

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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):

Diagramme UML

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 ! :)

Édité par The_Lord_King

+0 -0

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

Édité par Vayel

+0 -0

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é.

+0 -0
Staff

Cette réponse a aidé l'auteur du sujet

Alors, il y a du très bon dans ton schéma. Ce qui m'embête c'est qu'il n'y a pas de liaisons entre les différents arbres. Typiquement un Joueur a un Inventaire qui possède de 0 à un nombre indéterminé d'objets. Il faut donc que tu implémente ça.

Maintenant, ce qui me fait très plaisir dans ton schéma c'est que l'Héritage est bien utilisé. Tu n'as pas tenté de faire un peu tout et n'importe quoi avec l'héritage comme on le voit parfois dans les tuto. On a vraiment un truc bien fait avec une vraie réflexion logicielle derrière. Continue comme ça !

Elle aurait un tableau d'objet comme attribut, et des méthodes supprimerObjet, ajouterObjet.

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)

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 ?

Je pense que pour éviter toute confusion, tu dois comprendre quand on parle de quoi.

  • une page est un élément d'interface homme machine, il permet à l'utilisateur de dialoguer avec ton logiciel;
  • une classe est un élément de la conception de ton logiciel, de sont organisation conceptuelle.

Ainsi, comme ça, à vue, j'ai envie de dire "les deux". Tu auras une page sur laquelle la carte s'affichera mais en tant que développeur, tu vas représenter le "concept" de carte avec une classe "Carte".

+0 -0
Auteur du sujet

@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 ! :)

+0 -0

Cette réponse a aidé l'auteur du sujet

@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 ? ^^

The_Lord_King

La conception d'un logiciel correspond à un ou plusieurs besoins pour un client. En tant que particulier et amateur, tu es ton propre client évidemment, mais au final, tu as envie de créer un logiciel pour un certain nombre de choses. Dans le cas d'un RPG tu veux produire une certaine expérience de jeu, un gameplay particulier, et que sais-je encore !
La première étape est donc de poser tes besoins, tes attentes et tes ambitions vis à vis de ce projets et décrire autant que possible ce que tu veux faire (il y a toujours possibilité de raffiner par la suite évidemment). Normalement, c'est le client qui fait cela et généralement il n'est pas spécialiste du développement logiciel (sinon, il le ferait soit même !) et ne parlera donc pas en termes techniques..

Ensuite intervient donc l'expert qui va à partir des besoins établir des documents plus ou moins techniques (je ne rentre pas dans les détails car ça n'a pas trop d'importance dans ton cas), qui vont traduire ces besoins en modèles qui vont permettre l'implémentation.

J'aime bien parler en termes de client / experts (on parle plus de maitre d'ouvrage / maitre d'oeuvre dans le milieu professionnel pour la culture) qui peuvent sembler inapproprié pour un jeune autodidacte qui veut simplement apprendre et faire un projet sur son temps libre, car ce vocabulaire permet séparer les rôles qui sont mélangés dans le cas présent.

Tout ça pour dire que sans l'expression claire des besoins initiaux, il est difficile de répondre ou de critiquer une architecture ou des documents techniques si ce n'est sur des points très génériques (comme l'a fait artragis par exemple).

+0 -0
Auteur du sujet

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. :)

+0 -0

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.

+0 -0
Auteur du sujet

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. :)

+0 -0

Lu'!

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

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.

Édité par Ksass`Peuk

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte