PHP Objet : avantages et inconvénients

[Ernestine]

Bonjour,

J'ouvre ce sujet, non pas pour lancer une polémique sur l'utilité de faire de l'objet en PHP, mais pour savoir vraiment quels sont les avantages et les inconvénients (s'il y en a) de faire de l'objet en PHP. Jusqu'à peu, notre chef d'équipe refusait catégoriquement de faire de l'objet en PHP, il disait : "je ne vois pas l'intérêt de faire de l'objet avec un langage procédural, si je veux faire de l'objet je choisirai un langage qui est vraiment fait pour ça, mais certainement pas PHP". Et il ne disait pas cela par ignorance : il était avant tout un spécialiste de Java, donc du pur objet. Dans le même ordre d'idées, il refusait de gérer les relations avec mysql (avec le moteur InnoDB), il disait : "si je veux gérer les relations dans ma base de données, je choisis PostgreSql, qui est vraiment fait pour ça".

Mais maintenant on a un nouveau chef d'équipe, qui lui, est dans la philosophie inverse : il veut faire du PHP Objet, et rien d'autre que de l'objet, de façon très poussée. Pour moi c'est assez nouveau, alors ces derniers temps, je m'autoforme à l'objet. Je trouve ça intéressant mais bon, jusqu'à aujourd'hui, très franchement, je ne vois pas ce que ça apporte de plus. Mais je me dis que si tant de monde fait du PHP Objet, c'est qu'il doit bien y avoir des avantages.

Alors voila ma question, pour tous les spécialistes : quels sont les avantages de faire de l'objet en PHP ?

[BlackPage]

Salut !

Après avoir fait beaucoup de procédural, je passe également peu à peu à l'objet total ( avec beaucoup d'interfaçage JS ).

Je dirai pour les moins : le fait que la structure générale d'un site est alourdie ( beaucoup de modules différents à inclure, charger dans un certain ordre ).

Et pour les plus : code plus robuste, plus propre et surtout bien plus portable... Actuellement, je ne manipule plus que des classes php de base ( en général l'attaque d'une base mysql ) et je délaisse tout le reste à un framework javascript spécialisé dans la manipulation du DOM et donc... en objet complet lui aussi...

Le résultat : moins d'1h pour développer un module de gestion des comptes avec 20 champs à traiter, avec tous les gestionnaires d'évènements inclus, les vérifications à la saisie, l'interfaçage Ajax->PHP. PHP qui ne fait plus d'ailleurs que recevoir le formulaire ajax sous la forme d'un objet, le traiter et le renvoyer au client...

[SStephane]

Hello,

l'utilité de faire de l'objet en PHP, mais pour savoir vraiment quels sont les avantages et les inconvénients (s'il y en a) de faire de l'objet en PHP.

Même si c'est à mon sens incontournable, il doit bien exister des inconvénients : ne serait-ce que celui-ci : tous les développeurs ne font pas de l'objet ou l'utilisent mal (ce qui revient à faire du procédural). Les ressources sur le marché du travail sont plus rares, donc plus chères (point de vue dirigeant); d'autre part le temps que toi et tes collègues soyez formés, vous allez perdre du temps.

Jusqu'à peu, notre chef d'équipe refusait catégoriquement de faire de l'objet en PHP, il disait : "je ne vois pas l'intérêt de faire de l'objet avec un langage procédural, si je veux faire de l'objet je choisirai un langage qui est vraiment fait pour ça, mais certainement pas PHP". Et il ne disait pas cela par ignorance : il était avant tout un spécialiste de Java, donc du pur objet. Dans le même ordre d'idées, il refusait de gérer les relations avec mysql (avec le moteur InnoDB), il disait : "si je veux gérer les relations dans ma base de données, je choisis PostgreSql, qui est vraiment fait pour ça".

Il a quel âge ? certes, php4 n'offrait que peu de fonctionnalités objets, mais php5 et même les versions les plus récentes offrent quasiment toutes les fonctionnalités qu'il faut pour faire à peu près ce qu'on veut (typage, namespace, interface, abstract...).

Ce qui choque les développeurs la première fois avec php, c'est l'absence de typage fort, le côté moche du code et certains trucs pouvant paraître bizarres au premier abord. Quoi

Dans tous les cas (y compris en php4), je comprends mal (à part en invoquant les raisons plus haut) ce qui pouvait motiver ton ex-chef à refuser de développer objet. L'argumentation ne tient pas vraiment la route ("qui est vraiment fait pour ça"), c'est comme si je lançait un projet c#, récusant java à cause de son absence de delegate...

Le principal avantage de l'objet est simple : gagner du temps. (Je ne parle pas de la phase d'apprentissage).

