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

Bon, j'ai changé toute ma structure.

Mais j'arrive avec une incertitude:
J'essaie d'implanter ma classe 'lieu'

La classe lieu sera utilisée principalement pour 2 choses (selon mon analyse):
1) Pour convertir l'ID du lieu du personnage en nom affichable.
2) Retourner une liste des sous-lieux pour les déplacement et l'envoi de message aux lieux environnant (si une personne lance un cri par exemple)

Là comme tentative j'ai:

class Member_Lieu{}
class Member_LieuLien extends Member_Lieu {}

Pourquoi je pense à mettre un lien en classe fille ? Parceque le lien mène...à un lieu (qui a un nom, une description, etc... et toutes ces propriété sont déclarée déjà dans la classe Lieu.)

Sauf que je ne vais probablement jamais instancier un Lien !

À vrai dire, je suis un peu perdu tout simplement...
... J'ai beau regarder dans mon sujet nouveau livre "PHP 5 Objects, patterns, and practice", je ne débloque toujours pas

Vous, vous faite comment pour gérer vos lieux/liens ?

Me voila a ce niveau aussi, je me suis lancé dans la POO en php5. donc je vais eassyé d'apporter ma contribution.surtout que je remarque quelque chose.

J'ais lut tout le post, et il y a un truc que je remarque. Tout le monde se jette dans le code tete la première, mais une analyse du pb doit etre faite avant.

analyse merise ou UMl pour les plus fort. Bref, sans cela cè dur de faire quelque chose de potable, à moins de prendre et reprendre ses classes sans cesse.

C'est vrai que c'est la partie la plus chiante, mais qui au final permet d'y voir un peu plus clair sur la structure générale et surtout l'organisation des classes et des héritages.

Se jetter dans le code à tête baiser c'est plus moi que les autres.

Mais j'ai pris le temps de me faire un beau graphique (un genre de truc UML-like) sur papier, mais ca ne m'expliquait pas que:

Je devais créer une classe Lieu avec un tableau d'objet 'lien'
Créer une classe fille LieuLien QUI N'APELLE PAS LE CONSTRUCTEUR PARENT (sinon ca créer un boucle infinie de lieux/liens)

^^ tout ca, c'est qu'une banale flèche sur mon diagramme. Et c'est cette "flèche" que je n'arrivait pas à conceptualiser.. en code !


Ps.: Si tu souhaite une entraide via MSN, comme on est au même niveau (selon tes dires) ca me ferait plaisir de me casser la tête à deux sur nos problèmes communs

Le OOP, ça prends des annés a comprendre, enfin c'est ce que dit les gurus ^^

Pour le déplacement, il faut pas "placed le code pour se déplacer" ici ou là, c'est
pas comme ça qu'il faut penser, ce qu'il faut c'est une classe position
avec une fonction de déplacement, l'OOP est beaucoup une facon de penser en fait.

// je code plus du OOP en c++ desolé pour les eventuels syntax-errors

class Position
{
int $x,$y;
int $id;
public:
Position(); //<- nouveau position (nouveau objet par ex.) créer "position"(ID) dans DB
Position($id); //<-position existant
int GetID(void){return($id);};
void move($dx,$dy); //bouge $x et $y puis update MySQL
};

puis heriter ça dans tout nouveau objet qui devra pouvoir se déplacer.



Pratique ?
Oui, facile a integrer des déplacements dans des nouveau choses, et facile de restraindre les déplacements.

Rapide ?
pas forcement, le PHP est pas compilé, donc tout OOP=lent, sauf que le
Turckmmcache etc compile quand même donc peut-être que c'est rapide quand même.
Pour l'optimisation de MySQL etc, ça peux aussi poser probleme je m'imagine, avoir
un tableau uniquement pour les positions, et un 'ID' dans chaque objet/perso/...
qui y pointe, ça risque de ralentir aussi.

Mais bon, c'est OOP ^^


HTH

/Ludvig

