Quelle est l'utilité de la POO avec PHP?

Version imprimable

10/11/2013, 13h16
ChriGoLioNaDor

Quelle est l'utilité de la POO avec PHP?

Salut,

Je m'intéresse depuis un bon moment à la POO, mais malgré les différents tutoriaux et articles parcourus, je n'arrive pas à cerner précisément comment tirer réellement partie des avantages qu'offrent la POO, au niveau de la programmation PHP.

Pour être plus précis, j'ai déjà utilisé la programmation orientée objet en C++, et je comprends son intérêt : pour simplifier à l'extrême, on crée des objets à partir de classes, on a des attributs qui permettent d'éviter d'avoir à passer 36 fois les mêmes paramètres à chaque fois qu'on appelle une fonction, on peut utiliser les attributs statiques si on veut avoir un attribut commun à toutes les instances, ... Bref, pour une application de bureau, je trouve que ça apporte pas mal de petits trucs sympas.

J'ai par contre beaucoup de mal à transposer la logique de la POO au langage PHP.

En effet, alors que dans une application "standard" la consommation de mémoire est la plupart du temps secondaire (ça ne change pas grand-chose qu’une application consomme 5Mo ou 10Mo de mémoire vive), alors que PHP ne dispose souvent que de quelques Mo maximum pour générer une page Web. De plus, tout changement de page efface les données en mémoire pour repartir à zéro.

J'arrive donc à un dilemme:
- Si j'utilise les variables de session afin de conserver l'ensemble de mes objets, ma consommation mémoire explose, puisque je me retrouve avec la quasi-totalité des données de mon site en mémoire (liste des membres du site, des discussions du forum, des images de la galerie photos, …) de façon quasi permanente. En effet, il suffit qu’un utilisateur se balade sur quelques pages pour que les objets créés s’accumulent en mémoire.
- Autre alternative, ne utiliser les variables de session, mais dans ce cas je perds une bonne partie de l'intérêt de la POO : ça reviens à devoir recréer les instances dont j'ai besoin à chaque chargement de page. Dans ce cas, je me retrouve à créer deux ou trois objets et une ou deux méthodes par objet. Peu d’intérêt donc d’avoir des attributs de classe, puisque de toute façon je n’appelle quasi-jamais plusieurs méthodes de la même classe sur une même page.

Qu'ai-je mal compris?

Merci de partager avec moi vos connaissances :)
10/11/2013, 14h20
bretus

Bonjour,

Je me trompe peut-être, mais en te lisant, je pense que tu passes à côté de nombreux intérêts de la P.O.O et que tu fais du PHP from scratch (sans framework ou structurant ton développement)...

