Après m'être replongé dans le PHP orienté POO, certaines "questions" se posent a moi.. Notamment l'interet de l'utiliser etant donné qu'actuellement c'est encore un moteur jeune et donc assez "nu", et qui est susceptible d'evoluer dans un sens ou dans un autre => problemes de compatibilité (notamment la difference entre PHP4 et PHP5 de comment sont passées les variables dans les classes)
Ce qui m'a surtout porté a me demander si actuellement ca presente un interet,est le fait que presque tout ce qui est faisable avec la POO peut etre remplacé d'une maniere a peu pres equivalente (c'est mon avi) par d'autres elements, sans pour autant perdre (a mon avis) en clareté.
 
Notamment :
 
Les variables passées par références peuvent etre remplacées par les variables globales (comme il est meme dit dans les pages POO de php.net)
 
Les appels d'une methode d'un constructeur :
 

 
Par
 

 
Les exceptions, remplacable a mon avi par le classic @fonction or function2()
 
La seule chose que j'utilise et pour laquelle l'equivalence non POO est plus dure a faire, c'est l'heritage. C'est bien entendu un argument de taille, mais combien de sites utilisent la POO sans avoir besoin des notions d'heritage?
 
Meme le fait qu'on puisse plus facilement separer le code par fonctions (une classe pour mysql, une classe pour le parseur xsl,..) me semble facilement faisable en includes "non POO".
 
Deplus je trouve que la doc officielle PHP est assez découragente de ce coté la .. Elle me semble assez "lite", presque incomplète. Et tres peu claire sur ce qui est PHP4 et ce qui est PHP5.
 
Donc, qu'en pensez vous? Il faut continuer a utiliser la POO en PHP en esperant que dans les prochaines versions elle soit plus complètes ou existe-t-il vraiment quelquechose a coté duquel je sois passé?

l'orientation POO du langage n'est jamais essentielle, c'est plus un état d'esprit et un ensemble de méthodes qu'une fonction du langage en elle même (même si certains concepts POO sont très difficiles à transposer dans un langage non POO).
 
Par exemple, il est possible de faire de la POO (ou un truc qui y ressemble) en C, et l'une des raisons pour lesquelles certains "fanatiques" du C refusent en bloc le C++ est le fait qu'il ne leur apporte rien, aucune flexibilité et aucun concept qu'ils pensent ne pouvoir appliquer en C.

La POO en C c'est un bordel pas croyable à gérer...

 
Tout a fait d'accord, mais tehoriquement le POO devrait etre faite pour simplifier et surtout clarifier le code, et non l'inverse non?
 
Hors il me semble qu'en PHP en tout cas (le seul autre langage OO que je connaisse est Java, et étant donné qu'il est pas mal basé la dessus les outils orientés objets sont quand meme plus perfectionnés) ce compliques pas mal pour enfait ne pas apporter grand chose (sauf dans l'heritage, qui me semble plus chaud a gerer de maniere clean en procedural).
 
J'en suis donc presque a me dire qu'a l'etat actuelle ou se trouve PHP, la POO est presque a deconseiller, etant donner qu'on ne sait pas comment ca va evoluer (=> risques de problemes de compatibilité) que ca rallonge le code (un $obj->mafonction() sera toujours plus long a ecrire qu'un mafonction() ) et que ca apporte pas enormement du point de vue de la clareté du code (perso, toutes les methodes contenues dans mes classes commencent par le nom de la classe (genre mysql_secure() mysql_conn , mysql_exec,...) donc je pense que niveau clareté, si on regroupe dans le meme ficher toutes les fonctions protant sur la meme chose ... on s'y retrouve tout aussi bien

J'ai pas dit que c'était facile (j'ai jamais essayé, je suis pas un nain tégriste), j'ai dit que c'était possible et l'une des raisons du refus de migration de pas mal de gens qui restent sur le C (ça fait également partie des raisons invoquées par les devs du kernel nux)

ça, c'est vrai quand on génère un langage OO sans avoir à prendre en compte de rétrocompatibilité, dans le cas du PHP on a "greffé" une interface OO par dessus un langage non OO, donc on se retrouve avec un batard/hybride qui n'est pas nécessairement simplifié.
 
De plus, tu nous montre ici un exemple de 3 lignes, ça fait un peu court pour une démonstration, il faudrait faire des comparaisons sur de gros devs

Java a été pensé en tant que langage à peu près OO (comme Python ou Ruby)
 
 
T'façon j'aime pas le PHP

(perso je trouve l'OO bien pratique niveau écriture et organisation du code...mais flemme de développer, c'est dimanche...:o)

SSI+CGI/Python  
 
hahaha
 
Il est temps d'inventer le Python Hypertext Preprocessor
(ou Python Server Pages au choix, au moins comme ça PSP désignera quelque chose de potable )
(enfin bon on a déjà mod_python)
 
edit: en fait, PSP existe déjà depuis mod_python 3.1

Oui mais est-ce que ca a les meme capacitées qu'un site en php, ou est-ce que juste pour afficher "hello world" et faire une requete il faut 500 pages de code?

Ça me rappelle quelqu'un qui critiquait l'argument souvent utilisé pour justifier la programmation orientée objet: "La POO correspond à la manière naturelle de penser pour un être humain". Il rétorquait: "Vous plaisantez? Il faut des livres de 500 pages pour expliquer aux gens un modèle proche de leur manière naturelle de penser?"
 

Tout ce qui peut être fait en POO peut être fait en procédural, c'est très clair, mais tout ce qui peut être fait en C++ pouvait aussi être fait en assembleur
 
En réalité il y a deux débats ici: premièrement, est-ce que la POO vaut vraiment tout ce qu'on en dit? est-ce réellement une grande avancée par rapport au procédural? et deuxièmement, PHP est-il bien équipé pour la POO?
 
Pour le premier point, la POO rajoute pas mal de complexité et de jargon (héritage, polymorphisme, etc), mais apporterait selon les fanas de POO des avantages tels que un code facilement réutilisable, une meilleure abstraction, etc. Il faut que j'avoue que je ne m'y connais pas assez en POO pour pouvoir dire si ces arguments tiennent vraiment la route.
 
Néanmoins je vois personnellement dans la POO l'avantage suivant: la possibilité de grouper des variables avec des fonctions au sein d'un même objet permet une réutilisation "plug and play" entre deux programmes/scripts. Il suffit d'instancier la classe pour pouvoir l'utiliser, alors qu'un module procédural qui nécessite des variables utilisera des variables globales, ce qui peut provoquer des conflits de noms (c.à.d deux modules qui utilisent la même variable globale)
 
Je vois comme inconvénients la tendance à lier les objets entre eux (obligé de comprendre une classe pour comprendre une autre) et la tendance à utiliser des fonctions (méthodes) pour n'importe quelle action: p.ex. je crée un objet "site" avec une méthode "addPost" alors que l'ajout d'un post ne se fait qu'en un seul endroit, et ne nécessiterait donc pas de méthode, de plus c'est spécifique à cette application et donc ne pourra pas être réutilisé.
 
Maintenant pour la question est-ce que cela vaut la peine de faire de la POO en PHP, je pense personnellement qu'un développement complet en POO est et restera une mauvaise idée: un script PHP a un temps de vie très court, cela me parait beaucoup trop lourd d'inclure puis d'instancier tous les objets, d'utiliser une ou deux de leurs méthodes, puis qu'ils soient détruits, en sachant que cela recommencera à chaque appel de page. Néanmoins utiliser quelques objets (pour le côté réutilisation dont j'ai parlé plus haut) n'est pas forcément une mauvaise idée.
 

Je ne connais pas bien Python, mais j'ai lu que c'était un langage relativement simple et de haut niveau, donc pour afficher Hello World, ça doit ressembler à un print "Hello World", pas beaucoup plus compliqué. Par contre j'ignore ce que ça vaut au niveau performance.
 
À part Python, dans les langages dont tout le web parle, il faut mentionner RubyOnRails (basé sur Ruby, un langage japonais qui a beaucoup de succès là-bas), qui est je crois également orienté web, mais j'ai personnellement toujours tendance à réféchir en tant que développeur amateur, et de ce point de vue là PHP est disponible chez n'importe quel hébergeur, alors que les autres langages me demanderaient peut-être une installation spéciale, et mon propre serveur.

Je me suis posé la même question quant à la POO en général et sur PHP en particulier.
 
C'est vrai que l'encapsulation de variables et fonctions est commode. Néanmoins, l'utilisation de namespaces (c++, ou Perl ) permet de d'éviter les conflits de nommage, et donc de faciliter la réutilisation, sans faire nécessairement de l'objet.

Perso j'ai toujours trouvé que les affaires de portée limité d'une variable (justement en OO) ont tendance a créer plus de problemes qu'a en resoudre ... D'ailleurs j'essaie toujours de faire en sorte que mes variables aient une portée maximale (sinon globale). Apres si j'ai besoin d'une variable specifique a telle ou telle fonction, je fais un $mafonction_mavariable = $mavariable; et apres je modifie cette derniere. Ca m'a toujours apporté des solutions et relativement peut d'embrouilles ...
 
En quelques sortes j'ai l'impression que le fait de limiter la portée d'une variable a plus ou moins la meme fonction que le fait de mettre le register_global a off :  
 
Ca empeche qu'on modifie par megarde qqch qu'on ne voulais pas modifier, et cela parcequ'on a un script pourri

Personellement je suis pour la POO.
 
Je vais prendre quelques exemples concrets.
J'utilise pour mes connexions a la base, un "layer". Ce dernier est un objet. Bien que ce dernier dispose deja de beacoup de "drivers" qui lui permetent de se connecter a beacoup de base, il me permet egalement, si j'en ai le besoin, de l'heriter.
L'enorme avantage, en comparaison a un script procedural, c'est que lors de l'heritage, je ne reecris que le code qui m'interesse.
Si je veux par exemple y integrer un gestion avancee des types de donees, alors il me suffit d'etendre l'objet qui represente le layer et d'y surcharger les methodes qui m'interessent.
 
Autre exemple, dans une application que j'ai cree pour un cyber cafe, j'ai cree un objet nome Tarif. Ensuite chaque tarif va etendre cet objet pour implementer le tarif voulu.
L'avantage avec les objets, c'est qu'il n'y a pas de problemes a avoir plusieurs instances de ses tarifs.
Si j'avais voulu faire la meme chose en procedural, j'aurais eu un probleme des le moment ou j'aurais inclus deux fichiers ou sont definies les memes fonctions (normal, chaque tarif doit implementer les "memes fonctions", afin que la gestion des tarifs soit independante de ces derniers).
Avec un objet, je peux sans probleme manipuler "differentes version" des fonctions qui vont calculer le prix.
 
En revanche je tiens quand meme a dire qu'il ne faut pas tomber dans l'exces. J'utilise des objets quand ces derniers ont un sens, et qu'ils me simplifient la vie (exemples pour les tarifs). Mais bon, je ne cree pas un objet "global" pour le site.  
 
Par exemple dans le cms que je fais avec un pote, le "coeur" de ce dernier est surtout consitue de index.php et d'un serie de fichiers qui representent "l'api" de tout le systeme. Pas d'objet ici. En revanche, pour la gestion du menu, ainsi que la creation des formulaires, on a cree des objets.
Pour le menu c'est peut-etre discutable, etant donne qu'il n'y en a qu'un instance. Mais je trouve ca plus clair.
Quand je dois ajouter une entree au menu, je fais comme ca :

Ensuite dans index.php je n'ai plus qu'a "recuperer" le menu :

 
L'avantage la dedans c'est que chaque script php ou "module" a la possibilite d'interagir avec le menu. L'avantage aussi, est que je ne declare pas de variables globales qui pourraient entrer en conflit avec d'autres variables des differents modules/scripts php.
 
On utilise egalement un objet pour la creation de nos formulaires. Cela nous permet une creation simplifie des formulaires, ainsi qu'un certain controle sur le code produit :

Comme deja evoque, cela nous permet de centraliser la creation des formulaires, avec un control acru sur le code produit.  
 
Ici aussi, sans les objets nous aurions peut-etre eu des problemes avec les variables globales. Alors qu'avec la POO nous pouvons creer plusieurs formulaires a la fois si necessaire.
 
 
Alors voila, pour conclure j'aimerais repeter ce que j'ai dit avant. La POO c'est bien, l'exces c'est mal. Le procedural est la POO peuvent cohabiter enssemble a mon avis.

 
Je suis pas trop d'accord pour ce truc. Ce sera $obj->ma_fonction() en POO, ok, mais sans POO ce sera plutôt affiche($var1, $var2, $var3...) et autant de $var qu'il y a de variables membres dans ton objet

 
@FlorentG : Et si toutes les variables avaient la portée globale? Il y aurai pas besoin de les passer en parametre    
 
A nouveau, je ne suis pas du tout contre la POO (meme si c'est l'idée qu'on peut en avoir en lisant ce que j'ai écris), j'essaie juste de comprendre si les problemes qui sont en general resolu avec l'OO ne le seraient pas plus facilement en passant toutes les variables a globale et en gerant proprement les differents flux dans le script de la sorte a ne pas les faire melanger

Tout passer en global c'est quand même super crade...et c'est amha le meilleur moyen d'écraser des données sans faire gaffe dans une fonction et de mettre 4000ans à trouver d'où vient le bug irrationnel qui en résulte...

+ 1 ouais. Avec mes objets et mes variables Private, je suis sûr que personne n'y touche et ne fasse n'importe quoi

je suis assez d'accord avec vous sur le coté "utilité" , d'ailleurs les 2 sites que je developpe actuellement utilisent des trucs OO. Mais je continue a me demander si, en faisant les choses vraiment proprement (On declare tout a la Java, on separe les variables de chaque fonction,...) on ne pourrait pas s'en sortir avec un script qui marche tout aussi bien, qui est logiquement plus rapide a l'execution ... Parcontre c'est vrai que niveau rapidité de developpement ca risque d'en prendre un mauvais coup :s

Mauvais exemple, si je puis me permettre: en procédural on ne créérait pas différents fichiers avec les fonctions répétées, mais plutôt un seul set de fonction, à qui on passe en argument quel type de tarif utiliser.  
 
C'est une différence essentielle: en POO on réécrit pour chaque type d'objet, mais grace à l'héritage on n'a pas besoin de tout réécrire. En procédural, on utilise des structures comme switch pour différencier les différents types. Je manque d'expérience pour dire quelle méthode est meilleure, je suppose que ça dépend des cas.
 

Il ne s'agit pas de "tout" passer en global, si nos variables globales sont bien gérées, c'est pas "crade" du tout.
 
A mon avis, la POO tout comme le procédural ont des problèmes, évitables si l'application est bien conçue. Je pense qu'en PHP il faut écrire soit entièrement en procédural, soit un mélange, mais en tout cas pas entièrement en POO, et à voir les messages plus haut, la plupart des gens sont d'accord avec moi

Non  
 
C'est du Python, pas de l'ASM  
 
http://www.99-bottles-of-beer.net/ [...] l-version)

Effectivement ... C assez speed.
Mais bon certains problemes restent ... Comme le dit doclegi .. il faut trouver un serveur qui propose de gerer le python .. et en mutualiser j'en ai pas vu des masses ...  
 
Parcontre superbe site, hop dans mes fav

Moi j'aime bien la POO avec php 4!!  
Déjà jcomprend po que les créateurs/développeurs de langages objet aient po porté plainte pour publicité mensongère!!  
 
Même si ça reste loin d'un C++ (surtout) j'ai vu que dans le 5 ils ont quand même implémenté les bases de la POO: ya la gestion du constructeur/destructeur, les droits d'accès aux variables, les classes abstraites, les variables et méthodes statiques,.. ya même de la gestion d'exceptions..  
Après comparer PHP et JAVA c'est un peu excessif, ui en effet Java a été un peu + pensé OO Cependant je n'ai rien testé de tout ça encore avec php C'est aussi une question d'opportunité et d'utilité réelle...
 
L'objet est une représentation rationalisée de la réalité, et donc implicitement de notre façon de la percevoir.. (d'où débat). C'est de la méthode, l'idée c'est + d'abstraction donc + de souplesse, + de "logique" et surtout + de généricité pour :
- correspondre au max de situations possibles à décrire
- être + autonome
- évoluer dans le temps le + simplement et "logiquement" qui soit.
 
Dire que l'objet c'est + long à écrire (je caricature) est totalement vrai, sur un exemple de 3 lignes. Mais allez demander à Carmak de recoder les couches objets de Quake III (dsl chui has been^^) en procédural pour voir Dans un gros projet logiciel ya des arbres de classes plus impressionnants que l'arbre généalogique de la famille d'Angleterre Le faire en procédural est irréaliste, c'est illisible et impossible à suivre pour ceux qui développent.
Pour s'en rendre bien compte il faut voir ça sur du papier et non face à l'écran: pour représenter un enchaînement d'étapes complexes à coder en procédural vous aurez un énorme diagramme dégueu qui part dans tous les sens, et en objet vous aurez plusieurs schémas simples et ultra-lisibles qui permettent de donner du relief à la conception en spécifiant différentes couches d'abstraction..
 
Biensûr théoriquement dans la majorité des cas un code objet est aussi faisable en procédural, mais ça n'est po forcément intéressant ni en terme de développement ni même et surtout en terme d'analyse/de conception et donc de compréhension générale du truc que l'on veut obtenir. C'est même plus une histoire de programmation, c'est juste être capable maîtriser ce que l'on fait jusqu'au bout, et même au-delà.. Bref, c'est de la méthodologie!
 
Après en php c'est sympa de se faire ses petits objets IHM, pour gérer des forumlaires par exemple, c'est rapide, pratique, modulable, générique, bref c beau, mais c'est po nécessaire du tout, quand on est po maniaque Et c'est encore + sympa (et utile) quand on désire exploiter beaucoup de données issues d'une base en même temps, comme se faire un mini-moteur de statistiques, on instancie les objets avec des données extraites de la base, et zouh! on peut créer sa moulinette objet. Pour ça la couche objet de php paraît suffisante pour créer des modèles à la mesure des possibilités logicielles offertes par ce langage...
 
 
Et pis de toute manière c'est has been aussi l'objet, maintenant la nouvelle mode c'est le processus!  

Le kernel Linux est intégralement codé en C (donc langage non OO) et c'est considéré comme l'un des codes les plus stables, puissants et efficaces qui existent, malgré une taille impressionnante

combien d'années de dev ??  
 
 
de toute façon je ne suis po à convaincre de ce côté là...

Débat classique OO / pas OO... Avec de l'eau au moulin des deux côtés.
 
On peut bien sûr faire sans, et tous les mécanismes mis en place en OO n'empêcheront jamais un pecnaud de foutre le souk dans le code, car OO != fool proof.
 
Mais on parle bien de PHP ici, et à ce sujet, AMHA, dans son cas, l'OO s'apparente plus à un gadget qu'à un fondement.
 
Ca pue le bricolage, la rajoute. Un peu parce qu'il fallait bien se remettre au goût du jour et contenter tout le monde.  
 
Mais ça reste très inachevé et très incertain.
 
esox> Tu me fais un peu peur, avec ta suggestion de tout mettre en global. Ca induit du couplage et non seulement ça hypothèque une hypothétique réutilisation (ha ha, la belle théorie), mais surtout, ça complique la maintenance, les tests et le debugging !
 
En créant des objets proprement encapsulés, tu peux tester ces derniers à fond individuelement. Si chaque object respecte son contrat, tu limites vachement les pépins, et tu peux sans craintes modifier son implémentation (internals) sans impact extérieur. Je ne t'apprends rien.

Quake 3 a été développé en C. C'est que pour Doom3 qu'ils sont passés au C++

@sircam Perso je continue a scripter en OO (surment mes restes de Java qui resortent ), mais c'est juste que je me suis demandé si on ne pourrait pas faire pareil avec un systeme d'includes imbriqués au lieu de classes imbriquées .. Ce "debat" n'est pas du tout la pour affirmer "L'OO c'est bien" ou "L'OO c'est nul" mais juste parceque j'ai deja vu plusieurs posts sur la POO en php sur ce forum, la pluspart son vieu (PHP3/4) et maintenant on en est a la 5. Et je voulais voir ce que vous en  pensiez, si vous etes pour que PHP continue a s'orienter lentement mais surment OO ou si les developpeurs de php devraient s'axer a avoir une partie procedurale plus "complete" encore. Et aussi faire un topic un peu different de ceux du genre "Mon DW a fait un truc en JS, j'comprend pas pkoi ca marche pa quand je le couple a un truc trouvé sur le site XXXXX.html, vous pouvez me le modifier ?"

Un petit tuto OO pour PHP5 , il est pas tres long mais plante bien le decour je trouve, si vous en avez d'autres postez les aussi  
 
http://www.liquidpulse.net/article [...] troduction

J'ai pas lu j'ai juste regardé le code. Il sait pas coder en objet le gars
 
C'est quoi ces attributs dans la classe User : dbHost, dbUser, dbName, dbPass, dbUserTable ?
 
Ils n'ont rien à y faire. OK il manque plein d'objets dont il aurait besoin pour son tutorial. Mais soit il donne des objets propres, quitte à avoir plus de code, soit il explique juste le design des classes en question.

Oui ca c'est vrai que ca m'a aussi un peu surpris de trouver des trucs de ce genre (Ce qui m'a le plus surpris c'est le UserID ou je sais plus comment il l'apppelle ... qui est l'id de la requete qui vient d'etre envoyée), mais je parlais plutot de comment il explique les constructeurs & co (a noter que je crois pas qu'il ait expliqué que les constructeurs doivent etre soit __construct soit le meme nom que la fonction)

tout à fait!  
 
Certainement pour une question d'ampleur du projet également...