Que faire ?

[rygnes]

Pour reprendre Argorate et poursuivre sur la ligne d'Allwise, tu te trompes royalement Argorate.
La POO apporte énormément en termes de programmation, si tu la trouves très difficile à mettre en place c'est parce que tu t'y prends mal. En l'utilisant tu gagnes en rapidité, en lisibilité, en facilité de maintenance au final. Le débuggage n'est pas plus compliqué qu'en procédurale (mon expérience personnelle prouve justement le contraire). Le seul inconvénient est effectivement le coût machine qui est plus important, mais quel temps a le plus de valeur, celui de la machine ou celui des développeurs ?

Comparer un tableau et une classe... Je suis sceptique là.

[tog84]

Etant aussi un vrai débutant en POO et pas du tout un expert, Je vais te faire part de mon expérience personnelle.

je me suis posé la question pendant plus d'une semaine quand j'ai voulu me lancer à coder mon projet.
Faut-il rester en procédural ou s'emmerder à commencer en POO.
Après de longues hésitations, j'ai décidé de passer à la POO.

Déjà, rester en procédural, c'est aller au fil du temps vers des problèmes de compatibilité car si je ne me trompe pas, la POO sera de plus en plus omniprésente à terme dans les prochaines versions du PHP.
J'avais codé une webtv en procédural, mais mes pages comportaient au minimum plus de 100 lignes (500 à 600 lignes pour les grosses pages). Tout était réuni au même endroit, donc à plusieurs reprises, j'ai fait des boulettes en effaçant du code propre et fonctionnel car j'étais perdu dans toutes ces lignes. L'erreur classique, je ne fais pas attention ou est mon curseur et hop, j'ajoute des caractères au mauvais endroit, d'où, des nouvelles erreurs de code la ou il n'y en avait pas auparavant.
Avec beaucoup d'appréhension, j'ai lu et relu des tutos sur la POO et rien me paraissait clair, aujourd'hui encore, je ne suis pas encore au top mais ça commence à rentrer.

Alors, j'ai commencé par coder une classe de connexion à ma BDD puis tout de suite après une classe joueur.

Pour t'aider un peu ma classe joueur comprend comme méthodes entre autres :

Code PHP :

<?php 

- Connexion($nomlogin,$motdepasse1,$id_session)

- Verif_Form_Inscription($nomlogin,$motdepasse1,$motdepasse2,$email,$jour,$mois,$annees)

- Validation_Inscription($nomlogin,$code)

- Verif_Form_Recup_Mail($email)

- Verif_Form_Regen_Mdp($nomlogin,$code,$motdepasse1,$motdepasse2) 

[Argorate]

rygnes : Je ne suis pas convaincu par tes propos, pas plus que tu ne l'es par les miens^^

Pour te rassurer bien que je n'ai rien à prouver, je t'assure que je sais m'y prendre avec la POO comme en procédural, et que je tire mes conclusions d'expérience.

Je dois réaliser 5 programmes différents pour mon BTS, il y en a certain en procédural d'autre en objet. Les plus long et les plus difficile dans leur avancement sont ceux en POO, non pas parce que la tache à accomplir est plus dur ou que je ne sais pas comment la réaliser, mais parce que on perd un temps fou quand tout est basé sur de l'objet: de la création de classe, accesseurs jusqu’aux appels des méthodes...

De plus dès que tu bouges quelques choses en BDD, tu dois retoucher à chaque fois ta classe :
Rajouter un attribut et les gets et les sets correspondant, c’est lourd, redondant et concrètement ça n’apporte rien de plus qu’un simple tableau !
Mise a part qu'un tableau est créé en 2 min et qu'une classe peut prendre beaucoup de temps… Surtout que certains on la fâcheuse tendance à créer des classes pour rien, remarque je rigole bien quand ils viennent demander pourquoi leur 20ene de lignes marche pas, alors qu’en 2 ou 3 en procédural se serait réglé…

Le débugge est carrément soulant (je parle toujours de PHP en POO), en cas d’erreur tu as une ligne (comme en procédural) sauf que 9 fois sur 10, la ligne (ou les lignes alentour) ne sont pas du tout la source du problème, et tu n’as aucune indication d’où se situe réélement l’erreur !
Parfois même c’est un include de class qui elle même include d’autre class, au final tu as des pages entière ou pourrait se cacher l’erreur…
Bref grosse perte de temps là aussi, donc désolé mais je ne suis pas d’accord sur le gain de temps.

