P.o.o. >> On S'y Met ? :)

Bon, comme certains d'entre-vous se souvienne peut-être, je n'ai jamais été vraiment en faveur de la POO (Programmation Orienté Objet).

Seulement moi et le reste de l'équipe technique somme en train de programmer la 4ieme version du moteur de jeu CyberCity 2034.... et il commence à y avoir une sacré masser de trucs à gérer (Pour ceux qui connaissent pas trop le jeu, sachez simplement que plutot que d'axer sur l'estétisme et les mappes, nous avons choisit d'axer sur le RP et d'offrir une grande quantité d'actions possibles)


Bon, donc, en gros, c'est le bordel. Avec toutes ces fonctions au même niveau, plus personne ne s'y retrouve.



La P.O.O. deviend donc essentielle pour des raisons de développement selon moi.



J'ai donc commencer à penser à comment je pourrais "séparrer" tout ca (les classes):
- Session
- Compte
- Personnage
- Lieux
- Item
- etc...

Sauf que la j'arrive à un constat. Si je prend, par exemple, l'action DÉPLACEMENT
Je place cette méthode dans la classe Personnage ou Lieux ?
--> Et si un item permet un certain type de déplacement, l'action déplacement sera dans Personnage, Lieux ou Item ?


Bon, selon-moi, le plus propre sera de la mettre dans Personnage, puisque c'est le personnage qui se déplace. Mais à ce moment j'arrive à la conclusion que ma classe, selon des estimations rapide, fera aux alentours de 15 000 lignes de codes !!!

(oui oui, j'arrive à ma question)

Donc évidemment, je vais pas tout mettre ca dans un seul fichier, je vais inclure les méthodes via des REQUIRE('') afin de construire la classe.


Mais cela signifie quand meme que la classe Personnage sera IMMENSE (300kb de code PHP/MySQL pure). J'ai peur que ca créer un ralentissement si à chaque page PHP doit traiter autant de lignes de code pour simplement en utiliser 1000 au final.

Vous en pensez-quoi ?

J'en pense que je ne comprends rien à ce que tu dis.

Moi si un joueur me dit qu'il veut se déplacer, je lui demande simplement où il veut aller ? ...

C'est pas plus simple comme ça ?

edit : je sais c'est pas constructif, mais waooof ca soulage.

C'est celui qui réalise l'action qui doit l'engendrer. Donc c'est lui qui doit porter la méthode principale. Rien n'empêche cependant d'utiliser des méthodes des outils de l'action.

Exemple : le déplacement.
C'est le perso qui se déplace, donc la méthode deplacer($x,$y) appartient à l'instance de la classe Personnage. C'est cette méthode qu'il faudra appeler. Par contre l'action principale concernant le lieu et la mise à jour des données du lieu doit être faite... dans la classe Lieu ^^ Voici comment je coderais la chose (je trouve qu'un exemple concrètement pseudo-codé vaut mieux qu'un long discours) :

En fait, l'emplacement de la méthode dépend des données manipulées : la classe Personnage ne devrait manipuler que des données attachées aux personnages (santé, caractéristiques, points d'action, inventaire, etc...). La classe Lieu ne devrait manipuler que des données attachées au lieu (coordonnées des éléments du jeu, terrains, coût de déplacement selon le terrain, etc...).

Le déplacement d'un perso engendre :
- un coût en points d'action (le coût est calculé par Lieu, la dépense est gérée par Personnage).
- un déplacement (le changement de coordonnées est géré par Lieu).
La méthode Personnage::deplace() se contente de rassembler tout ça