On ne fait pas de l'objet pour faire de l'objet (sinon je rejoins ton ex-chef), on fait de l'objet pour développer plus vite, abstraire son code, et réutiliser certains composants tels quels de projet à projet en faisant des fois évoluer ces composants (que l'on peut dans certains cas appeler framework d'entreprise).

Pour lister les avantages rapidement voilà :

• gain de temps
  
• ré-utilisabilité du code, capitalisation d'un framework pour l'entreprise(*)
  
• harmonisation des développements (à développer au sein de la boite, convention de nommage etc.)
  
• complétion dans les ide de dév quand les sources sont commentées (netbeans par exemple, zend studio)
  
• lisibilité
  
• ...
  

Je pousse néanmoins la logique plus loin concernant l'objet : utiliser un framework et d'un orm pour gagner plus de temps (toi qui parlait de sgbdr), il y en a pas mal sur le marché aujourd'hui.

[Ernestine]

D'accord, merci à vous deux pour ces réponses

Stéphane, pour te répondre : ce chef était plutôt jeune, moins de 30 ans. Au début il était le seul et unique développeur de la boîte (maintenant on est cinq), et les premiers sites qu'il a faits, c'était en php orienté objet car il avait l'habitude de java. Mais assez rapidement, il a renoncé à l'objet et pris la décision de faire du procédural uniquement, pour les raisons évoquées plus haut.

Cela ne l'a pas empêché de monter son propre framework, qui petit à petit s'est enrichi au fur et à mesure des projets et des nouvelles recrues. Bien que non objet, ce framework tenait bien la route, on a quand même créé environ 150 sites web avec, dont certains assez gros et complexes : e-commerce, sites communautaires, etc... C'était du MVC, il y avait des contrôleurs, des librairies de fonctions, des modules réutilisables, des API pour faire de l'ajax, du requêtage sur les BDD, des API pour faire communiquer les sites entre eux, gérer les webservices, etc, bref, un truc tout de même assez complet et performant. Pour l'IDE, on développe sous NetBeans également, et la complétion de fonctions marche bien aussi.

Donc voila pourquoi je posais cette question En tous cas je vais continuer d'apprendre à faire de l'objet, ça ne peut être que bénéfique, et puis c'est intéressant (et de toutes façons j'ai pas le choix !)

[SStephane]

Si vous avez fait tout ça en procédural, c'est sans doute très bien, je dis pas le contraire; cela dit, vous avez sans doute réinventé la roue, ça existe déjà dans tous les frameworks (ie vous avez perdu du temps). Ca n'est qu'une hypothèse, sans voir le code, c'est dur de dire.

Je donne juste un exemple (qui colle à l'objet) : je veux un module qui offre des fonctionnalités génériques (ajout/suppression/modif) + certaines hyper spécifiques, en objet, tu fais un truc du genre (valable quasi partout, qq soit le framework) :

class SpecificController extends GenericController{
   function __construct(){
     parent::__construct();
     //+ traitement spec
   }
   function specific1(){
   }
   function specific2(){
   }
}

En procédural, je vois mal comment le faire proprement. Fondamentalement, je ne vois pas comment utiliser une seule fois la logique pour plusieurs rendu/traitements différents. Note que ce n'est qu'un exemple, je ne parle même pas d'abstraction, d'accès db, de tests unitaires etc.

Faire du MVC en procédural, c'est possible. C'est plus facile avec de l'objet voilà tout, et la totalité de ce que j'ai vu en procédural était un étendard de ce que l'on fuit généralement en MVC.

[Cariboo]

Donc voila pourquoi je posais cette question En tous cas je vais continuer d'apprendre à faire de l'objet, ça ne peut être que bénéfique, et puis c'est intéressant (et de toutes façons j'ai pas le choix !)

De toute façon, tu as tout à fait intérêt à apprendre la programmation objet ! C'est indispensable.

Les arguments de ton chef de projet demeurent néanmoins assez curieux. D'autant plus que (horreur pour les puristes ! ), en PHP, tu peux faire les deux en même temps : utiliser la POO dans certaines parties, et le procédural ailleurs !

L'un des problèmes que l'on a avec la POO, c'est que cela crée des couches abstraites qui masquent parfois le fonctionnement du programme. Bref, cela peut créer un phénomène de "boîtes noires" empilées difficile à déboguer et à comprendre. La POO simplifie les choses pour des tâches complexes, mais parfois cela les embrouille et les alourdit pour des choses simples (comme générer un bout de HTML).

Donc, on peut faire le choix d'utiliser le procédural pour des choses simples, comme le code d'un template de page, et utiliser une classe en objet pour gérer un formulaire ou une couche d'abstraction de base de données.

