Dans la création de vos jeux ou de vos sites, utilisez-vous la programmation orientée objet (POO) ?
Et pourquoi l’utilisez-vous ou ne l’utilisez pas ?! Quels bénéfices ou quelles contraintes en tirez-vous ?
Hein ?! Dites nous tout !
Dans la création de vos jeux ou de vos sites, utilisez-vous la programmation orientée objet (POO) ?
Et pourquoi l’utilisez-vous ou ne l’utilisez pas ?! Quels bénéfices ou quelles contraintes en tirez-vous ?
Hein ?! Dites nous tout !
Oh laaa…. Oui, oui, et re-oui.
Pourquoi ? Certainement pas parce qu’il serait admis qu’il faut faire ainsi sans savoir pourquoi (un peu comme les fan des validateurs XHTML qui mettent du javascript partout pour rendre des sites non conformes sans que les analyseurs s’en rendent compte 🙂 ).
Non, clairement, l’approche objet est celle qui permet l’architecture la plus robuste et la conception la plus rapide. Les tests unitaires sont facilités et automatisables.
Et surtout, dans le cadre de l’évolution du jeu (nouvelles fonctionnalités, modification/amélioration du system de jeu), l’approche objet réduit les impacts. Je change la définition de ma classe « Personnage » en ajoutant une caractéristique et c’est fini. Partout dans mon code (si j’ai bien travaillé) cette nouvelle caractéristique est prise en compte.
Bref, tout ce qu’on vous apprends dans les livres à propos de la POO et de ses avantages est AUSSI vrai dans le cadre de nos jeux.
Je commence pour ma part à m’intéresser à la POC (http://fr.wikipedia.org/wiki/Progra…) et à la POA (http://fr.wikipedia.org/wiki/Progra…)
Je cherche les avantages et désavantages de chaque afin d’adapter mes habitudes de développements en fonction de ce qui me semble bon à prendre chez chaque paradigme.
Avant cela, je ne développe exclusivement en objet, c’est à peine si je serais encore capable de faire du procédural.
Pourquoi l’OOP ? Nous connaissons tous les avantages. La séparation des couches, la séparation par objet, moins de récurrence dans le code, forte maintenabilité,…
P.
Je l’utilise mais je pense que c’est plus un formalisme qu’autre chose. Clairement ça permet de bien organiser des modules et s’y retrouver plus facilement.
C’est assez naturel de faire correspondre un objet avec une entité/table.
Par contre, je suis moins enthousiaste que toi, Kalan. Si je reprends ton exemple, en programmation procédurale, je vois pas ce qui empêche de faire un module ou librairie « Personnage ». De la même façon, modifier ce module répercutera la modification partout dans le code. C’est pas quelque chose de particulier au code objet.
Le bénéfice est clairement la lisibilité. Le gain potentiel se fera le jour où quelqu’un d’autre voudra contribuer ou relire mon code.
Peut être que l’approche objet force à une plus grande rigueur ? oubien les codeurs objets sont plus « matures », ont plus de bouteille que les développeurs / débutants en procédural ?
Bref, c’est objet pour moi aussi, utilisé intensivement dans le framework symfony.
tiens, ça me rappelle un de mes tutos pour passer à l’objet :
http://wiki.jeuweb.net/tutoprog/pas…
Au risque de donner l’impression de nager à contre-courant, pour ma part c’est procédural.
Les raisons seraient un peu longues à développer pour un simple commentaire, mais je vais tenter un résumé.
Disons qu’après de longues années de pratiques, professionnelle et personnelle, de la POO comme du procédural pour les développements de sites web et intranets, je suis arrivé à voir un panel assez divers de manière de coder et surtout eu le temps de voir ce que ça donne sur du long terme (du vrai, pas celui qu’on s’imagine quand on écrit un site tout neuf), sur du travail partagé entre plusieurs personnes et sur le fait de devoir reprendre le travail de quelqu’un d’autre, parfois lorsqu’il n’est plus là.
Et d’après ces expériences, une évidence sort clairement du lot : il faut arrêter de vouloir assimiler les sites à des applications classiques. Sur un site, l’utilisateur va se « déplacer » page par page. On ne peut pas « charger » l’ensemble de l’application et attendre ses requetes.
La POO c’est super pour des applications classiques, mais pour des sites web, c’est pas super génial.
Le schéma est alors assez simple : chaque Action d’un utilisateur est associée à une requete POST et un script qui fait juste cette action là puis redirige l’utilisateur sur une consultation, chaque Consultation d’un utilisateur est associée à une requete GET, qui lui affiche ce qu’il a demandé et ne fait pas d’action.
L’idée est : si quelque chose plante, y’a pas à se poser 50 questions ni examiner 12 logs, l’erreur est dans LE script qui est appelé, pas la peine de passer des heures à chercher parmis les 14 classes qui sont utilisées.
Une nouvelle action à créer ? de nouvelles données à afficher ? une des fonctionnalité à revoir ? On n’a qu’un ou deux scripts à modifier à chaque fois, on ne peut pas faire plus simple, d’autant qu’il ne sera jamais très compliqué à comprendre puisqu’il ne fait qu’un seul traitement.
Très souvent en plus, on peut retrouver le classique : Liste (consultation) + Edition (consultation) + Enregistrement (action) + Suppression (action) + éventuellement un Visualisation (consultation) dans le cas où certains utilisateurs pourraient consulter sans modifier.
Reprendre un site fait par quelqu’un d’autre sur ce modèle devient un jeu d’enfant, car à chaque url correspond à un fichier physique, qui correspond à une seule action.
Par contre, à partir du moment où on commence à mettre des bidules lourds dans le site (ex : flash), là bien sûr, ça change les données du problème puisque le bidule en question va être entièrement chargé avant utilisation. Mais peut on encore vraiment parler de « site » à ce moment là ?
Findel > je nage dans le même sens que toi ^^ rassure-toi.
J’ai fais 3 ans d’école d’ingénieur pour apprendre les avantages et les inconvénients de la programmation Procédurale et POO.
Ensuite, j’ai fais 3 ans de dev en POO sur des applis client-serveur en C++,
J’ai débuté un gros chantier y’a 4-5 ans sur le Web. A l’époque php n’intégrait pas (ou disons mal) la POO. J’ai donc naturellement fait du procédurale.
Cependant, comme tu le dis, mon procédurale est composées de fonctions regroupées dans des fichiers qui, à la structure rigide près, ressemble à de la POO.
Ainsi je gagne tous les avantages de la POO (au test unitaire et à la protection des données près), tout en ayant la lattitude de rajouter n’importe quel texte et n’importe quel FORMs n’importe où.
Pour résumer mon opinion, la POO a de gros avantage sur des architectures clients lourds, mais je ne ressens pas tant d’importance que ça sur un site Web en PHP. Ni la modularité, ni la reprise de code qui sont des avantages de la POO, ne sont des avantages sur un site.
Kéké
Mais le site du jeu n’est PAS le jeu.
Sur la V4 de G&P, le site est en PHP, le moteur en .NET.
C’est bien le moteur que je veux absolument en objet.
Pour le site, mon collègue à fait le choix d’un framework (Copix) qui est objet; mais c’est plutôt le modèle MVC qui m’intéresse.
Il est clair que faire de l’objet pour faire de l’objet ca n’e pas de sens.
M’enfin, j’avoue que je persiste à trouver que, si bien conçu et documenté, une approche ojet reste plus aisément maintenable