Personnelement je ne vois toujours pas l'interet de l'objet en php.

Entre faie une classe et une methode get ou une fonction objet_prp() qui me renvoit un champ de ma table objet, je vois peu de différence.....sauf que'un objet c plus long a codé.


Voila si qq'un a un jour une vrai explication sur l'interet de la chose

Tout ce qui est fait en objet peut être réalisé également en procédural, tu ne trouveras pas de supériorité à ce niveau là.

La force de l'orienté objet c'est l'encapsulation des données, la simplification du code final (le code objet est naturellement plus facile à lire, pour produire du code procédural très lisible il faut fournir de gros efforts de conception), et surtout l'héritage.

Mouais tjs pas convaincu ^^

Un temps j'ai été tenter de faire mon moteur de combat en objet. Finalement avec des tableaux sa marche aussi bien....

Tu comprendras quand tu reprendras ton code dans quelques mois je pense.

+1

j'ajoute l'interêt de la composition, qui est plus simple à maintenir que l'héritage.

A+

Pascal

oui bref, le OOP c'est un facon de programmer qui facilite grandement les gros projets.
C'est une syntaxe, un facon a faire, pas un remede miracle

Ca s'utilise surtout en c++ parce que le c++ est compilé donc même si on fais
des dixaines de classes encapsulés et avec des heritages, le code sera (globalement hein) le
même que si on programme en "procedureale" ou en spaghetti.

Perso je pense que l'idé que le OOP est puissant viens de là, puis on pense que
ça rendra d'autre langages plus puissant automatiquement (comme le java ou
on est plus ou moins obligé de coder d'un facon pseudo-objet, enfin c'est horrible)
donc utilisez tout ça si vous trouvez que ça vous va bien dans votre style de
programmation, faut pas se forcer ; les classes, l'encapsulation, le polymorph etc,
sont là que pour aider alors au bon projet, le bon philosophie!


Moi je n'utilise pas du tout le système des classes en php, je trouve que
j'arrive mieux a structurer mon projet en fichiers .php et fonctions de
tout genre, a chaqu'un d'avancer comme il le sent.

En c++ je melange les deux, je programme même du procedurale en pensant oop
puis en java(j2me) je fais du anti-oop pour certains raisons, enfin c'est comme
la politique, il n'y a pas une reponse exacte ^^


/Ludvig

Troll ?

Hors plaisanterie, je trouve au contraire que les choix fait par Sun pour l'implémentation du modèle objet sont plus pragmatiques et, au final, rendent Java plus simple et plus clair d'utilisation que le C++.

Comme quoi, les goûts et les couleurs des geeks...


Sinon le principal problème en POO est de se lancer sans avoir vraiment intégré les principes de conception et, oserais-je aller jusque là, d'architecture.

D'un autre coté, il est difficile d'apprendre sans mettre les mains dans le cambouis.

L'idéal c'est d'avoir une équipe constituée de personnes expérimentées et de débutants.


Bref, terminons cet enfonçage de portes ouvertes pour en venir au problème de Sybler concernant une histoire de lieux :

Sybler, la conception de ton modèle va dépendre de ce que tu appelles les liens ("flêches") entre les lieux : un lien a-t-il des attributs (distance, type de terrain, ...) ou sert-il seulement à symboliser la liaison des lieux entre eux ?

Je vais seulement parler du cas où les liens n'ont pas d'attribut.

Dans ce cas, une solution possible est de n'avoir qu'une seule classe (appelons-là Lieu).

L'un des attributs de la classe est alors une liste d'objets Lieu qui représentent les lieux reliés.

Plus précisément, puisqu'un Lieu peut donc se trouver dans la liste des lieux reliés de plusieurs objets Lieu, il faut que la liste contienne les références* des objets Lieu et non leur valeur.

Bon, sans pouvoir faire un schéma et vu l'heure, je pense que ce que je viens d'écrire est quasiment imbitable... cependant, c'était surtout pour faire remarquer que la conception n'est pas intuitive : tout élément ne donne pas forcément lieu à un objet.

