Discussion :

[stb007]

1- "A l'arrache" -> procédural
2 -"Professionnel" -> objet

Ton avis de professionnel m’intéresse,

imaginons la fonction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
/**
* Traduit une chaîne de caractère 
*/ 
function _($str) {
  return Registry::get("catalogue")->traduire($str);
}

Explique moi l’intérêt de créer un objet pour faire une opération simple comme celle-ci et transverse par rapport à l'aspect métier de ton application.

Moi j'adore les gens qui estiment que l'objet c'est la panacée, pour info vaut mieux bosser sur une appli bien codée en procédural qu'une appli mal codée en objet. l’intérêt de l'objet c'est "d'humaniser" le développement en essayant de le représenter avec des choses moins abstraites que des fonction, mais c'est comme tout il faut le faire avec parcimonie, et savoir quand une fonction est plus indiquée qu'un objet à certains moments.

[Tryph]

Ton avis de professionnel m’intéresse,

imaginons la fonction suivante :
/**
* Traduit une chaîne de caractère
*/
function _($str) {
return Registry::get("catalogue")->traduire($str);
}

Explique moi l’intérêt de créer un objet pour faire une opération simple comme celle-ci et transverse par rapport à l'aspect métier de ton application.

Moi j'adore les gens qui estiment que l'objet c'est la panacée, pour info vaut mieux bosser sur une appli bien codée en procédural qu'une appli mal codée en objet. l’intérêt de l'objet c'est "d'humaniser" le développement en essayant de le représenter avec des choses moins abstraites que des fonction, mais c'est comme tout il faut le faire avec parcimonie, et savoir quand une fonction est plus indiquée qu'un objet à certains moments.

explique moi l'intérêt de faire une fonction qui contient une ligne de code...
les exemples à la con on peut leur faire dire ce qu'on veut, ils n'en constituent pas plus des arguments de poids.

quant au fait qu'il vaut mieux bosser sur une appli bien codée en procédural qu'une appli mal codée en orienté objet, ça me parait évident et je penses pas que tu auras d'avis contraire.
mais quitte à continuer à énoncer des évidences, on peut aussi dire l'inverse:
vaut mieux bosser sur une appli bien codée en orienté objet qu'une appli mal codée en procédural... qui va me contredire...?

n'empêche que ça avance pas à grand chose.

pour ce qui est de faire de l'objet avec parcimonie, je sais pas trop ce que ça veut dire...
dans un projet objet on fait de l'objet, dans un projet procédural on fait du procédural...
le pire de tout serait à mon avis de mélanger les 2 avec parcimonie ou non. c'est d'ailleurs bien ce qui cloche avec le PHP (bien que c'est un langage que j'apprécie).

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.

je suis pas bien d'accord. laisser chacun coder à sa sauce c'est le meilleur moyen d'avoir un joyeux bordel in-maintenable à la sortie à mon avis. et mélanger de l'objet et du procédurale, ça ma parait extrêmement bancale comme idée.
après si on se contente de faire des classes statiques pour y mettre des fonctions pour faire une sorte de bibliothèque mais sous forme de classe, effectivement ça sert à rien. et d'ailleurs je n'appelle pas ça faire de l'orienté objet.

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" !

c'est certain que faire une classe pour juste avoir un équivalent de la fonction str_replace c'est pas forcément utile.
mais dans un projet développé en orienté objet, çe ne me parait pas déconnant d'intégrer une telle méthode dans une classe String ou RegEx (qui ne ferait pas que ça bien entendu) si le besoin s'en fait sentir. ne serait-ce que pour garder une cohérence.

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

à ce moment là, faut pas non plus que les débutants fassent de l'ASP ou du Struts...

[Nathanael Marchand]

explique moi l'intérêt de faire une fonction qui contient une ligne de code...
les exemples à la con on peut leur faire dire ce qu'on veut, ils n'en constituent pas plus des arguments de poids.

Pas d'accord! En l'occurrence dans ce cas ca permet une indirection pour faire les traductions (enfin ca semble). Il s'avère qu'en l'occurrence cette implémentation est relativement simple mais il n'est pas impossible qu'à l'avenir elle soit plus compliquée. Ca simplifie donc le refactoring. Après c'est sur qu'il ne faut pas 12° d'indirections

[stb007]

explique moi l'intérêt de faire une fonction qui contient une ligne de code...
les exemples à la con on peut leur faire dire ce qu'on veut, ils n'en constituent pas plus des arguments de poids.