Alors, la P.O.O. permet effectivement (par rapport à du procédural) :
- De regrouper des variables (via les attributs d'une classe)
- De simplifier les initialisations (via les constructeurs)
- De masquer une implémentation (pour ne pas noyer le poisson ou pour pouvoir changer d'implémentation)

Seulement, la P.O.O., c'est pas uniquement ça... La P.O.O. permet aussi de spécifier un service via l'usage d'interface (UserInterface fournissant un identifiant et un mail, et faisant abstraction du fait que ton utilisateurs est authentifié via une table, via facebook ou via LDAP)

Après, la P.O.O. s'accompagne d'une série de technique (design patterns par exemple) qui visent généralement à :
- Permettre à un développeur de modifier le comportement de ton code sans le modifier
- Permettre la réutilisation de ton code dans un plus grand nombre de cas d'utilisation possible
- Fixer un cadre de développement (organisation des classes dans des namespaces, architecture MVC avec une batterie de service dans un conteneur par exemple)

Citation:

J'arrive donc à un dilemme:
- Si j'utilise les variables de session afin de conserver l'ensemble de mes objets, ma consommation mémoire explose, puisque je me retrouve avec la quasi-totalité des données de mon site en mémoire (liste des membres du site, des discussions du forum, des images de la galerie photos, …) de façon quasi permanente. En effet, il suffit qu’un utilisateur se balade sur quelques pages pour que les objets créés s’accumulent en mémoire.
- Autre alternative, ne utiliser les variables de session, mais dans ce cas je perds une bonne partie de l'intérêt de la POO : ça reviens à devoir recréer les instances dont j'ai besoin à chaque chargement de page. Dans ce cas, je me retrouve à créer deux ou trois objets et une ou deux méthodes par objet. Peu d’intérêt donc d’avoir des attributs de classe, puisque de toute façon je n’appelle quasi-jamais plusieurs méthodes de la même classe sur une même page.

Quelques choses me dit que tu tentes d'inventer des architectures avant d'avoir observé les architectures montées par d'autres.

En général, on ne stocke pas autant d'information sur les sessions. Quand on affiche une liste d'article, on accède à la base de données. D'ailleurs, on évite d'avoir toutes les lignes en mémoire, on procède par itération (hasMore / next). Et quand on veut éviter d'accéder à la base de données, quitte à faire du cache, on essaie de mettre en cache le résultat du traitement (i.e. le code HTML, JSON, XML,... produit par le script PHP)

Est-ce que tu connais les design pattern? Est-ce que tu as déjà utilisé des framework MVC?
10/11/2013, 14h54
papajoker

Bonjour

Citation:

Envoyé par ChriGoLioNaDor

la programmation orientée objet en C++, et je comprends son intérêt

Il me semble que tu n'as pas véritablement compris l'intéret de la poo

Citation:

Envoyé par ChriGoLioNaDor

Dans ce cas, je me retrouve à créer deux ou trois objets et une ou deux méthodes par objet. Peu d’intérêt donc d’avoir des attributs de classe,

Dans une appli C++ je vais créer un objet produit, je vais faire des appels "Produit".delete() en fonction de la logique métier... en php, la même appli, j'ai la même logique métier! donc je vais faire exactement le même nombre d'appel "Produit".delete().

La seule chose différente en php, c'est, comme tu l'as noté, le rechargement de l'appli entre chaque page ! donc en php je vais avoir juste en plus (par rapport à l'appli desktop) le chargement répétitif(répétitif=bon pour objet).

Citation:

Envoyé par ChriGoLioNaDor

Qu'ai-je mal compris?

regarde un Framework php pour te faire une idée.
10/11/2013, 17h21
ChriGoLioNaDor

Rebonjour, et merci de vos réponse.

En effet, la POO ne se limite bien entendu pas à ce que j'ai cité, et je n'ai fait que reprendre les fonctionnalités que j'utilise le plus souvent.
En effet, faisant de la programmation pour mon usage personnel, je n'éprouve pas le besoin de fixer un cadre de développement, par exemple.

Je m'en sers principalement parce que je me retrouve plus facilement dans mon code, et parce que ça me facilite la vie de tous les jours.

Concernant les design paterns, ça m'évoque vaguement quelque chose (en particulier le Singleton).
Pour le MVC, je me suis déjà documenté dessus, pense avoir compris la logique générale, et j'essaie de m'y tenir.
Entre autre, j'évite de mélanger la partie "métier" (appels à la BDD, traitement des formulaites etc) avec la partie présentation.

papajoker > En effet, je ne dis pas que je ferai plus d'appels.
Ce que je veux dire c'est qu'en C++, si j'ai une application qui gère une liste de produits, je vais créer une instance de ma classe Produit pour chacun de mes produits, avoir un attribut static QteProduit, et ensuite je pourrai faire ce que je veux de ma liste de produits via les méthodes delete(), ajout(), tri() etc.

En PHP, je ne me vois pas faire ça, dans le sens où je ne vois pas l'utilité de réinitialiser la liste de mes produits à chaque pages, alors qu'il me suffit de supprimer l'objet de ma BDD, et au prochain affichage de ma liste, je vais refaire une requête afin de lister les produits.
C'est donc une logique assez différente, où je n'utilise aucun attribut de classe puisque de toutes façons je ne vais pas m'amuser à recréer ma liste de produits à chaque page, alors que je ne m'en servirai pas vraiment.

Mais justement, je trouve ça dommage de perdre cet aspect là de la POO (même si je suis d'accord que ça n'enlève rien à d'autres fonctionnalités telles que les héritages par exemple). Car au final on perds un peu cette notion d'objet ayant ses attributs, pour utiliser selon la page appellée, telle ou telle fonction qui en soit est quasiement autonome et pourrait faire exactement la même chose sans passer par la POO, en supprimant simplement la classe et en gardant uniquement les fonctions.

Pour ce qui est des Frameworks, en auriez-vous un en particulier à me conseiller?
En effet, il n'est pas facile de s'y retrouver entre les usines à gaz, ceux développés initialement en PHP4 et "adaptés" en PHP5 sans vraiment tirer partir des possibilités du langage objet afin de garder un maximum de compatibilité avec les versions passées, ...
Je me suis déjà penché rapidement sur Kohana qui me semblait assez bien pensé et assez simple à prendre en main.
Cependant ce qui m'intéresse c'est surtout de comprendre le pourquoi du comment, plutôt que d'utiliser quelque chose que d'autres ont pensé à ma place. Pour prendre une image, je ne veux pas réinventer la roue, mais je veux comprendre pourquoi ceux qui l'ont inventée ont fait tel ou tel choix.

De plus, chacun ayant sa façon de programmer, et ne le faisant pas dans un cadre professionnel (je veux dire : je ne fais pas partie d'une équipe de développement par exemple), je préfère me faire mes petites classes adaptées très précisément à mes besoins, plutôt que de prendre quelque chose qui pourra en faire 100 fois plus, mais que je n'utiliserai jamais si ce n'est qu'à 10% de ses capacités.
10/11/2013, 18h29
bretus

Citation:

Envoyé par ChriGoLioNaDor

En effet, la POO ne se limite bien entendu pas à ce que j'ai cité, et je n'ai fait que reprendre les fonctionnalités que j'utilise le plus souvent.
En effet, faisant de la programmation pour mon usage personnel, je n'éprouve pas le besoin de fixer un cadre de développement, par exemple.

Même pour mon usage personnel, je me pose un cadre... Une fois à l'aise dans un cadre, on évite de se poser des questions et on profite de l'expérience de ceux qui ont définit ce cadre.

Citation:

Envoyé par ChriGoLioNaDor

Je m'en sers principalement parce que je me retrouve plus facilement dans mon code, et parce que ça me facilite la vie de tous les jours.

Il y a clairement une courbe d'apprentissage pour être à même de travailler avec un framework. Je parierais que tu trouves que c'est trop compliqué pour ce que tu as à faire? (je pensais ça avant de comprendre l'intérêt de cette complexité)

Citation:

Envoyé par ChriGoLioNaDor

Concernant les design paterns, ça m'évoque vaguement quelque chose (en particulier le Singleton).

Donc, tu ne connais pas les designs patterns. Je ne saurais que te conseiller "Tête la première dans les design patterns" où les auteurs partent justement de problématiques concrètes en programmation.

Citation:

Envoyé par ChriGoLioNaDor

Pour le MVC, je me suis déjà documenté dessus, pense avoir compris la logique générale, et j'essaie de m'y tenir.
Entre autre, j'évite de mélanger la partie "métier" (appels à la BDD, traitement des formulaites etc) avec la partie présentation.

Je trouve MVC intéressant pour :
- Gérer les liens et leurs paramètres
- Gérer les vues

Citation:

Envoyé par ChriGoLioNaDor

En PHP, je ne me vois pas faire ça, dans le sens où je ne vois pas l'utilité de réinitialiser la liste de mes produits à chaque pages, alors qu'il me suffit de supprimer l'objet de ma BDD, et au prochain affichage de ma liste, je vais refaire une requête afin de lister les produits.

Comme je te le dis plus haut, on n'instancie pas tous les objets : On n'a pas besoin de les conserver après avoir produit le code HTML correspondant.

Jettes peut-être un oeil à ce tutorial : Le modèle MVC et le contrôleur sous PHP

(tu verras qu'il ne stocke rien sur la session ;))

Citation:

Envoyé par ChriGoLioNaDor

C'est donc une logique assez différente, où je n'utilise aucun attribut de classe puisque de toutes façons je ne vais pas m'amuser à recréer ma liste de produits à chaque page, alors que je ne m'en servirai pas vraiment.

La vie des objets n'est pas la même en PHP et en C++ et n'a pas lieu d'être la même... Une fois le code HTML, on n'a plus besoin de l'objet. En C++, on conserve généralement l'objet vivant sous une IHM.

Dans un cas, on communique en appelant des URL, dans l'autre on appelle des fonctions.

Citation:

Envoyé par ChriGoLioNaDor

Mais justement, je trouve ça dommage de perdre cet aspect là de la POO (même si je suis d'accord que ça n'enlève rien à d'autres fonctionnalités telles que les héritages par exemple). Car au final on perds un peu cette notion d'objet ayant ses attributs, pour utiliser selon la page appellée, telle ou telle fonction qui en soit est quasiement autonome et pourrait faire exactement la même chose sans passer par la POO, en supprimant simplement la classe et en gardant uniquement les fonctions.

Tu as conservé cette logique en stockant les données sur les SESSION, tu auras déjà du la perdre et t'adapter au mode déconnecté du web :aie:

Citation:

Envoyé par ChriGoLioNaDor

Pour ce qui est des Frameworks, en auriez-vous un en particulier à me conseiller?
En effet, il n'est pas facile de s'y retrouver entre les usines à gaz, ceux développés initialement en PHP4 et "adaptés" en PHP5 sans vraiment tirer partir des possibilités du langage objet afin de garder un maximum de compatibilité avec les versions passées, ...
Je me suis déjà penché rapidement sur Kohana qui me semblait assez bien pensé et assez simple à prendre en main.

Symfony2 ou Zend...

Citation:

Envoyé par ChriGoLioNaDor

Cependant ce qui m'intéresse c'est surtout de comprendre le pourquoi du comment, plutôt que d'utiliser quelque chose que d'autres ont pensé à ma place. Pour prendre une image, je ne veux pas réinventer la roue, mais je veux comprendre pourquoi ceux qui l'ont inventée ont fait tel ou tel choix.

Pour éviter de faire des folies du style "mettre toutes les données dans une session" et pouvoir apprendre en mimant les meilleurs pratiques de développement? :aie:

Citation:

Envoyé par ChriGoLioNaDor

De plus, chacun ayant sa façon de programmer, et ne le faisant pas dans un cadre professionnel (je veux dire : je ne fais pas partie d'une équipe de développement par exemple), je préfère me faire mes petites classes adaptées très précisément à mes besoins, plutôt que de prendre quelque chose qui pourra en faire 100 fois plus, mais que je n'utiliserai jamais si ce n'est qu'à 10% de ses capacités.

On voit que tu fais du C++ où chacun est heureux de pouvoir choisir sa convention de nommage, son organisation des sources, etc. Ça change le jour où le code commence à avoir du vécu, des ajouts de fonctionnalités et où il faut gérer 10 dépendances avec du qmake, du cmake, des make et "rien" ;)

Le temps que tu perds à comprendre une organisation prédéfinie, tu le récupères vite en ne perdant pas ton temps en réinventant ta propre organisation.

Après, même si tu utilises 1% des fonctionnalités du framework : La seule organisation de ton code en MVC te fixera une base pour être à même d'ajouter des fonctionnalités sans que ton code se fige.
10/11/2013, 19h23
ChriGoLioNaDor

Oui j'avais déjà lu cet article, et mes projets implémentent quelque chose d'assez proche du modèle MVC. En fait je me rends compte maintenant que ce que j'ai fait pourrait être amélioré, mais on reste dans la même logique :)

Par contre pour les Design Patterns, je me pose une question : tu me confirmais que la logique entre "language web" et "langage PC" n'est pas la même et qu'il fallait que je la perdre.
Or, l'article que tu me donnes concernant les Design Patterns donne des exemples pour Java... Est-ce vraiment transposable à la programmation PHP? Je deux dire : pour un site web standard, j'ai du mal à saisir l'utilité de ce genre de patterns, puisqu'en général j'ai un nombre très limité d'instances créées.
Je comprends l'utilité des design patterns pour de gros projets, mais pour des sites Internet se limitant à des forums, galeries, pages d'admins et choses de ce type, ça me semble un peu exagéré :)

Pour les frameworks, oui en effet ça me semble assez compliqué, mais pas seulement. C'est surtout que ça ne m'intéresse pas vraiment de savoir que tel framework contient une méthode nommée xss_clean() qui me permets de filtrer mes variables. Ce qui m'intéresse, c'est comment le faire moi-même pour que si demain je préfère changer de framework, ou que je doive travailler sur un projet n'utilisant pas de framework, je puisse concevoir moi-même cette fonction.
Or, utiliser ne veut pas dire comprendre. Et comprendre ce qui a été fait n'est pas évident car souvent il n'y a pas vraiment d'explication détaillée de pourquoi telle chose a été faite comme ça plutôt qu'autrement.
D'où ma volonté de faire pour apprendre :)
10/11/2013, 19h58
papajoker

Citation:

Envoyé par ChriGoLioNaDor

puisqu'en général j'ai un nombre très limité d'instances créées.

Utilise un framework, charger 50 classes pour une page n'a rien de monstrueux.

Citation:

Envoyé par ChriGoLioNaDor

c'est comment le faire moi-même pour que si demain je préfère changer de framework, ou que je doive travailler sur un projet n'utilisant pas de framework, je puisse concevoir moi-même cette fonction.

ca c'est un concept procédural :)

Citation:

Envoyé par ChriGoLioNaDor

Or, utiliser ne veut pas dire comprendre. Et comprendre ce qui a été fait n'est pas évident car souvent il n'y a pas vraiment d'explication détaillée de pourquoi telle chose a été faite comme ça plutôt qu'autrement

ne pas connaitre les design pattern c'est comme concevoir des tables sans notion de mcd
10/11/2013, 20h39
ChriGoLioNaDor

Citation:

Utilise un framework, charger 50 classes pour une page n'a rien de monstrueux.

Quel que soit le langage, charger 50 classes si tu peux faire la même chose proprement avec 3, c'est en charger 47 de trop.

Je sais bien que la mode est au dicton "qui peut le plus que le moins", mais j'ai toujours trouvé que c'était du gaspillage d'avoir un char d'assaut pour tuer une fourmis :)

Après si en effet tu as besoin de ces 50 classes pour arriver à tes fins, c'est une autre histoire. Mais franchement, dans la très grande majorité des cas, ça me semble plus qu'exagéré. :)

Je ne dis pas que les frameworks ne sont pas utiles, je dis qu'ils sont parfois disproportionnés à ce que tu en fais.
C'est un peu comme les personnes qui ne jurent que par les CMS, et expliquent que créer un site sans se baser sur un CMS est totalement inutile. Mais nous sortons du sujet initial.

Citation:

ca c'est un concept procédural

Ca, c'est la réalité quand on travaille sur différents projets existants. Ne crois pas que 100% des sites présents sur le net utilisent un Framework. Si 10% en utilisent, c'est déjà bien.

Citation:

ne pas connaitre les design pattern c'est comme concevoir des tables sans notion de mcd

OK je reconnais que ça peut être utile, au moins pour savoir que ça existe et savoir où chercher le jour où on en a besoin.
Mais comme je disais, ça me semble un peu compliqué pour un site Internet... :)

Cela dit, je vous remercie de vos réponses, qui m'ont confirmées qu'il y avait bien une différence de logique entre la POO "software" et la POO "Web". Ce qui explique que j'avais l'impression de ne pas arriver à réutiliser exactement les mêmes habitudes.
10/11/2013, 21h31
bretus

Citation:

Envoyé par ChriGoLioNaDor

Par contre pour les Design Patterns, je me pose une question : tu me confirmais que la logique entre "language web" et "langage PC" n'est pas la même et qu'il fallait que je la perdre.

C'est même pas une question de design pattern, c'est une question de développement web en mode : Le client envoie une requête, je répond, il se déconnecte (donc ça me sert à rien de garder des objets en vie).

Citation:

Envoyé par ChriGoLioNaDor

Or, l'article que tu me donnes concernant les Design Patterns donne des exemples pour Java... Est-ce vraiment transposable à la programmation PHP? Je deux dire : pour un site web standard, j'ai du mal à saisir l'utilité de ce genre de patterns, puisqu'en général j'ai un nombre très limité d'instances créées.

Hum... Le mieux est que tu te forges ta propre opinion non? Tu verras vite que certains pattern supposent qu'on a des garbage collector et qu'il faut par exemple les adapter en C++.

Citation:

Envoyé par ChriGoLioNaDor

Je comprends l'utilité des design patterns pour de gros projets, mais pour des sites Internet se limitant à des forums, galeries, pages d'admins et choses de ce type, ça me semble un peu exagéré :)

Pour les besoins que tu évoques, j'aurais tendance à apprendre à faire des extensions pour des CMS :aie:...

Citation:

Envoyé par ChriGoLioNaDor

Pour les frameworks, oui en effet ça me semble assez compliqué, mais pas seulement. C'est surtout que ça ne m'intéresse pas vraiment de savoir que tel framework contient une méthode nommée xss_clean() qui me permets de filtrer mes variables. Ce qui m'intéresse, c'est comment le faire moi-même pour que si demain je préfère changer de framework, ou que je doive travailler sur un projet n'utilisant pas de framework, je puisse concevoir moi-même cette fonction.

J'ai appris à programmer en MVC avec Zend. Quand Zend 2 et Symfony 2 sont sorti, je n'ai eu aucun problème pour migrer sur Symfony 2 car le gros du boulot était fait : Apprendre à ramener une application à des contrôleurs, des vues, des layouts, etc.

Après, je me suis déjà amusé à faire un MVC "maison" pour voir comment faire un FrontController et un mécanisme de layout, du reste, je pense sérieusement qu'il faut apprendre à vivre en présence d'abstractions, c'est à dire apprendre à utiliser un outil avant de comprendre tous les détails du fonctionnement interne.

Enfin, à toi de voir... De mon point de vue, on progresse beaucoup plus en lisant les codes des autres et en utilisant leurs outils qu'en partant de zéro.
10/11/2013, 21h38
papajoker

Citation:

Envoyé par ChriGoLioNaDor

charger 50 classes si tu peux faire la même chose proprement avec 3, c'est en charger 47 de trop.

En fait tu as un problème de conception aussi bien en procédural qu'en poo :(
- Pour la poo : une classe = une responsabilité (3 ca va être coton de faire un MVC)
- En procedural, même chose; il est meilleur d'écrire 50 procédures que 3. Au moins elles seront réutilisables

--------------------
Si tu désires te persuader que la poo avec php n'est pas obligatoire, alors tu as raison :) tous les professionnels php n'y sont pas encore passés; mais il reste de moins en moins d'irréductibles gaulois :)
11/11/2013, 07h30
ChriGoLioNaDor

Je ne cherche pas du tout à me convaincre que l'OOP sous PHP n'est pas obligatoire, je l'utilise déjà depuis un moment.

Ma question était plus lié à comment l'utiliser mieux, et mieux comprendre son "adaptation" à la programmation web.

D'autre part je ne parlais pas de 3 classes en tout, mais de trois classes instanciées lors du chargement d'une page. Et "3" n'était bien entendu qu'un exemple pris au hasard. Après on est bien d'accord que selon ce les fonctionnalités de la page, il peut y en avoir plus ou moins :)