C'est donc normal que tu galères un peu au début, courage !

* toujours le cas en Java, utilisation d'un pointeur en C/C++, utilisation d'une référence en PHP.

Certain doute de l'utilisation de la POO. je vais tenter de donner quelque avantages.
EN c++ java et langage orienté objet, langage que je pconnais très bien, c'est très utile.
Le php jusque la procédurale se met a l'objet pk?

- parcque lorsque l'on créé une classe, par ex une classe connexion. Cette classe peut etre reprise dans différetns projets. Il est meme possible de créé des bibliothèque de classe que l'on réutilise dans différent projet, donc au final, on gagne enormement de temps.

- la clareté du code est indéniable.

- parcque cè a ca que tente tous les modeles d'analyse comme UML par ex.

j'ais pas d'autre argument pour le moment ^^.
Il est vrai que pour un petit jeu php dsur navigateur, la poo ne soit pas la solution la meilleur. Maintenant si d'autre vise de plus gros projet, ce qui est mon cas, la POO est quasi obligatoire pour s'y retrouver.

PS: Sybler se serait avec plaisir!!

Maieuh ^^

Enfin, c++ est aussi bien connue pour ça superiorité en puissance que par ca complexité.
Choisir le moins compliqué pour son projet est souvent bien sauf
evidamment si on vie trop bas mais java/c++ et php savent tous faire le boulot.

Le java c'est sympa pour debuter (et pour apprendre tout ce qu'il faut pas faire en OOP )
tout comme le php et même pourquoi pas le c++, par contre c'est des languages
de programmation, pas une système d'OOP.

Les classes c'est super, on peux même les contourner pour faire des bibliotheques
le heritage par dessus et l'incontournable polymorphisme (on peux traiter differents
classes pareils parce qu'ils ont herité du même super-class, par exemple la classe
position) et on peux faire des très jolies choses.
On peux aussi evidamment s'emmeler les pinceaux.