Lit ce qu'a écrit Nathanael, ça m'évitera de le faire, pourtant l'interet de cette fonction est évident..
Je maintiens que pour certaines choses simples il est inutile de faire un objet, notamment pour pas mal de choses transverses (traductions, sessions etc...). Aprés que certains soient fan des méthodes à ralonge de Java, je respecte, moi j'aime pas, point. Je ne nie pas que l'objet est intéressant quand on développe des composants métiers car justement on arrive plus facilement à modéliser mentalement les interactions entre éléments.

pour ce qui est de faire de l'objet avec parcimonie, je sais pas trop ce que ça veut dire...

Je me répète donc : Quel intérêt dans mon exemple de faire un objet pour traduire une chaine, donne moi de vrais arguments stp.

dans un projet objet on fait de l'objet, dans un projet procédural on fait du procédural...

Voila avec ce genre de rigidité on ce retrouve avec d'énormes paquets de caca full objet bien inbitable. Tout est question de mesure, être rigoureux c'est différent d'être rigide.

[Tryph]

Je maintiens que pour certaines choses simples il est inutile de faire un objet, notamment pour pas mal de choses transverses.

bah moi je maintiens que c'est un exemple bidon qui énonce une évidence pour faire croire que toute l'argumentation tient la route...
personne ne te dira qu'il faut faire une classe pour y mettre une méthode.
mais j'ose espérer, en tant qu'expert procédural, que tu n'oseras pas me soutenir que c'est mieux de faire une bibliothèque pour une fonction...

soit tu as un projet qui ne fait qu'une chose et ils n'est jamais nécessaire de faire un gros projet orienté objet. soit tu as un projet de taille honorable qui nécessite par exemple de mettre en place un système d'internationalisation et je doute pas qu'on trouvera une classe ou mettre ta fonction de récupération de chaine dans un catalogue sans forcément créer une nouvelle classe juste pour faire ça (encore mieux même, la classe ou mettre ça s'imposera probablement d'elle même)...

d'ailleurs, même si le traitement en question est transversale (internationalisation par exemple), rien n'empêche d'implémenter l'internationalisation dans une classe dont tous les éléments à traduire où que ce soit dans l'appli hériteront...
et pour le cas ou on a 2 hiérarchies d'objets bien distinctes à traduire sans aucune super-classe commune, bah on fait une interface et on l'implémente dans au niveau le plus haut possible dans les 2 hiérarchies pour éviter d'avoir à l'implémenter 50 fois...
bref, je vois pas ou est le problème de l'orienté objet pour l'exemple que tu as voulu soulever.

Je me répète donc : Quel intérêt dans mon exemple de faire un objet pour traduire une chaine, donne moi de vrais arguments stp.

comme dit plus haut: aucun évidemment. c'est bien cette évidence de la réponse que je te reproche. t'en as vu beaucoup des classe avec une seule méthode? ça m'étonnerait (a part peut être les classes d'évènement en java y a quelques années. je sais pas si maintenant java propose un système d'évènement à la .NET).

(voire plus haut pour les arguments)

à moi de poser une question: fais-tu des bibliothèques d'internationalisation avec une seule fonction toi...? si non, pourquoi...? si oui, peux tu m'expliquer l'intérêt...?

Voila avec ce genre de rigidité on ce retrouve avec d'énormes paquets de caca full objet bien inbitable. Tout est question de mesure, être rigoureux c'est différent d'être rigide.

quand je vois "caca full objet", j'ai des doutes sur celui qui est réellement rigide...

[Grimly_old]

je suis pas bien d'accord. laisser chacun coder à sa sauce c'est le meilleur moyen d'avoir un joyeux bordel in-maintenable à la sortie à mon avis. et mélanger de l'objet et du procédurale, ça ma parait extrêmement bancale comme idée.
après si on se contente de faire des classes statiques pour y mettre des fonctions pour faire une sorte de bibliothèque mais sous forme de classe, effectivement ça sert à rien. et d'ailleurs je n'appelle pas ça faire de l'orienté objet.

J'ai précisé qu'il faut assembler les bonnes personnes. Je déteste le procédural pur alors j'ai utilisé des classes dans mon projet PHP afin d'éviter parfois des fonctions à 50 arguments. J'ai eu du mal à expliquer à certains classophobes comment ça fonctionnait et eux ont continué à modifier des fonctions avec encore plus d'arguments pour des cas particuliers alors qu'un simple héritage et modification d'une partie du comportement suffirait. Du coup on n'aurait jamais du travailler ensemble.
Après je ne dénigre le travail de personne. Sa solution fonctionne bien et est assez commentée ou explicite. Lui reprocher d'avoir fait ce qu'il a fait serait lui retirer son identité pour imposer la mienne, c'est mal. Ca ne nous a pas empêché de faire du peer-programming sur des sujets difficiles.

