PHP - procédural vs Objet

Bonjour,

Je développe en PHP depuis plus de 10ans en procédural et c'est vrai que pour maintenir une application ca devient très difficile surtout quand on a des pages de 1000 lignes, mais pourtant je trouve qu'il y a une vrai logique dans le procédural.

J'ai déjà tenté de passer à la POO dans le passé mais c'est une toute autre manière de penser la conception du code, qui ne me convient pas du tout. Aussi, je bacle souvent vers la fin de mes projets tellement j'ai l'impression d'avoir créé une usine à gaz en faisant du procédural.

Par exemple pour une page simple qui affiche les données d'une table, je crée d'abord le template HTML, puis à l'intérieur du code je crée mes requêtes SQL et affiche les données dans une boucle. C'est très simple mais au final quand on fait ça plusieurs fois dans la même page ca devient un vrai bordel pour s'y retrouver
En POO cela à l'air plus facile à entretenir puisqu'on peut créer une class dans un fichier à part qui va afficher les données de la page et il suffit dès lors d'appeler cette class dans mon code HTML, mais pourtant je n'arrive pas à me mettre à cette méthode...

Même dans mes maigres tentation de faire un site en objet j'ai l'impression d'avoir fait du procédural. J'ai aussi testé le framework codeIgniter, mais wow j'y comprend rien avec les controlleurs, vues et modèles, pourtant j'imagine qu'une fois qu'on le maitrise le temps à développer un site se fait beaucoup plus vite et au niveau de la maintenance aussi.

J'aurais voulu savoir s'il y avait des gens comme moi et comment ont-elles passées le cap. N'y a-t-il pas des bons tutoriaux complet qui aide à passer le cap ?

l'UML avant tout... et un bon bouquin pour comprendre et apprendre. Pour les design pattern, il y a ce bouquin qui est vraiment bien (O'reilly ). Ce livre traite du Java. Mais comme c'est de la poo, le passage se fait avec peu d"effort.

Pour un aperçu des design pattern php, j'ai parcouru ce livre et il vraiment pas mal.

Un design pattern mal utilisé peut vite devenir un enfer. Donc toujours bien réfléchir sur ce que l'on fait. Ce n'est pas parce qu'on parle beaucoup de design pattern qu'il faille l'utiliser à tout bout de champ. les design pattern ne sont que des concepts avancés de la poo.
Modifié par niuxe (19 Jan 2014 - 18:43)

Merci pour ta réponse. Quel serait d'après toi le meilleur bouquin ou sujet à apprendre pour avoir une bonne méthodologie pour une vraie application web, comme un webshop par exemple.
Je n'ai pas envie de lire un livre qui m'explique comment créer une class, comment hériter, les constructeurs etc.. ou qui me parle de voiture dont les propriétés sont la couleur jaune/rouge..

J'aimerais vraiment trouver un livre avec une théorie et des exemples concrets de comment organiser mon code pour un projet et qui m'explique la méthodologie a utilisé pour traiter un formulaire autrement que d'une manière procédural.
En procédural il y a une vraie logique de comment traiter les données: Tout se fait à la suite mais comment superposer cela en objet, en prenant compte des paramètres, la gestion des erreurs, etc.. C'est là que je cale le plus..

Aussi, de ce que j'ai pu voir, le MVC est quelque chose qui me parait idéal à mes besoins (séparation du code), même si pour le mettre en pratique j'ai beaucoup de peine. C'est une méthode propre aux framework (sauf erreur) et qu'il faut de plus apprendre le "langage" propore au framework.
Modifié par txR (19 Jan 2014 - 20:29)

L'utilisation des objets peut très bien se faire au fur et à mesure, par exemple en remplaçant des fonctions complexes, type gestion d'images, de calendrier, ou de base de donnée.
Un des grand avantage est de pouvoir assigner à l'objet autant de propriétés que tu souhaites, fini donc les fonctions avec 5 arguments...
Prenons le cas d'une fonction de gestion de calendrier, tu peux donc passer dans le même objet, le mois, le jour, l'année, la couleur, le contenu, la taille etc.. ce qui est quand même très fastidieux en procédural.
Ce que je te conseillerai, c'est tout simplement d'essayer, avec un exemple concret, de transformer une fonction ou un groupe de fonctions dédier aux mêmes taches. Tu verras c'est très pratique de pouvoir manipuler un seul objet aux propriétés bien identifiés plutôt qu'un groupe de fonction à plusieurs arguments dont on oubli vite à quoi ils correspondent.
Un exemple concret peut être la création d'un "model", c'est à dire un objet qui est crée a partir d'une base de donnée. Si celui si est souvent utilisé dans un programme de différentes manières l'objet permet de spécifier les attributs, les filtres, les modifications post requêtes, etc..
Modifié par matmat (21 Jan 2014 - 19:28)