Ensuite sur la lisibilité, moi je lis aussi bien l’une que l’autres, mais je trouve plus clair d’écrire :
Info_véhicule[1][‘couleur’]
Plutôt que
collectionvehicule->getVéhicule(1)->getCouleur()
(notamment dans les conditions des if ou de boucles, qui ne rentre plus sur ton écran tellement elle sont longues)
Donc soutenir que c’est lisible, surtout que l’objet renvois toujours aux classes, donc a d’autre page que celle ou tu te situes => on ne peut pas avoir toutes les pages en même temps sous les yeux, donc non ce n’est pas plus lisible.

Quand au temps de maintenance je ne vois pas en quoi il serait plus long en procédural, si tu fais bien les choses, que tu organise bien ton code, tu t’y retrouveras sans doute plus vite avec des tableaux que des trucs a rallonge.
Au lieu de perdre du temps à décrire une classe personnage, moi j’ai un tableau et dès que j’en ai besoin je fais : perso[‘pv’] et voilà.
Alors tu me diras que cela revient au même que d’écrire perso->getPv(), oui…
La différence c’est que je n’ai pas perdu plusieurs minutes à décrire une classe pour faire au final la même chose…

La POO aide à clarifier, et ordonner les données en mémoire, mais si on est suffisamment clair et rigoureux, le procédural marche tout aussi bien et est tout aussi rapide si ce n’est plus que la POO.

Je ne parle pas de l’argument qui dit que la POO est moins accessible à la compréhension que le procédural pour certains…


Pour en revenir à Lain : je ne te conseil pas ni de m’écouter ni d’écouter un autre, fait toi ton opinion, créez deux petits jeux(ou programme) d’égal importance et qui demande a peut prés le même temps de réalisation, et créez l’un en objet et l’autre en procédural, tu choisiras ensuite ce que tu préférés, je pense que c’est a l’appréciation de tous.

[pascal]

Argorate, je ne suis pas convaincu par ce que tu dis; pour plein de raisons.

J'arrive à expliquer avec un exemple réel que le passage à la POO est intéressant : http://wiki.jeuweb.org/tutoprog/passage_a_la_poo

A part, j'ai juste un secret à vous dévoiler :
un objet, c'est juste un tableau avec :
- des attributs à la place des index associatifs
- des fonctions dédiées à la manipulation de ce tableau/objet, que l'on appelle des méthodes