Donc j'encourage chacun à suivre sa propre voie sans l'imposer. Si erreur il y a, et bien je dirais qu'il faut bien tomber pour mieux se relever.

[camus3]

En fait ya même plus vraiment besoin de classes au sens strict , puisqu'on peut faires des modules du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$x = 0 
 
$myModule = array();
 
$myModule["incX"] = function() use($x){
 return $x++;
}
 
$myModule["getX"] = function()use($x){
return $x;
}
 
# etc ...
 
return $myModule ;

et importer un module de cette façon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$myInstance = require("mymodule.php");

un peu à la node.js

[ascito]

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.

Un code orientée-classes et pour moi à l'inverse de ce qui est dit ici, plus naturelle que l'utilisation abusive de fonctions isolées et désorganisées...

Dans une class tu y range tout de même littéralement des fonctions.

Je trouve son raisonnement étrange, et pas du tout évolutif, suis-le seul ?

[demon66]

Je suis tout à fait d'accord avec @ugo-sans-h

Ce que tu dis est vrai, tout dépend du projet. C'est d'ailleurs pour cela qu'il y a des consultants/développeur.
Exemple, combien de personne sur le web avons-nous vue poser des questions sur symfony par exemple afin de créer un vulgaire petit blog ou bien petit site ?? Sur le web il y a les écho de technologie en vogue pour les geeks et celles pour les profesionnelles. L'engouement pour symfony2 a déteins sur des développeurs amateurs qui ne connaissaient même pas les frameworks pour certain. Identiquement j'ai bossé dans une web agency en tant que ergonome/intégrateur/développeur sous drupal. Nous n'utilision que drupal et donc par moment nous développions des sites vitrine avec drupal. Quel hérésie.

Joomla par exemple a bénéficié d'une grande réputation sur le web, mais concrètement en utilisation professionnel, le cms reste tout de même limité de part sa structure et code plutôt bancale dans certaines parties. Même avec la version 2.5 si elle corrige beaucoup de manque, il reste encore des efforts à fournir.

Nous en revenons à la même problématique qui est de savoir dans à quel contexte sommes-nous rattaché ?
Est ce que l'utilisation d'un framework ou cms est nécessaire ? Si oui quel framework utiliser ? Quel architecture concevoir ? Devons nous utiliser une librairie de fonctions ou de class.

[jeroy]

Currently I am 17, am in my last year of school and live in Berlin/Germany.

Source : http://nikic.github.com/aboutMe.html

Il doit être très content le petit de se retrouvez en une d'une gros site français de développeurs, censé s'adresser aux "professionnels de l'informatique".

L'équipe de DVP a une explication à fournir là ?

[stailer]

DVP n'a pas d'explication à fournir...

Après voilà, c'est la tendance actuelle : bcp de développeurs prennent comme parole d'évangile le 1er blog en anglais venu.

Il suffit qu'un gus aux USA écrive que Perl c'est de la bombe et si son blog est bien référencé ça y est : l'article est cité partout et ça fait débat.

De tout façon aujourd'hui : tout fait débat. Tout se dit et son contraire...

[javan00b]

Hi! My name is Nikita Popov, but you'll mostly meet me as nikic on the internet. Currently I am 17, am in my last year of school and live in Berlin/Germany.

Je comprend pas pourquoi on est en train de parler de tout sa, jai deja été jeune et naif aussi, sa fait parti de la progression normal de la pluspart des développeurs/etudiants, dans quelques années il va probablement revendiquer l'utilisation de la POO avec PHP...

Si tu ecris quelques petit scripts php, bien sur tu pourras t'en sortir sans POO on le sais tous, à plus grand echelle tu ne peux pas te passer de la POO.

[zeyr2mejetrem]

Si tu ecris quelques petit scripts php, bien sur tu pourras t'en sortir sans POO on le sais tous, à plus grand echelle tu ne peux pas te passer de la POO.

Je pense qu'on ne peut réduire l'utilisation d'un paradigme au fait qu'un projet soit "gros" ou "petit".

Chaque paradigme a pour vocation de répondre à une problématique en utilisant une vision du monde adaptée (d'ou l'origine étymologique du mot).