Bon évidemment, ce n'est pas comme ça que l'on crée un site en MVC pur et élégant... Mais ça fait sérieusement gagner du temps en mode "quick and dirty".

[Nicolas]

Je pense qu'il faut trouver un bon compris entre faire un code propre, facile à maintenir, facile à faire évoluer etc ... et le temps passer à le mettre en place.

Un code orienté objet peut prendre du temps à développer mais une fois mis en place il sera plus efficace, évolutif, ... sur la durée c'est surement le meilleur choix.

Sauf que ;-) parfois (souvent même) il faut aller vite, avec le procédural on peut aller plus vite au départ et à la fois avoir un code propre.

[AdvertEasy]

Il me semble qu'il est beaucoup plus facile de faire évoluer un script programmé en objet, même quand on ne l'a pas fait soi-même.

D'accord avec ChatMaster, c'est plus évolutif et certainement plus efficace au final.

[Ernestine]

Bonjour,

D'accord, je réalise en effet que sur le long terme, il sera plus efficace d'avoir un code objet, ce sera plus simple à faire évoluer, et plus simple pour le travail en équipe, même si en contrepartie le code est un peu plus lourd. C'est effectivement un bon argument en faveur de l'objet.

Dans l'état actuel de mes recherches, il y a principalement deux choses qui me chiffonnent :

1/ Ce qui me pose principalement problème, c'est la durée de vie ultra courte des objets. Imaginons par exemple un catalogue, avec une liste de produits. Au minimum, j'aurai donc une classe Produit et une classe ProduitsCollection. Le client envoie sa requête, sur le serveur j'instancie mes objets, je fais le traitement, tout ça, et j'envoie le rendu html au client. Et après ça : les objets cessent d'exister. Si le client réactualise sa page, ou visualise un autre produit, ou si un autre client demande la même page au même moment dans tous les cas le résulat est le même : sur le serveur je dois tout recommencer à zéro à chaque fois. Alors que dans un logiciel qui serait en java par exemple, les objets, une fois instanciés, existent jusqu'à la fermeture du logiciel. On peut donc réellement les manipuler, les faire interagir entre eux, etc, ce qui est super. Mais là, dans un système client-serveur, c'est un peu comme si on lançait le logiciel des milliers de fois, au moindre affichage de page par un visiteur, voire même à la moindre requête Ajax !

2/ La deuxième chose, c'est que j'ai l'impression qu'il faut faire tout le travail deux fois : une fois sur les objets proprement dit, et une fois en base de données. Si par exemple le visiteur modifie un objet (exemple : un message de forum), dans mon script, je devrai non seulement mettre à jour mon objet Message, mais je devrai également aller effectuer la modification de ce message dans la base de données. N'est-ce pas étonnant, de devoir tout faire deux fois ?

Si quelqu'un pouvait m'éclairer sur ces deux points, je crois que ça m'aiderait beaucoup à avancer, merci d'avance

[SStephane]

D'un part je comprends mal ton découpage, d'autre part je vois pas en quoi ton objet aurait une "vie" plus longue en java ou dans un autre langage qu'en php ou on ne manipule généralement pas vraiment la mémoire. C'est du web, pas de l'applicatif.

Tu dois tout recommencer à chaque fois ? si tu gères pas de système de cache, j'ai envie de te dire oui. Cacher, c'est inclut dans struts, .net, symfony, zend, django (pas sectaire sur le langage).

Alors que dans un logiciel qui serait en java par exemple, les objets, une fois instanciés, existent jusqu'à la fermeture du logiciel.

Il existent jusqu'à ce que le garbage collector passe par là, sinon il faudrait relancer le service du pôle-emploi toutes les 5 minutes

Mais là, dans un système client-serveur, c'est un peu comme si on lançait le logiciel des milliers de fois, au moindre affichage de page par un visiteur, voire même à la moindre requête Ajax !

J'ai pas bien compris, mais des milliers d'objets seront instanciés (et détruits), c'est clair (en php ou en java), et alors ? En procédural comme en objet, l'algorithmie est une notion importante, et c'est surtout de ce point de vue qu'il convient de bien faire ton travail. La quantité d'objets est peu importante et objet ou pas, la complexité (au sens de complexité, d'ailleurs, tu l'évalueras mieux en objet qu'en procédural) restera la même.

N'est-ce pas étonnant, de devoir tout faire deux fois ?

Tu as du taf