txR a écrit :

Aussi, de ce que j'ai pu voir, le MVC est quelque chose qui me parait idéal à mes besoins (séparation du code), même si pour le mettre en pratique j'ai beaucoup de peine. C'est une méthode propre aux framework (sauf erreur) et qu'il faut de plus apprendre le "langage" propore au framework.

Le MVC est en effet un bon design pattern qui correspond assez bien au besoin de développement d'un site web. Par contre, même si ce n'est pas votre but, le MVC peut aussi être entrepris en procédural. En procédural, on n'est pas obligé de faire des pages de 4000 ligne mêlant pêle-mêle html, logique et acces/modification des données. Le MVC peut très bien aussi s'appliquer par soi-même sans framework. Par contre, si on prend le temps de faire un bon modèle solide, ça vaut la peine de le généraliser et d'en faire finalement, son propre petit framework.
Personnellement, j'utilise mon propre framework pour des petits projets réalisés individuellement, que j'améliore selon les besoins du projet en cours. Ce framework est en MVC et en procédural.
Pour les projets de plus grande envergure et en collaboratif, comme je gère plutôt le front et que ce sont les devs qui s'y collent, on part plutôt sur du Symfony ou du Drupal selon les besoins.

Pour le reste, je n'ai malheureusement pas de livre à proposer.

kustolovic a écrit :

Pour les projets de plus grande envergure et en collaboratif, comme je gère plutôt le front et que ce sont les devs qui s'y collent, on part plutôt sur du Symfony ou du Drupal selon les besoins.

Pour le reste, je n'ai malheureusement pas de livre à proposer.

Bonjour,

En sachant que Drupal est développé sous Symfony.

Je pense que le meilleur moyen d'adopter une logique de code purement "objet" et "mvc", est d'apprendre un framework professionnel : Symfony ou Zend Framework.

C'est aussi le seul chemin pour être reconnu comme expert PHP dans le monde professionnel, si vous ne connaissez aucun framework de ce type, vous n'êtes pas considéré comme un "vrai" développeur PHP.

Aujourd'hui nous avons des outils très performants, nous n'avons pas le temps de réinventer la roue, aussi il serait "anticonformiste", de vouloir à tout prix esquiver MVC ou l'objet; en tant qu'intégrateur, cela peut passer mais en tant que développeur spécialisé ça casse. Vous le verrez très rapidement si vous décidez d'occuper un poste dans une boîte de développement.

txR a écrit :
Je développe en PHP depuis plus de 10ans en procédural

Vous n'êtes pas sans savoir qu'internet est un monde en constante évolution, et qu'il est impossible de garder les habitudes de développement d'il y a 10 ans alors que PHP n'en était qu'à sa version 3 et que le mot objet n'existait même pas encore dans ce langage.

Pour un projet personnel, vous pouvez tout à fait continuer à développer de manière procédurale, mais dans le monde professionnel qui est à la page et à l'affût de la moindre façon d'accélérer le temps de programmation, la précision du développement et la maintenance du code; aucun de vos arguments ne pourra être retenu et on vous demandera soit de vous former, soit d'intégrer une entreprise qui a besoin de développeurs mais dont le développement n'est pas le centre principal d'activité (ce qui en soi dévalorisera votre métier de développeur).
Modifié par ohweb (24 Jan 2014 - 11:09)

ohweb a écrit :
En sachant que Drupal est développé sous Symfony.

Drupal 8 oui, mais il est encore en alpha. Nous ne risquons pas de l'utiliser avant 2015. Drupal 7 est en procédural mais on a une gestion très propre des choses. Quant à Drupal 8 son utilisation sera probablement conscrite à des sites à haut budget à cause du fort coût en développement, maintenance et ressources du système.

