Discussion :

[Benjamin Delespierre]

Les développeurs PHP sont-ils fonctionophobiques ? C'est en tout cas ce que pense un jeune développeur allemand. Sur sa page GitHub, nikic déplore la surdominance de l'OOP sur la programmation procédurale et dénonce la pratique selon lui trop répandue de programmation orientée classes.

D'après lui, cette réticence à utiliser des fonctions viendrait principalement du chargement automatique des classes, une fonctionnalité aujourd'hui largement répandue qui permet le chargement automatique de classes à la demande, ce qui est nativement impossible avec les fonctions. Les développeurs PHP seraient donc tentés d'exprimer leurs besoin au travers de méthodes, ce qui conduit à une approche orientée-classes moins naturelle que l'utilisation de fonctions.

nikic va jusqu'a dénoncer la pratique courante consitant à isoler chaque classe dans un fichier séparé et invite les développeurs à adopter l'approche Python où chaque fichier caractérise souvent un module et non une seule classe, permettant de ce fait l'usage naturel de fonctions.

Source : L'article sur le blog de nikic

Et vous ?

Trouvez-vous également que l'usage des classes est parfois abusif voire contre-productif ?
Préférez-vous l'approche procédurale ou objet ?
Comment structurez-vous votre application ?

[berceker united]

Je sais pas trop ce qu'il veut dire. L'utilisation de classe ou développer en objet. Il est vrai qu'il y en a qui utilise des classes comme des sacs à fonctions.
Après, l'utilisation d'un fichier par fonctionnalité au lieu que ça soit par classe me semble pas idiot non plus. Il arrive qu'on ait besoin d'une classe qui soit toute petite,dommage d'utiliser un fichier rien que pour ça.
PHP est fortement influencé par les critiques faite par le monde de Java et tente du coup de côtoyer le standard java tant que possible.

[matios]

En effet, PHP est déjà un très bon langage et très complet sans la moindre utilisation de la POO.

Pourquoi toujours vouloir programmer orienté objet si cela n'est pas nécessaire.

Par contre, je trouve qu'il est plus clair de créer une classe par fichier (d'ailleurs c'est ce que l'on apprend au cours).

Pour moi il est mieux de créer un dossier par module (comme Java, PHP) et non un fichier (comme python, ...).

[raimbow]

J'ai pas la même vision des choses...

Pour moi du fait que le PHP soit relativement simple à prendre à main pour faire de petits sites web conduit à une utilisation massive du langage par des gens non-informaticien ou peu expérimenté. Du coup on se retrouve avec du code parfois assez crade et sans l'ombre de POO.

Pour ceux qui ont plus de connaissance en programmation et qui utilisent la POO, je ne vois pas vraiment en quoi c'est un problème. Même l'utilisation bancal de la POO ou on fait quelques classes très générique avec 50 ou 100 méthodes du genre Tools() ou SiteWeb() qui regroupent tout et n'importe quoi ne me semble pas nécessairement pire que du code procédural. Surtout qu'il à l'air de dire que les gens font ça pour exploité l'auto-loading qui ne me semble pas un concept utilisé par des débutants. Donc, ça me semble curieux comme réflexion. L'idéal ça aurait été qu'il montre des exemples de code et de classe qu'il considère inutile, ça aurait été mieux pour comprendre ce qu'il veut dire.

A propos de la technique 1 classe = 1 fichier je ne vois pas d'intérêt à faire ça. Surtout vu le prix moyen du fichier aujourd’hui. Enfin si, ça à du sens si on code avec notepad et pas un IDE qui intègre la navigation oui, mais bon...
Le gros avantage 1 classe = 1 fichier c'est la facilité de réutiliser une classe (on copie juste le fichier en entier, pas besoin de copier/coller la classe qu'on veut réutilisé parmis 4 ou 5 autre classe). C'est aussi plus pratique lorsque bosse en groupe avec un serveur de versionning. C'est pas rare de bosser sur le même module, mais on bosse rarement sur la même classe.

En faite en y réfléchissant, vu les IDE actuels, la notion de fichier physique est presque devenu inutile même.

[matios]

A propos de la technique 1 classe = 1 fichier je ne vois pas d'intérêt à faire ça. Surtout vu le prix moyen du fichier aujourd’hui.