Je ne dis pas que c'est la meilleure façon de faire, mais c'est ainsi que je procède. J'essaie de me rapprocher au maximum du 100% objet, en n'utilisant que deux types de méthodes (les termes n'ont rien d'officiel, c'est moi qui utilise ces termes pour ma façon de programmer, je ne crois pas les avoir vus dans un cours POO) :
- les méthodes "élémentaires" (exécution d'une requêtes sql, petit calcul, etc...).
- les méthodes "composées" (actions, calculs plus complexes, etc...).
Avec deux règles non négociables :
- les méthodes élémentaires ne doivent être composées que d'une poignée d'actions très simples (une requête, un calcul simple, une écriture dans un fichier, etc...) toutes en rapport entre elles. Exemple de Lieu::deplacerPersonnage() qui effectue une modification des attributs, puis qui écrit ses modifications en base de données : deux actions simplistes en rapport direct entre elles.
- les méthodes composées ne doivent contenir que des appels aux méthodes élémentaires ou composées, et éventuellement mais le moins possible des actions triviales (calculs tolérés : simples additions de résultats élémentaires par exemple). Exemple de Personnage::deplace() qui se contente de demander le calcul du coût à Lieu::coutDeplacement() (probablement élémentaire), de réaliser la dépense par Personnage::depensePA() (élémentaire) et de concrétiser le déplacement par Lieu::deplacerPersonnage() (élémentaire).

Hé merci !! déjà ca ca m'aide...

mais sinon, le fait est quand même que ma classe Personnage va etre monstrueusement immense...

comment PHP gère t'il ca ?
Il charge tout en mémoire?
Il charge que la structure pour ensuite charger (lire) les fonctions utilisées ?

Bref, ce point là me fait un peu peur en fait :-\


-------------
Edit:

Par exemple, le HE (Historique des évènements), la fonction qui génère la liste des messages, ca se trouve à être dans quel type de classe ? Personnage ? Affichage ? (On fait une classe affichage/page ?)

^^ C'est ce genre de trucs la que j'arrive pas encore à bien visualiser ou les caser... un message ca 'appartient' à aucun 'objet' vraiment :-\ (Un message peu-être un objet, mais alors la fonction qui génère la LISTE des message... huhu)

En POO, on pense souvent
- Objet = entité (perso, lieu, arme...)
- Verbe = méthode (se déplacer, attaquer ...)

Il est possible que certains verbes ou actions soient des objets eux même (donc des classes). Dans ce cas ce sont les classes d'action qui se chargent d'appeler les différentes méthodes "élémentaires" sur les objets.

Dans l'exemple du déplacement, la classe Deplacer_Perso a une méthode qui appelle:
- Perso->depenserPa
- Perso->deplacer
- Lieu->deplacerPerso

Tu peux ainsi utiliser l'héritage, par exemple faire une action Courir qui hérite de Se_deplacer mais avec une consommation de PA supérieure.
De cette manière tu peux réaliser des actions complexes en créant une classe action qui se compose de plusieurs classes actions simples. Par exemple Sauter_avec_elan serait une action composite de Courir et Sauter

Un avantage de classes Action est aussi que tu peux facilement faire du test unitaire : une action = un jeu de tests

Ce qui est important c'est que les données restent cohérentes : pas de PA négatifs, pas de déplacement sans consommation de PA etc. Pour cela il faut bien définir qui est responsable de l'intégrité. Si tu découpes la logique en classes d'action, alors ce sont les actions qui doivent tout vérifier. Si au contraire la classe perso a une méthode par action, alors c'est elle qui garantit son intégrité.

Dans ta classe Action tu peux ajouter une méthode qui génére l'historique des évennements. Si toutes tes classes action héritent d'une même classe, il suffit alors d'avoir un "ActionProcessor" qui crée l'action, appele action->faire_action() puis action->HE()

En effet ma façon de faire peut impliquer des classes énormes si la classe générique Personnage a un million d'actions à sa disposition. Ce n'est pas très grave, mais normalement la classe générique ne devrait avoir que des actions génériques, et donc pas tant que ça (parler, ramasser, equiper, deplacer, etc...). Mais c'est un risque en effet, je n'ai jamais eu de problème avec des classes énormes, même à l'époque de PHP4.

L'affichage ne doit surtout pas être géré par la classe générique. Tu dois avoir une autre classe d'affichage qui s'occupe de récupérer les données des différents objets et de les afficher. En général je faisais une méthode "toString()" dans la méthode générique (à vocation de débuggage bien souvent) et une méthode "toHTML($xhtml=true)" dans une classe fille. Maintenant j'ai plutôt tendance à ne mettre que toString() dans la classe Personnage, et une méthode afficherPersonnage() dans une classe Affichage, ce qui nécessite que tous les éléments nécessaires à l'affichage soient disponibles en public (ce qui n'est pas plus mal, ça permet de se cadrer tout de suite et de vite voir si on a bien publié toutes les infos nécessaires, s'il faut des getter/setter, etc...).



C'est pas bête cette histoire de classe Action, je n'y ai jamais songé je suis toujours resté collé au action = méthode. Comment gères-tu ça en pratique ? Tu mets quoi comme méthode dans ta classe Action ? Tu mets quels attributs ?

Parce que de la façon dont je le verrais (statique, avec le perso en paramètre), ça ressemblerait furieusement à du procédural :s alors je dois avoir du mal à me mettre cette histoire de classe d'action en tête :x pourtant ça semble intéressant justement avec l'héritage. Tu voudrais bien me mettre un exemple pseudo-codé avec l'exemple de courir que je vois à quoi ça ressemble ?

Qu'est-ce que tu apelle 'classe générique' exactement ?

.. Je pense que je commence à mieux comprendre pour les actions, c'est vrai que de cette facon, ca évite d'avoir 100 000 lignes dans une classe.


Mes questions à ce stade:
1) Est-ce que c'est une bonne idée de créer un fichier (ici ca serait carément l'index) qui s'occuperais de charger les classes nécésaire (exemple: session+perso+actionDeplacement)