ohweb a écrit :
C'est aussi le seul chemin pour être reconnu comme expert PHP dans le monde professionnel, si vous ne connaissez aucun framework de ce type, vous n'êtes pas considéré comme un "vrai" développeur PHP.

Je ne remet pas la nécessité de l'objet et des frameworks en vogue dans le CV d'un développeur pro PHP. Mais ce n'était pas la demande.

ohweb a écrit :
Aujourd'hui nous avons des outils très performants, nous n'avons pas le temps de réinventer la roue, aussi il serait "anticonformiste", de vouloir à tout prix esquiver MVC ou l'objet; en tant qu'intégrateur, cela peut passer mais en tant que développeur spécialisé ça casse. Vous le verrez très rapidement si vous décidez d'occuper un poste dans une boîte de développement.

Encore une fois oui c'est nécessaire sur un CV de dev, mais non ce n'est pas obligatoire sur tous les projets. On ne choisit pas un paradigme, un système ou un framework parce que c'est à la mode et que tout le monde en fait, mais par divers points:
– Budgets à disposition
– Conséquences sur la maintenance et besoins/possibilités/budget sur la maintenance
– Tests
– Besoins en collaboratifs et besoins
– Recrutement et compétences disponibles sur le marché
– Compétences disponibles dans notre boîte/partenaires
– Viabilité
– Communauté
– Performances et dimensions serveur & bande passante
– Temps à disposition
– Flexibilité
– Durée de vie du projet
– Mises-à-jour
etc.
Sans oublier, moins présent dans le monde pro, mais incontournable pour un amateur:
– Le plaisir

kustolovic a écrit :

Ce message ne t'était pas particulièrement destiné, je t'ai cité pour rebondir sur la discussion mais je m'adressais davantage à l'auteur du sujet en essayant de l'éclairer en fonction de mon expérience personnelle
J'aurai sans doute dû le préciser, au temps pour moi.

Et pour Drupal 8 je n'étais pas au courant, je n'utilise pas ce CMS, je pensais que Symfony était déjà en application dessus, au temps pour moi tu m'apprends quelque chose
Modifié par ohweb (24 Jan 2014 - 12:37)

ohweb a écrit :

Vous n'êtes pas sans savoir qu'internet est un monde en constante évolution, et qu'il est impossible de garder les habitudes de développement d'il y a 10 ans alors que PHP n'en était qu'à sa version 3 et que le mot objet n'existait même pas encore dans ce langage.

Faut te remettre à jour dans ton calendrier, les années passent vite tu sais.