Pour moi, PHP permet d'utiliser au choix le paradigme procédural ou objet pour répondre au mieux au besoin fonctionnel (ce qui est quand même sensé être le but du développement logiciel) et c'est une très bonne chose.
Le revers de la médaille est que cela demande une discipline de la part du développeur qui n'est pas forcément facile à tenir dans les conditions de production (manager qui hurle, client qui harcèle, clim en panne ... ).

En procédural il est très facile de fabriquer du code "spaguetti" qui devient inmaintenable.
En objet, il est aussi facile de tomber dans l'usine à gaz ou dans le "faux-objet" (aka. une classe avec toutes les méthodes et propriétés statiques ou faussement non statiques (utilisation du singleton à outrance)).

Bref, comme d'habitude on peut revenir à la conclusion qu'il n y a pas foncièrement de mauvais outil mais des outils non adaptés à l'utilisation ciblée ou utilisés par des personnes non compétentes dans l'utilisation de cet outil.

D'un autre côté, si les outils étaient "magiques", permettaient de régler tous les problèmes et ne demandaient aucune compétence, le développement ne serait plus un métier (à proprement parler).

[MaitrePylos]

Source : http://nikic.github.com/aboutMe.html

Il doit être très content le petit de se retrouvez en une d'une gros site français de développeurs, censé s'adresser aux "professionnels de l'informatique".

L'équipe de DVP a une explication à fournir là ?

LE petit, à même le culot de proposer des RFC qui sont en passe d'être accepté par le core team de PHP , vous qui critiquez son jeune âge, j'imagine que vous en faites autant.

A bon entendeur

[youccef]

l'un des points forts de la POO est la référence qu'on peut faire aux objets dans la vie reèls, ce qui permet une meilleurs compréhension par les devs.

[Zefling]

Pour moi, ça dépends du projet. J'ai un projet je n'ai qu'une seul classe, tout le reste est en procédural car l'approche objet n'apporte rien, elle complique même les choses. Mais ce n'est pas valable pour tout... Sur un autre projet, j'ai juste un fichier de fonctions qui pallie quelques manques de base et tout le reste est objet. Bref, je dirais : « ça dépends des cas. »

[mantalo]

Ben perso, je suis de ceux qui pense qu'a chaque situation sont développement particulier.

Je pense que pour un projet simple pas besoin de s’embêter avec des classes. Par contre si le besoin s'en ressent je n'hésite pas.

Par contre j'aurais vraiment envi de me mettre à symfony ... je n'ai pas encore réussi à l'installer nulle part. A chaque tuto que j'ai testé il y avait plusieurs ambiguïté qui m'ont bloqué au final.

Je préfèrerais l'installé sur mon Wamp/Easyphp ... mais toujours des soucis d'install. Et VMWare je ne maitrise pas du tout ...

Qqun pourrait me donner un coup de pouce avec un lien ou autre ?

Merci

[Matthieu Vergne]

Si j'ai bien compris l'article, on parle d'utiliser des classes uniquement, pas de programmer en objet. De ce que j'en ai compris, ce qui est abusif est d'utiliser le principe de classes pour centraliser ses fonctions (qu'on appelle donc méthodes pour la peine) en lieu et place des "modules". La critique ne se situe pas sur l'utilisation de la POO. Je me trompe ?

Si j'ai raison, alors je comprends tout à fait l'auteur dans le sens où on mixe les concepts venant d'horizons différents, ce qui n'arrange rien à la compréhension du code. Soit on fait de l'objet (haut niveau) soit on fait du procédural (bas niveau). Mais on ne mixe pas des concepts pour obtenir une simple facilité technique (surtout quand on a la possibilité de faire tout aussi propre avec les concepts déjà présent), c'est du codage d'opportuniste.

Pour ma part je fais de l'objet, chaque classe a un sens concret (qui se traduira par des instances faciles à comprendre et à manipuler) et non abstrait (pour faire office de paquets de fonctions).

[ascito]

Si j'ai bien compris l'article, on parle d'utiliser des classes uniquement, pas de programmer en objet... La critique ne se situe pas sur l'utilisation de la POO. Je me trompe ?

Ca fait du bien de lire quelqu'un qui a vraiment lu l'article

[Matthieu Vergne]

J'ai juste lu l'article Developpez.com, pas les commentaires de l'allemand, donc je me base peut-être sur une omission de l'article. Mais en tout cas c'est ce que j'ai compris.