Heu, de quel prix tu parles ??

En faite en y réfléchissant, vu les IDE actuels, la notion de fichier physique est presque devenu inutile même.

Pourquoi les fichiers physiques peuvent être inutiles ?

[ascito]

A la fois, j'ai lu l'article, et me dit que la question n'est pas de savoir si nous devons définir des class personnelles, ou utiliser des fonctions personnelles, mais plus de savoir à quel moment il est bon d'abstraire les objets du langage php déjà disponibles en php natifs ( qui à une incidence sur les version ), et à quel moment il est préférable d'utiliser des fonctions, quand on pense is_function va retourner false ;

[Invité]

C'est un sujet de débat sans fin.

La popularité de Php viens principalement du fait qu'il peut être utilisé par un néophyte souhaitant un site sur trois pages développé dans la journée, comme de professionnels l'exploitant pour développer de vrais gros logiciels.
C'est cet souplesse dans son mode d'utilisation qui a fait son adoption.

La question n'est pas de connaitre et de fixer LA méthode d'exploitation de php, mais avant tout le contexte. Il serais une perte de temps d'installer Symfony pour un site de trois pages sans back office. Il serais difficile de développer, maintenir et versionner un système intranet gérant n bases de données de x Go dans un code purement procédural sans niveau d'abstraction et de séparation des différentes couches et à cela l'OO est très bien adapté.

Son interrogation est louable, je pense que tout le monde se la pose, et ceux, régulièrement.
Tout est une question de contexte, je ne pense pas que j'y trouverais une réponse un jour.

[arnolem]

Mouai, ca c'est de l'actu qui sert a rien.
En plus, c'est complétement con et inutile ce qu'il dit.
Place au troll ...

[Neko]

Mouai, ca c'est de l'actu qui sert a rien.
En plus, c'est complétement con et inutile ce qu'il dit.
Place au troll ...

Merci pour cette argumentation très complète! Ça donne une super image des "Rédacteur/Modérateur"

[berceker united]

Merci pour cette argumentation très complète! Ça donne une super image des "Rédacteur/Modérateur"

Il a raison, c'est un sujet à troll qui va parler sur le forum sur un sujet qui tourne en rond et qui mène à rien. Cela aurait pu être valable il y a 7-8 ans mais aujourd'hui ça a pas beaucoup de sens. Il suffit de lire les discutions. Tout le monde à chacun son idée. Aucune est vrai ou fausse. PHP permet de répondre à pas mal de cas. Il y a pas tortiller sur ça.

[jeroy]

La question posée peut se factoriser à "un langage peut-il être multi-paradigmes". Mon humble opinion est un Non des plus définitifs. Les précédents (Scala ou Erlang) ont montré que :
- sur les listes de diffs internes on tente à tout prix de sauver l'aspect "multi-paradigmes",
- dans la réalité des faits (la prod stricto-sensu), on utilise en priorité l'un des paradigmes : pour PHP, l'objet (Zend, sf), pour Scala idem (Play!) pour Erlang le fonctionnel (OTP).

Le besoin d'un paradigme fort est essentiel à un langage, quel qu'il soit. C'est ce que la communauté a toujours reproché à PHP (un choix définitif entre objet ou procedural est indispensable pour assurer la perennité du langage).

@MaitrePylos : si la core team de PHP n'était pas un sérail, et qui de l'avis général conduit le langage droit dans le mur (PHP 6?), je serai ravi d'y poster des RFC. Le process interne de la core team PHP est plus souvent un sujet de vannes que d'exemplarité dans l'open-source... trouve-moi le lien où sont décrites les guidelines pour le droit de commit, et je serai ravi de participer à ce mirobolant projet qu'on dit "open-source" - personnellement je ne l'ai jamais trouvé...

[Conaclos]

La pratique de l'Orienté Objet (je parle de la méthodologie) n'est pas à remettre en cause elle apporte de nombreux avantages.

En revanche la simple utilisation de ce concept comme structure de stockage de fonction (donc leur utilisation en terme de module) est une mauvaise chose. Il est préférable dans ce cas d'utiliser de simples fonctions.

Mais la déclaration de fonction ce fait de manière globale, ce qui peut poser des problèmes de conflits entre bibliothèque et de maintenance.