2) En lien avec la question 1, actuelle j'utilise un paramètre GET qui donne une URL du genre:
index.php?action=deplacer
de cette facon, toute ma gestion des session et des trucs généraux (cookie, doublon, frame générique de la page, etc) est gérer dans un seul fichier, ce qui évite de faire à chaque fois, pour tout les fichier un truc du genre:

deplacement.php:
include ('header');

include ('footer');

... en réalité je sauve uniquement un footer vu que je dois inclure une page qui valide la sécurité pour éviter les accès direct mais bon... C'est surtout le fait que ca évite d'afficher trop la structure interne du site.

>> Oui, je suis au courrant que les mod_rewrite existe, mais j'ai juste jamais encore apris à les utiliser


Bref, je m'égare un peu, mais en gros la question2 c'est: est-ce que c'est une bonne facon de gérer les accès aux pages dans une conception objet ?

... en ce sens que le code qui décidera quelle classe charger (via des require) ne sera pas dans une classe, mais directement au 'premier niveau', vu que sont but est de 'générer' un code.


^^ Si vous avez rien compris, c'est pas trop grave...

Tu as une page principale action.php qui reçoit toutes les requêtes d'action faites par le joueur. Dedans il y a un switch géant qui suivant le paramêtre 'action' du GET va créer et initialiser la bonne classe Action. Dans les actions tu mets les paramétres nécessaires : en gros ça correspondrait à ce qui est mis dans le GET, plus l'id du joueur. Finalement tu appele les méthodes action() et historique()

Un exemple de ce que ça donne (en JAVA désolé ) pour deplacement et courir :

Et pour les actions composites : sauteravecelan est composite de courir et de sauter

>> Je retiend que la méthode du switch qui charge la classe nécéssaire est donc une bonne méthode.

Merci pour l'exemple, je suis justement un cours de Java en ce moment ;p

Hmmm, intéressant (attention tu as oublié ton constructeur pour ActionSauterAvecElan) mais je sais pas, je n'accroche pas au concept

Il faut que je teste un peu voir si ça apporte réellement quelque chose au niveau méthodologique, j'ai l'impression que si ça allège le code de la classe ça alourdit le code final (plutôt que d'instancier une fois perso et d'appeler ses méthodes, je dois instancier la bonne classe pour chaque action ça me botte pas a priori)

