Discussion :

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

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

[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

[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

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

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

[Zefling]

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.

Surtout quand je vois certains frameworks web Java en plus des annotations, je n'ai pas vraiment l'impression de faire de la programmation objet, ni de la procédurale... Il y a de l'injection de tous les côtés.

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

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

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

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

[zevince]

Moi ce que j'ai du mal a comprendre c'est les intégristes du "tout objet". J'utilise et j'apprécie d'avoir cet outil à disposition.. dans les cas ou c'est utile, et pertinent.. ! Parfois, une simple fonction suffit largement !

Ce ne sont que des outils.. A nous de les utiliser au mieux, pour avoir des codes propres, clairs, bien structurés et surtout.. le plus simple possible !

D'ailleurs, toute l'évolution de php va dans ce sens.. Les classes, puis les namespaces, interfaces, traits.. Tout ca est plutot du domaine de l'organisation du code.. Et plus ton projet est gros, plus tu as besoin d'une organisation stricte.

Quel est le souci avec le fait d'avoir une partie du site en objet et quelques fonctions transversales à coté ? Je ne vois que des avantages.. !

[stb007]

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

Globalement quand je fais de l'internationalisation sur un site Web, cela s’arrête en général à la traduction de chaine de caractère, dans de rares cas j'ai eu à ajouter des cas pour les séparateurs de float (milliers + décimales anglosaxons) et les formats de dates, mais c'est rare, en général je gère ça avec des constantes qui en fonction de la langue retournent telle ou telle valeur.

Alors évidement je parle de ce que je connais : les sites Web.
Effectivement si j'avais à re-développer SAP, je pense que ce serait un peu plus touffu au niveau de l'internationalisation... Et peut-être qu'un object bien structuré m’apporterait de la valeur ajoutée.

Actuellement quand je traduit une chaine j'écris un truc de ce genre :

Code :

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

<?php echo _("Bonjour"); ?>

Et toi tu penses que je vais m'amuser à écrire ça à chaque ligne :

Code :

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

1
2
3
4
<?php 
 $s = new String();
echo  $s->TraduireMaChaine("Bonjour");
?>

PS : ouais j'aurais pu mettre une méthode statique, la belle affaire...

Contrairement à ce que tu penses je ne suis pas un fanatique du procédural, en gros ça occupe 5% d'un projet quand je développe, je bosse avec SF et Zend, donc l'objet je connais, merci.
Je voulais juste mettre en avant l'idée qu'en fonction du projet, du contexte et du langage, il existait des méthodes plus rapides et tout aussi efficaces qui permettent de gagner du temps et que ça n'a rien de farfelu contrairement à ce que tu sembles penser....
Le maitre mot en développement c'est KISS, je t'invite à te renseigner sur ce que ça veut dire, en 10 ans j'ai toujours pu vérifier l'exactitude du bon sens de cette approche...

[Tryph]

je vois parfaitement quel avantage peut vous apporter l'utilisation d'une fonction transversale comme _() et comme elle s'inscrit bien dans une approche KISS.


c'est certain que, pour cet exemple, c'est beaucoup plus rapide: moins de code à taper, pas de réflexion à avoir sur une éventuelle hiérarchie d'objet et surtout "ça marche" alors pourquoi faire mieux?

je sais pas, je suis peut être trop rigide en effet, j'aime pas mélanger les paradigmes, j'aime pas les fonctions de plus de 500 lignes, j'aime pas les variables globales, j'aime pas les variables nommées toto et les fonctions avec des noms qui ne veulent rien dire...

pourtant ça peut parfois être plus rapide et tout aussi efficace à développer, tout aussi simple et stupide ou stupidement simple ou simplement stupide (l'article de wikipedia fourni trop de traductions possibles pour l'approche KISS).

c'est peut être parce que depuis plus de 5 ans je passe mon temps à maintenir des applications probablement écrites par des gens qui n'étaient pas dérangés par tout ça que je suis aussi attaché à la cohérence dans le code.

[ascito]

Avez vous vraiment lu l'article ?
Ce qui me trouble le plus c'est le fait que nous sommes tous d'accord sur le fond, mais que personne ne donne un vrai avis constructif en rapport à l'article


Dans la tournure de l'article, le débat, n'est vraiment pas procédural vs object,
mais de faire un pic de rappel, disant que les modules peuvent se monter de tel et tel façon, qu'il y a 10 ans, nous n'avions que peu de choix, et que les choix engagés à l’époque ont encore certaines raisons d'être.

Maintenant tu peu étendre une classe native php à ta propre classe, c'est un des arguments qui pourrait faire évoluer l'article en démontrant qu'une simple fonction n'était pas disponible en class pour le commun des mortels, alors que maintenant ( PHP 5> sans risque ) la base du noyau se comporte ainsi, voir spl , Iterator, PDO par exemple.

encore une fois, si vous avez lu l'article dite vraiment hors troll, ce que cela peu représenter en terme d'évolution