Quant à mettre plusieurs classe dans le même fichier je ne suis pas convaincu.
Pour moi une classe est la primitive de la modularisation orienté objet.

[grunk]

Faire une classe quand une simple fonction peut suffire effectivement c'est idiot. C'est d'ailleurs pas rare de voire une classe qui peux simplement se remplacer par une fonction native de php.

Maintenant je me vois pas maintenir une appli complète en procédurale ou chaque fichier est un module.

nikic va jusqu'a dénoncer la pratique courante consitant à isoler chaque classe dans un fichier séparé et invite les développeurs à adopter l'approche Python où chaque fichier caractérise souvent un module et non une seule classe

Perso je l'invite à retourner faire du Python , y sera sans doute plus heureux

[stailer]

Trouvez-vous également que l'usage des classes est parfois abusif voire contre-productif ?

Il n'y a vraiment qu'en PHP qu'on peut malheureusement se poser cette question.

En PHP, rapport à C# nous avons la "chance" d'avoir 2 modes de programmation :
1- "A l'arrache" -> procédural
2 -"Professionnel" -> objet

En C# on ne peut pas se poser cette question : tout est objet... Et tant mieux.

J'adore PHP mais je suis toujours déçu de voir sa considération par les développeurs C# ou Java, justement dû à cause du mode "A l'arrache", encore très utilisé par des programmeurs ayant surtout très peur de l'objet.

Pour moi PHP = Zend Framework, Symfony etc...
Tout est objet et respecte le MVC (ce qui est le minimum syndical quand on fait une appli dépassant les 3 pages).
Le seul fichier non objet : index.php , qui lance l'initialisation un peu comme le Global.asax en ASP.NET MVC.

[Freem]

Il n'y a vraiment qu'en PHP qu'on peut malheureusement se poser cette question.

En PHP, rapport à C# nous avons la "chance" d'avoir 2 modes de programmation :
1- "A l'arrache" -> procédural
2 -"Professionnel" -> objet

Allons bon... PHP serait le seul langage multi-paradigme? Il semble que l'on m'aie menti sur C++ alors. (Bon, j'imagine que tu ne parlais que des "langages web" d'un autre côté)

Quant à ta classification procédural = à l'arrache... Je trouve ça bancal.
J'aime énormément la POO, mais j'ai vu du code POO très bancal, et d'un autre côté, j'ai vu du code procédural très propre et professionnel.

Heu, de quel prix tu parles ??

Pourquoi les fichiers physiques peuvent être inutiles ?

J'ignore de quel prix il peut parler précisément, mais, qui dit "plus de fichiers" implique effectivement un coût:
Plus d'inode, même si ce n'est que peu d'octets, le coût existe, et, à une époque, avait de l'importance.
Il y a aussi le fait que chaque fichier plus petit qu'un bloc occupera malgré tout le bloc entier. Encore une fois, perte d'espace. Et perte de vitesse, le bras mécanique du DD devant se déplacer plus: fragmentation du projet.

D'un autre côté, il est peut-être plus simple de parser un petit fichier qu'un grand: plus économe en mémoire, et contexte moins lourd.

Oui, les fichiers ont un coût, après, il est régulièrement négligeable. Ceci dis... un projet libre que je surveille - http://openmw.org/2012/07/09/week-review-14/ - à divisé par 2 le temps de compilation en corrigeant des problèmes d'inclusion inutiles ou mal placées (certes, ce n'est pas un projet PHP)

D'un autre côté, un coût plus pour le développeur:
_ fichier unique => plus long à lire, moins lisible
_ fichier unique => on ne sait pas nécessairement dans quelle classe on se trouve, ce qui peut se faire habituellement en regardant le nom du fichier

D'ailleurs, je rejoins raimbow sur le fait que l'usage des fichiers tel qu'on le connaît actuellement semble un peu... ancien. J'aurai même dit, hérité du procédural.
Après tout, les fichiers ne sont censés être qu'un support de stockage. Raisonner avec eux est certes pratique, mais je pense qu'on pourrait très bien imaginer un système différent de l'habituel 1 fichier par classe, même si dans un langage qui compile vite je ne suis pas persuadé qu'il y aurait un gain.
La ou je ne suis pas d'accord, c'est que les IDE modernes pourraient nous permettre d'abstraire la structure sur disque de nos projets.