Je veux pas nourrir un troll ni commencer un flamewar (chaqu'un ses gouts après tout)
mais de s'interesser au OOP, je ne vois pas comment ça peux nuire.
Par contre, il est pas sur que ça va rendre les choses plus facile, enfin pas les
premiers annés en tout cas.


/Ludvig

Avantage de la POO ?

Bah avec PHPDoc j'ai une documentation de mon moteur de jeu similaire à celle du site de php.net ...

Toutes mes fonctions sont ressencés automatiquement, quelques commentaires + exemples d'utilisation directement dans le code et voilà une sujet documentation delemortquitue.


Sinon plus sérieusement:

POO - Pour:
- Moins de code
- Moins de répétition de code
- Tout est structuré et la programmation est donc plus intuitive
- Chargement automatique des classes au besoin
- Récursivité à même la structure des données
- Uniformisation de la programmation (généralement 2 programmeurs en POO programme de facon plus similaire que 2 programmeurs procédural)
- Une fois la base de la modélisation terminé, le développement est environ 4 fois plus rapide.
- Possibilité d'avoir des documentateur automatisé (Doxygen / PHPDoc) qui parse le projet et extrait les propriétés/informations diverses.

POO - Contre:
- La modélisation de base est très chiante à faire
- Le fait que PHP décharge ses données entre chaque page est chiant. (Il faut donc sauvegarder certains objets en session)



EDIT:
Et si ceux qui sont pas convaincuent veulent prendre la peine de rechercher mes précédents post sur le forum, vous verez que je n'ai jamais été un fan de la POO avant de sérieusement m'y mettre, d'acheter un livre de POO appliqué à PHP et de suivre 3 cours (C++, Java, C#) orienté POO.... tout ca dans les derniers 2 mois.... étrangement je viend de changer de camp... malgré que je sois pas encore un expert, je commence à me débrouiller assez pour bien comprendre l'intérêt d'un tel concept.



EDIT2:
Sans prétention, si jamais quelqu'un se motive pour créer un tutorial de POO PHP appliqué/axé aux jeu en ligne, je serais intéressé à contribuer. Je vais bientôt offrir une mini formation pour expliquer le fonctionnement de la nouvelle base de moteur aux autres programmeurs de CyberCity donc je vais probablement sortir et expliquer quelques exemples qui pourraient être intéressant pour un tutorial ou un truc du genre. (vous remarquerez bien que je parle de contribuer, pas de diriger... car je ne pense pas avoir aquise une expérience suffisante pour écrire un tutorial sérieux)

Je profite de ton intervention pour m'excuser publiquement de ne pas t'avoir aidé alors que je m'y étais engagé !
Je m'auto-flagelle de ne pas t'avoir prévenu (à la rigueur, que je me désengage je pense que tu l'aurais compris, mais ne pas prendre la peine de te prévenir c'est impardonnable), et m'en excuse encore. J'ai bien sûr une excuse : pas le temps, mais ça n'empêche pas un petit mot (voilà, c'est fait pour le petit mot d'ailleurs ).



Ceci étant dit, je plussoie totalement ton analyse, et j'ajouterais qu'en étant familier avec la POO on s'ouvre de grandes portes :
- Tests unitaires : Créer un squelette de l'application fonctionnel dès le départ, et remplir les trous. La programmation dirigée par les tests est l'assurance de n'avoir aucun bug dans tous les cas d'utilisation prévus.
- Utilisation de frameworks : Créer une application en utilisant des outils fiables, stables, et maintenus par d'autres (parce qu'on a déjà à peine le temps de maintenir son site, si en plus on doit maintenir les briques fondatrices). Et surtout créer les applications futures en un temps record grâce à l'appropriation d'un tel outil. J'ajoute une facilité de travail en groupe grâce à un cadre de travail (en anglais : framework ) commun dans lequel on supprime d'entrée le syndrome du "je fais ma bouille dans mon coin et je vous emmerde".
- Utilisation d'outils ORM (type ezPdo que j'adore) : On a la possibilité de ne plus jamais écrire une requête SQL de sa vie tout en pouvant assurer la persistance des informations, la simplicité de recherche et de création de nouveaux objets. Bref, on a une vision de la programmation "haut niveau" (*) toute autre.

Voilà quelques-unes des portes qu'on ouvre en se mettant à la POO, et sans cette connaissance de base, ces portes restent fermées. Dommage non ?




(*) aucun élitisme dans ce terme, le "haut niveau" désigne simplement le niveau d'abstraction lors de la réalisation de l'application. La programmation en langage machine (binaire) est le plus bas niveau, au dessus on a l'ASM, puis le C, et au-dessus les langages contemporains. Avec l'objet on passe encore un niveau d'abstraction, surtout grâce à la modélisation qui va avec.

Voici une discussion trés interessante, et je pense que nous sommes beaucoup à étudier l'apport (éventuel) de la POO à nos (futurs) jeux en lignes.

L'idée a été lancée de réaliser un petit tuto de POO PHP appliqué/axé aux jeux en ligne, et je pense que c'est une bonne idée pour ceux qui se demande à quoi ressemble un projet en POO.

Je vous propose de regarder ensemble quelle serait la modélisation POO d'un jeu "exemple".

Pour commencer, définissons le jeu : je propose un classique click & slash sur carte avec dépense de PA. Avec gestion d'inventaire et plusieures classes de perso pour utiliser l'héritage et même le polymorphisme.

Si l'idée vous va, on pourra étudier la modélisation de ce jeu là en POO.
Qu'en pensez-vous ?

Ouais, ca pourrait me parraître une bonne idée... A condition de bien archiver et d'écrire nos raisonnement qui nous pencher pour tel ou tel choix lors de la conception.

Il faudrait aussi élaborer une base commune à la plupart de nos projets et s'entendre pour garder les trucs SIMPLE le plus possible (question que la POO ressorte au maximum, et non pas des algorythmes de combat)