Qu'est-ce que ça t'apporte concrètement (attention hein, je ne critique pas ta façon de faire, j'essaie surtout de m'intéresser à d'autres méthodes que ce que je fais, pour évoluer) ?
As-tu des liens qui discutent de cette méthode ?

Bah en gros, moi je pense que si tes actions sont des méthodes d'une classe, ca implique que tu dois toujours charger la totalité de ta classe (donc énormément de code innutile)

Si tu créer une classe par actions, et que tu utilise un SWITCH pour charger uniquement la/les classes nécésaire, les classes innutiles ne sont simplement pas chargé:
Gain sur la mémoire du serveur et/ou sur le temps de génération d'une page


^^ C'est précisément ce qui me rebutait de la P.O.O. et c'est pour ca que j'ai posé souvent la question sous plusieurs angle dans ce sujet.

Ce que je propose c'est le design pattern Command, atricle qui en parle

L'interêt que je vois c'est de créer un "squelette" pour toutes les actions. En gros il faut à chaque fois :
- Charger les données depuis la base
- Faire un contrôle de sécurité (le joueur a-t-il le niveau nécessaire pour l'action ...)
- Faire l'action
- Sauvegarder les données en base
- Afficher le résultat.

Si ta classe action a une méthode pour chacune de ces étapes, tu es ensuite libre de l'implémenter comme tu veux dans les actions spécifiques.
De cette façon tu peux éviter de faire un update dans Perso->consommerPA et un autre dans Perso->deplacer : c'est classe ActionDeplacement qui fera un unique update tout à la fin : dans SA méthode sauverDonnees elle appelle perso.sauveEnBase.

De cette manière tu découples bien le code "intelligent" (sauter, courir...) du code base de données et du code HTML.

Je crois que je commence à percuter, ça rejoint tout à fait l'utilisation des "behaviors" en Javascript pour séparer dans la page HTML le contenu (HTML), la présentation (CSS), et les comportements (Javascript) en déportant tout dans des fichiers séparés.
Ici on ajoute à un modèle MVC classique une séparation dans la partie Modèle : l'entité d'un côté, ses actions de l'autre.

Merci pour tes explications et cet articles, et merci sybler pour ta question du coup j'apprends moi aussi quelque chose

Le coup du switch énorme peut être évité en stockant directement en base le lien vers le code. mais il est vrai que je charge en mémoire toutes les actions dispo, pour savoir lesquelles il a le droit de faire.

mon système donne :

1 - chargement
- Requete des actions dont le perso dispose, aces tous leurs paramètres
- Chargement dans une liste chaînée d'objets de la classe ACTION.

2 - Récupérer le code de l'action que le joueur veut faire
3 - Parcourir la liste (do while) pour récupérer l'objet correspondant à l'action voulue.
4 - Faire la méthode 'éxecuter' de la classe

5 - Dans la méthode exécuter :
- Contrôle que le perso a les Point d'action
- Récupération de l'objet ciblé. (peut être un item de n'importe quelle classe, perso, case, porte, piège, etc..)
- Contrôle que le perso peut ou non faire l'action. (cible visible, distance, etc...)
- include d'un fichier cond.php, spécifique à chaque sort, et dont le nom est entré en base de donnée. (donc : include(obet->fichier_de_condition); )
- Vérification des trajectoires, etc...
- Si tout va bien, l'action peut être faite. Je fais alors un include du fichier d'exécution. (un fichier par sort, stocké aussi en BDD)
- le fichier d'exécution, très simple, fait en général des appels aux méthodes de classe des autres classes.
Ex : crocheter :
je fais :
calcul des scores du voleur.
porte->ouverture->serrure->deverrouiller()
si piège sur la serrure:
porte->ouverture->serrure->piege->activer().

Le plus drôle, étant que la fonction activer() contient un appel à la méthode exécuter de la classe sort ;=)


ça marche plutôt bien.

L'avantage :

Je peux créer des actions directement depuis l'interface HTML, sans toucher au code.
Il me faut juste uploader les 2 fichiers PHP dédiés à l'action. (pas possible via l'interface, pour des raisons évidentes de sécurité)

Je peux même copier - coller une action, pour en créer une similaire, avec le même code d'exécution, par exemple, mais un coût différent. une action de plus, sans écrire une seule ligne de PHP.

je prévois de mettre un jour mon moteur en ligne. inutile de comprendre la structure interne du code pour pouvoir créer son propre jeu. il faut juste avoir des bases en PHP.

Mais je m'égare, là

uzinagaz powa

nygma : juste un détail, pourquoi as tu besoin de charger toutes les actions auxquelles l'utilisateur à droit ? Pourquoi ne pas charger que l'action voulue et ensuite vérifier si elle est autorisée ?

Je serais d'avis à remplacer la classe Action par une interface vu qu'il n'y a aucune variable et aucune méthode d'implantées. Ça permet ainsi de garder la flexibilité de pouvoir hériter une classe.