On ne fait pas du MVC pour faire le travail 2 fois (c'est le mvc que tu remets en cause), on le fait pour séparer les couches.

Prenons exemple ce topic qui est affiché ici et qui potentiellement peut remonter en page d'accueil/rss/ws etc. Chacun de ces affichages est généré par un contrôleur © et présenté en html par une vue (V). Les contrôleurs accèdent à la base de données par les modèles (M). Pourquoi ?

Simplement parce que dans le cas présent, les contrôleurs RSS/topic/accueil appellent le même modèle (la table topic dans le cas présent) et peut potentiellement utiliser les mêmes requêtes, le découpage est donc une manière au contraire de ne pas refaire les choses 2 fois ie réécrire les requêtes 2 fois.

Autre chose, un topic de ce forum parle de générer un site pour mobile actuellement. Dans ce cas précis, on utilise les mêmes contrôleurs, les mêmes modèles mais des vues différentes (on peut feinter en css, mais ce n'est pas le propos, CSS = Vue, html = vue).

Imagine que tu doives générer du wml à la place du html, tu n'auras que la vue à changer,

Imagine que tu veuilles migrer sous postgre, tu n'auras que les model à modifier (et pas trop s'il est abstrait).

[Ernestine]

Merci pour ces réponses, mais j'ai dû très mal m'exprimer car ce n'est pas vraiment ce que je demandais.

Pour le premier point, ce que je voulais dire, c'est que sur le web (du moins avec php), tout se résume toujours à une seule et unique action de l'utilisateur. Le client envoie sa requête, le serveur effectue son traitement et envoie une réponse, et point final, les choses s'arrêtent là (l'utilisation des sessions permet d'avoir une sorte de continuité d'une action à l'autre, mais ça ne change pas grand chose au concept). Partant de là, je n'arrive pas à comprendre à quoi vont nous servir les objets. Alors que dans une application java ou C++, ces objets existent dans le temps, interagissent entre eux, sont modifiés, etc, jusqu'à fermeture de l'application, ou destruction par le programme ou ramassage par le garbage collector peu importe. Dans le deuxième cas, je vois bien l'intérêt, mais dans le premier, pour l'instant, je ne le vois pas.

Quant au deuxième point, j'ai parfaitement compris le pattern MVC, que j'utilise depuis des années. C'est bien de l'objet que je parlais. Imaginons un objet $message, instance de la classe Message, qui contient un champ $contenu. J'aurai logiquement un setter setContenu($contenu). Mais les données de mon message, au fond, elles sont stockées dans la BDD. Dans un cours sur internet (mais c'était peut-être un mauvais cours), il est écrit que lorsque l'utilisateur modifie son message, je dois instancier un objet $message avec les données de la BDD, puis modifier cet objet (avec des méthodes du genre setContenu()). Ok je veux bien, mais après avoir fait mon $message->setContenu() il me faudra encore faire un update sur la BDD, donc je ne vois pas à quoi a servi l'objet $message au milieu de tout ça. A moins que l'update de la BDD se fasse carrément dans la méthode setContenu() ? Ou alors ce n'est pas du tout comme ça qu'il faut faire ?

Voila, pour l'instant, j'ai vraiment l'impression que faire de l'objet en PHP ça se résume à encapsuler des fonctions, mais je ne demande qu'à me tromper. Je vais continuer d'étudier tout ça, je pense que d'ici deux ou trois semaines j'y verrai un peu plus clair.

[ricardo]

Le mieux est de passer au tout objet et suivre les pattern. Le principale avantage est la souplesse de mise à jour des applications. Avec le partern MVC, dans le cas où l'on veut ajouter de nouvelles fonctionnalités, les développeurs peuvent travailler en direct sur le site sans que ça n'ai dincidence sur le reste du site. L'HTML est d'un coté, le PHP de l'autre, tout est regroupé et facilement utilisable. Une fois que tu est dedans c'est un bonheur d'utilisation !

[Ernestine]

Je relance le topic pour donner des nouvelles de ma découverte de l'objet. je vais de découverte en découverte et je trouve ça vraiment excellent. Oui, je comprends mieux, maintenant, tout l'intérêt qu'il y a à faire de l'objet en php !

Je travaille notamment avec Symfony2 (je ne fais quasiment que ça depuis un mois) et c'est hallucinant la puissance du machin ! Que ce soit dans le routing, dans la création et le traitement de formulaires, dans l'organisation en bundles et en services, le moteur de templates, et surtout l'utilisation de Doctrine2 pour la BDD, c'est fou le temps qu'on gagne !

Cela dit, je ne regrette pas d'avoir fait du php et du SQL "à l'ancienne" (autrement dit : "à la main") pendant des années, au moins j'ai acquis la base, ce qui n'aurait peut-être pas été le cas si j'avais commencé directement par l'utilisation d'un gros framework.