Quant au fait: 1 module = 1 fichier, je crois que ça montre bien que cet ado est habitué à travailler sur des projets d'ampleur. Si un seul de ses programmes dépasse les 5K ligne pour une bonne raison, je serai intrigué.
Le fichier unique, c'est quand même assez ridicule, je ne comprend même pas comment une telle affirmation a pu ne pas discréditer "l'article" originel.
Ne serait-ce que pour le versionning...

[monsieurben]

Il n'y a vraiment qu'en PHP qu'on peut malheureusement se poser cette question.

En PHP, rapport à C# nous avons la "chance" d'avoir 2 modes de programmation :
1- "A l'arrache" -> procédural
2 -"Professionnel" -> objet

En C# on ne peut pas se poser cette question : tout est objet... Et tant mieux.


J'adore PHP mais je suis toujours déçu de voir sa considération par les développeurs C# ou Java, justement dû à cause du mode "A l'arrache", encore très utilisé par des programmeurs ayant surtout très peur de l'objet.

Pour moi PHP = Zend Framework, Symfony etc...
Tout est objet et respecte le MVC (ce qui est le minimum syndical quand on fait une appli dépassant les 3 pages).
Le seul fichier non objet : index.php , qui lance l'initialisation un peu comme le Global.asax en ASP.NET MVC.

C'est lourd de voir tout le temps associés les termes "procédural" et "à l'arrache" :

- de très bons logiciels sont faits de manière professionnelle tout en n'utilisant aucun objet (certains développeurs C ont du faire une crise cardiaque en lisant ton message...).
- C'est un peu dur de faire du full POO en PHP : à part quelques gros morceaux comme PDO ou mysqli, presque toute l'api est écrite sous forme de fonctions uniquement, et les types ne sont pas des objets. Alors, le PHP 100% objet n'existe pas (à moins de s'amuser à wrapper tous les types et toutes les API de PHP dans des classes, mais faut vraiment avoir du temps à perdre et n'avoir aucune exigence de performances. Et à un moment, y'aura toujours des appels de fonctions non issues de classes).

Par ailleurs, je trouve ta phrase :

Pour moi PHP = Zend Framework, Symfony etc...

Plutôt dangereuse et surtout à ne pas transmettre aux développeurs débutants : les frameworks PHP reposent massivement sur les APIs du langage. Et quand on utilise un framework sans en comprendre le fonctionnement sous-jacent, on se retrouve vite avec des bugs difficilement compréhensibles, parce qu'ils viennent d'une limitation du langage en lui-même et pas du framework...

[Grimly_old]

J'ai déjà eu à développer dans un projet où tout étais en procédural et ce n'est une bonne expérience car j'ai pu trouver tous les moyens de contourner un Framework. Pour le jeune nikic, je peux lui trouver un poste chez moi, il s'entendra bien avec le seul architecte PHP de mon skill group.
Après il y a tous les goûts dans la nature. Pour ma part je n'ai pas que les même goûts.

Imposer un format (classes ou pas de classes) n'est pas la bonne façon. Chacun code à sa sauce et elle ne changera jamais, et tant mieux, je suis pour le fait que chacun garde son identité ! Il suffit seulement d'assembler les bonnes personnes ensemble.

[stailer]

Je te trouve ta phrase plutôt dangereuse et surtout à ne pas transmettre aux développeurs débutant

Voilà comme ça au moins, sur 2 développeurs débutants, y en a qui commence en ASP.NET MVC, qui s'éclate avec ce pattern, les possibilités de C# , apprend une rigueur, entities etc...

Et l'autre qui début avec PHP, avec rien et les commandes pdo_mysql

1 semaine après ils se retrouvent, comparent et voilà comment on en arrive à 5 ans plus tard avec les 3/4 des dévs non php qui tiennent ce discours :

Hein PHP ? Oula... oui tu codes à l'ancienne quoi...

Ou :

PHP, ouaiiis, c'est bien pour débuter quoi... après faut passer aux choses sérieuses

Sans oublier le rituel (entendu de mes propres oreilles par des ingénieurs) :

PHP c'est nul !! tu peux même pas faire de l'objet !