Une petite variante à l'implantation de the-gtm pour sauter avec un élan.

Évidemment, c'est préférable d'utiliser une fabrique pour instancier l'action.

Plus j'y pense, plus je trouve que l'idée du switch géant risque de ne rien changer...

PHP va passer la totalitée de la page et procéder à tout les REQUIRE même s'il ne sont pas apellé dans l'exécution. Il n'exécutera pas le code mais va l'inclure.... ce qui règle pas le problème.

^^ j'ai raison ?

Sinon je commence à ne plus être en mesure de vous suivre au vu de mes connaissances actuelles pour être honnête. Existe t'il un endroit ou je pourrais avoir une explication au sujet des termes:
public class ListeAction implements Action
public abstract void action();
public interface Action


J'en suis encore qu'au base du concept de la P.O.O. en fait. (Ce qui me rapelle que je devrais p-e demander l'aide d'un 'expert' si je peux pas avoir à refaire mon moteur de jeu deux mois après sa sortie)

crois en un débutant en POO, commece par faire simple. (d'où mes grosses classes)

concernant la question du 'pourquoi charger toutes les actions', c'est simple :

Je ne propose pas aux joueurs les actions qu'ils ne peuvent pas faire.

si t'as 2 Points d'actions, je ne te propose pas de lancer un projectile magique de 3PA.
Si t'as pas de menottes, tu n'auras pas l'option 'menotter' proposée.

Si je proposais les dizaines d'actions possibles, l'interface serait surchargée.

Naholyr : comment ça uzinagaz ??? ;=))
je fais des centrales nucléaires, pas des usines à gaz !!

Dans ce cas remplacer les require par des include pour éviter d'inclure toutes les classes php.

Pour l'interface, je me suis trompé sur un point, c'est ce qui arrive en faisant copier/coller. Faut virer le abstract, y'est pas nécessaire.

Pour la POO, je te dirais que si t'es en PHP4, tu peux oublier les mots-clef interface et abstract, mais si tu tiens vraiment à faire de la POO en PHP, va vers le 5 si possible.

Interface
Abstraction

Je ne sais pas si ça peut d'intéresser, mais pour ma part je suis entrain de lire un livre sur les design patterns pour la conception OO. C'est "Tête la première Design Patterns". Mais c'est peut-être préférable d'avoir une petite base en java ainsi que la sytaxe OO du langage. Mais bon y'a pas mal d'exercices et le livre est pédagogique. Il existe aussi en anglais "Head First Design Patterns".

Je suis en PHP5
Et l'avantage des require contrairement au include, c'est qu'on pouvais placer des méthodes dans des fichiers séparé et faire des requires dans la classes pour les introduire.

Je suis pas certain que include permette cela puisqu'il exécutera le code pour en inclure que le résultat...

Et bien que tu ne les "propose" pas au joueurs, le code (les classes/ou les méthodes) sont quand meme présente dans le code, PHP doit lire la méga classe pour ne pas utiliser 95% du code non ?

Oui Sybler c'est vrai, mais si on reste dans le cas des classes à charger, au final je crois que c'est mieu de passer par la fonction __autoload qui ne charge que les classes qui parcouru par PHP. Je viens de faire le test avec 2 classes et un switch, il n'y a qu'une classe de chargée.

Donc:

N'exécutera jamais le second require.... ce qui reviend à dire que le fichier classe2.php pourrait être innexistant et il n'y aurrait aucune erreur.

Dans ce cas le switch est une excellente solution


Merci à tous

Note (mais je sais que c'était un oubli) : attention à ne pas oublier le break qui va avec le switch, sinon il exécute toutes les actions

(c'était moi), ouais, je sais, j'ai juste fait ca un peu trop vite.

^^ ca je comprend pas trop honnêtement :-\


Sinon j'arrive à un 'problème':

J'ai pensé faire ceci:

class Session{}
class Account extends Session{}
class Perso extends Account {}

Ca me semblais une bonne idée pour le personnage de la personne qui joue au jeu, mais quand j'ai pensé qu'il faudrait créer la liste des personnages dans un lieu, Account et Session sont des classes totalement innutile dans ce cas...

Vous faite comment pour gérer ces 3 grandes classes vous ?