Discussion :

[ChriGoLioNaDor]

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

[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)

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?

[papajoker]

Bonjour

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

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).

Qu'ai-je mal compris?

regarde un Framework php pour te faire une idée.

[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.

[bretus]

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.

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é)

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.

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

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 )

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.

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

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...

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?

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.

[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

[papajoker]

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.

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

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

[bretus]

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).

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++.

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 ...

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.