Un autre avantage de la POO, c'est d'utiliser des scripts de génération de DAO (objets d'accés aux données) automatiquement, et on ne doit plus se taper à la main la définition des getters/setters : c'est fait en une ligne de commande.

Me reste plus qu'à faire des tutos sur la POO, vu que ça manque.

A+

Pascal

[Allwise]

Pas du tout convaincu non plus, sauf ton respect, je pense que tu manques sérieusement de recul et d'expérience pour pouvoir apprécier le confort qu'apporte la POO dans un projet. Et là, je parle aussi avec mon expérience

Je retrouve dans ta description de la POO toutes les interrogations et les trucs chiants que je reprochais à cette approche quand je m'y suis mis.
J'ai encore pas mal de choses à apprendre en POO, mais j'en connais suffisamment pour savoir qu'on ne peut pas s'en passer pour les projets qui sont voués à évoluer et pour plein d'autres raisons. En vrac : modularité, réutilisabilité, lisibilité, maintenance. Un tas de trucs bien galère avec du pur procédural a tendance monolithique, quand le projet prend de l'ampleur.
Exemple tout con : j'ai développé une application serveur pour mon jeu. Plutôt que de mélanger le code qui s'occupe de l'ouverture des sockets, la lecture / écriture de données... et tout le tsoin-tsoin avec les données "métier", qui concernent directement le jeu, j'ai fait une classe assez abstraite pour pouvoir être réutilisée à d'autres sauces ( et une classe fille, avec les spécificités du jeu ). Ce qui n'aurait pas été possible si j'avais fait du procédural, car le code qui gère les connexions et celui qui gère le jeu auraient été tout mélangés...

[Argorate]

Pascal: je suis au courant de la possibilité de l'automatisasion des accesseurs, ce qui est un plus, mais encore trop insufisant a mon gout.

Allwise: je ne pense pas que l'empleur d'un jeu soit dépendant de la manière dont il est coder, je veux dire que la POO ou pas, c'est pas se qui détermine le résultat.
J'espere pouvoir te le prouver si je fini le mien qui n'est que procédural et qui selon moi n'est pas dans la catégorie "petit projet".

Après chacun ses expériances et son avis.

PS: l'argument de la "réutilisabilité" du code ne marche pas. c'est tout autant réutilisable en procédural, c'est d'aillieur se que je fais: je reprend des partie identique quand j'en ai besoin d'un projet a un autre et ça marche très bien...

[Zamentur]

je ne pense pas que l'empleur d'un jeu soit dépendant de la manière dont il est coder

L'ampleur non, mais le tuto de pascal montre que pour arriver à des choses bien procedural il faut utiliser des tableau et des fonction ce qui revient à de la poo, sans son esthétique...

Tu le dis d'ailleurs tu utilises des tableaux et je suppose que tu utilise des fonctions!
Tu fonctionne donc d'une manière très proche!

Les concept poo ne sont pas complexe ce qui est complexe c'est de savoir comment organiser un ensemble quand on en a jamais vu un et c'est valable en poo comme en procedural.

Moi je maintient Lain peut partir dans du procedural avec de l'oo pour certaines choses.

Cependant j'accorde le point concernant le problème du debuggage et des mauvaise ligne indiqué! Ca force à toujours verifier les cas limite, c'est bien mais c'est soulant. Mais avec un bon système de debug çà passe

[wild-D]

la première fois que j'ai eu un cours c'était du C++... et pourtant on a fait que du procédural toute l'année même si on nous disait d'utiliser cout plutot que stdout (ou qu'à l'occasion ou nous fournissait un objet "boite-noire" plutot qu'une ou 2 fonction pour aider à faire ce qu'on devait faire); la conception/l'approche était totalement procédurale.

A l'inverse, me semble que GTK en terme de conception est(était?) pensé en (pseudo-)OO, même si c'est programmé en pur C.


quand on revient au code machine; finalement y a plus tellement de différence entre du code OO ou procédurale. Utiliser un langage conçu pour la POO avec des lib/framework qui le font; c'est pour permettre des facilités/gains de temps en terme de développement. De même qu'en procédurale on utilise aussi des lib pour s'éviter de réinventer la roue à chaque fois.
Si c'est pas le cas; que ça prend plus de temps pour développer en OO/maintenir, faire évoluer votre code; c'est que le choix de l'OO est p-e pas optimal (ou que y a un défaut dans la conception).

d'expérience, la pooite aigue et la collection d'objet inutile c'est une plaie (mais je me soigne, sisi )

p.s.
pour le débugage et les erreur de ligne en générale avec les piles on retrouve généralement assez vite la source initiale.

p.s.2
+1 zamentur; tu peux tout à fait partir avec une sorte de mélange des 2 du procédurale saupoudré de petits objets. Ce qui paraît une approche assez logique en plus dans le cas de dév de page web dynamique.

[Globe]

Excusez moi d'être un peu brusque, mais si nous essayons de condenser ce débat plus ou moins stérile dans un autre sujet plutôt que de poluer celui-ci ? Un programmeur moins expérimenté demande un coup de main pour son jeu, ce serait bien d'élaborer sur les bases logiques de la création d'un jeu plutôt que comparer des opinions controversées qui semble hors de propos pour un développeur qui cherche simplement des directions pour commencer son boulot, le choix de la POO reste le sien, concentrons nous plutôt sur l'aide que nous pouvons lui apporter dans ce topic et créons en un limite en post-it dans la partie débats

[Lain]

et bien deja merci a vous tous ! j'ai compris que c'etais a chacun de choisir sa preference entre POO et procedural, je pense que je vais d'abord m'assurer d'avoir un cahier de route pour mon jeu afin de savoir ce que je veux faire , comment le faire , ca va m'aider a placer toutes les choses utiles et a me donner un bon suivi !

merci beaucoup !