Donc je persiste et signe : Symfony, ZF, Code Igniter.. Allez y à fond !! même pour débuter !
C'est comme ça qu'on fait en Java et C# et PHP propose aujourd'hui ces vrais outils de dévs professionnels.


EDIT :
Roh, j'avais pas vu ça :

C'est un peu dur de faire du full POO en PHP : à part quelques gros morceaux comme PDO ou mysqli, presque toute l'api est écrite sous forme de fonctions uniquement, et les types ne sont pas des objets. Alors, le PHP 100% objet n'existe pas

Quelle mauvaise foi pas possible !
Tu as très bien compris ce que je voulais dire quand je parlais de "tout en objet"... Pas de PHP mais de ton application bien entendu !
Après PHP est fait comme ça en interne, on appelle des fonctions... Mais bien sûr que non je vais pas faire un objet pour recrér un "str_replace" !

[monsieurben]

Voilà comme ça au moins, sur 2 développeurs débutants, y en a qui commence en ASP.NET MVC, qui s'éclate avec ce pattern, les possibilités de C# , apprend une rigueur, entities etc...

Et l'autre qui début avec PHP, avec rien et les commandes pdo_mysql

1 semaine après ils se retrouvent, comparent et voilà comment on en arrive à 5 ans plus tard avec les 3/4 des dévs non php qui tiennent ce discours :



Ou :



Sans oublier le rituel (entendu de mes propres oreilles par des ingénieurs) :



Donc je persiste et signe : Symfony, ZF, Code Igniter.. Allez y à fond !! même pour débuter !
C'est comme ça qu'on fait en Java et C# et PHP propose aujourd'hui ces vrais outils de dévs professionnels.


EDIT :
Roh, j'avais pas vu ça :


Quelle mauvaise foi pas possible !
Tu as très bien compris ce que je voulais dire quand je parlais de "tout en objet"... Pas de PHP mais de ton application bien entendu !
Après PHP est fait comme ça en interne, on appelle des fonctions... Mais bien sûr que non je vais pas faire un objet pour recrér un "str_replace" !

OK pour la mauvaise foi sur le 100% objet (c'était juste pour pousser ton exemple au maximum)

Par contre, je te retourne la politesse sur ta description de PHP : rien et PDO ? c'est sûr, avec ce genre de descriptions, PHP ne va pas avancer dans la tête des développeurs java - C#/.Net.

Et encore une fois, objet et professionnalisme n'ont rien à voir. Regarde le C, qui reste la base d'à peu près tous les OS et de pas mal de softs professionnels : pas un seul objet. Alors, tous les développeurs C sont des amateurs, parce qu'ils n'ont pas de vrais outils de professionnels ?

Pour conclure, je persiste et signe : adapter son outil à son besoin est bien plus important que faire de la POO pour le principe. Et ce n'est pas parce que c'est "comme ça qu'on fait en C# et en java" (sic, hein) que c'est la seule manière professionnelle de travailler.

[SurferIX]

Donc je persiste et signe : Symfony, ZF, Code Igniter.. Allez y à fond !! même pour débuter !
C'est comme ça qu'on fait en Java et C# et PHP propose aujourd'hui ces vrais outils de dévs professionnels.

Je te laisse lire le blog d'une personne bien plus compétente que moi dans le domaine, qui explique la loi des abstractions qui fuient

Dit en résumé et à ma façon : oui, c'est très bien, très pratique, pour commencer et apprendre les bases de la POO mais il arrivera forcément toujours, absolument toujours, un jour où quelque chose ne fonctionnera pas correctement, le débutant (ou la personne qui s'autoproclamera "confirmée" (il y en a tellement...)) qu'il ne pourra jamais résoudre le problème sans avoir certaines bases (= connaître les fonctions de base de Php, et pour pousser plus loin, connaitre le système sur lequel ça tourne, voire connaître le C donc avoir appris aussi à ne pas faire de programmation POO). Donc à mon sens, savoir la POO, et aussi savoir la programmation linéaire c'est comme le reste : ça ajoute juste des cordes à son arc, mais ça n'est pas une fin en soi.

Par contre je suis tout à fait d'accord avec le fait qu'un article très orienté écrit par une personne de 17 ans encore à l'école semble pris autant au sérieux.