PHP 4 (qui commence déjà à inclure l'orienté objet, même si moins bien que le PHP5) date de mai 2000, soit 14 ans, déjà.
en 2004 (le 13 juillet), tu es déjà au PHP 5, avec l'orienté objet presque complet par rapport à la version actuelle. J'ai d'ailleurs une version de PHP 5 pour les nuls, avec plusieurs chapitres sur l'orienté objet datant de 2004.

Alors non, y a 10 ans, le PHP était DEJA dans sa version 5 (il faut remonter à 1998 pour le php 3, soit 16 ans) et comprenait déjà l'orienté objet.

Lothindil a écrit :
Faut te remettre à jour dans ton calendrier, les années passent vite tu sais.

PHP 4 (qui commence déjà à inclure l'orienté objet, même si moins bien que le PHP5) date de mai 2000, soit 14 ans, déjà.
en 2004 (le 13 juillet), tu es déjà au PHP 5, avec l'orienté objet presque complet par rapport à la version actuelle. J'ai d'ailleurs une version de PHP 5 pour les nuls, avec plusieurs chapitres sur l'orienté objet datant de 2004.

Alors non, y a 10 ans, le PHP était DEJA dans sa version 5 (il faut remonter à 1998 pour le php 3, soit 16 ans) et comprenait déjà l'orienté objet.

Ce qui conforte encore plus mon propos, il y a 10 ans on pouvait déjà passer à l'objet en PHP, donc il est temps pour l'auteur de passer le cap, surtout si il compte exercer le métier de développeur PHP. Personnellement j'ai commencé à coder directement en PHP 5 donc je ne suis pas à jour en effet sur les dates et historiques de version, par contre je le suis sur les technologies actuelles.
Modifié par ohweb (24 Jan 2014 - 14:43)

txR a écrit :

Je n'ai pas envie de lire un livre qui m'explique comment créer une class, comment hériter, les constructeurs etc.. ou qui me parle de voiture dont les propriétés sont la couleur jaune/rouge..

C'est le principe même de la poo. Si dans les bases de la poo, il y a une incompréhension ou une compréhension partielle, ce sera la cata dans les concepts plus avancés.

Alsacreations va croire que je suis commercial pour Eyrolles et Hugues Bersini. Non, non je vous rassure. Lorsque je t'ai parlé du livre de H.Bersini, tu vas obligatoirement passer par cette étape. Ce qui est différent dans ce livre, c'est la compréhension et son approche du sujet. Il aborde la poo dans différents langages nobles de la poo (python, java, c#, c++, php). Chaque langage a une manière un peu différentes d'aborder la poo (ex : en php, le multi héritage n'existe pas).

Il faut le lire tranquillement pour l'assimiler car le contenu est très riche. Dès le début, on comprend très bien la différence du procédurale et de la poo. C'est devenu très limpide pour moi dès le début du bouquin. Je me souviens que c'est à partir de l'explication d'un environnement quelconque (l'exemple était une marre, un lion et une antilope). Pourtant au début, ce ne sont que les bases. Par la suite, tu apprends les différents concepts (héritage, polyphormisme, encapsulation, etc.) avec des exemples limpides. Dans les mises en pratique, tu apprendras à modéliser un match de foot par exemple et à la fin du livre, c'est modéliser un flipper en UML et le coder.

Je me souviens avoir lu sur le web un bon tuto (je ne retrouve plus le lien) expliquant les concepts de base de la poo et mis en pratique. Le sujet était une bonne intro sur le dév d'un rpg. Par contre, aucun diagramme UML .

Si demain, tu sais que tu te cantonneras vers un style d'applications : webshop comme tu l'as dit précédemment, je ne vois pas trop l'intérêt d'apprendre la poo pour concevoir des applications élaborées. Le jeu n'en vaut pas du tout la chandelle. Je pense qu'il suffit d'utiliser les solutions existantes (ex : Prestashop, Magento, Thelia, etc.). Se tenir au concept du framework en connaissant les rudiments de la poo, cela suffit amplement. On sait faire vraiment beaucoup de choses et proprement.

Par contre, demain tu sais que tu dois créer un traitement de texte pour le web et dans 6 mois 1 an voir 2 ans, tu dois créer un logiciel de gestion commercial, puis 6 mois, 1an plus tard tu dois créer un jeu vidéo rpg ou de gestion type Sim City. Oui, l'étude de la poo est recommandée.

Il y a aussi ce cas où tu veux/dois créer une seule application suite à une problématique personnelle. Tu veux que cette application soit robuste et tu dois travailler en équipe ou pas, là aussi un bon exemple où la poo est recommandée. A cet instant, je pense à l'histoire d'Open ERP anciennement appelé Tiny ERP. Il me semble que le développeur avait dû concevoir cette application pour le magasin de son père.

Je crois que le plus gros avantages d'apprendre la poo est qu'à travers chaque langage noble, il y aura la même philosophie/concept. ex : Je suis dev AS3 et ce langage est de moins en moins demandé. Donc j'apprends le Python. Après avoir appris la syntaxe du Python et son vocabulaire, je sais déjà élaborer de grosses applications dans ce langage. UML veut bien dire ce qu'il veut dire : Unified Modeling Langage. Une très bonne compréhension de ce langage et de ses concepts avancés permettent de créer ce que l'on veut dans n'importe quel langage (objet ou pas) et résoudre les problématiques récurantes.

Au passage, je t'invite à lire les commentaires des internautes sur Amazon par exemple pour tous les bouquins que je t'ai indiqués.
Modifié par niuxe (24 Jan 2014 - 17:26)

Maintenance,évolution sans mvc,c'est de l'amateurisme.
Le souci est que le php oo ne reflète que du procédural objet : fonctions->classes.Dans 99% des cas.Java est galvaudé mais je constate que peu de programmeurs java ne conçoivent en java.Ils codent en java ,c'est tout.Le paradigme est noyé,adieu le langage de très haut niveau,rationnel.On n'y est pas.Keep it simple hein?