Discussion :

[mermich]

Si vous voulez aussi vous amuser vous pouvez regarder du cote de la "programmation oriente aspect" ou du "domain specific language".

Ah oui tant qu'on y est oriente evenements aussi.


Au final vous trouverez a chaque fois autant de definitions que de perosnnes prenant part au debat et vu que personnes n'est d'accord sur la definition le debat est d'une sterilite sans non.

[Pyramidev]

utiliser ++i au lieu de i++

Why ?

Dans le cas des entiers, cela n'a aucune importance : pour une expression isolée ++i ou i++, un compilateur C ou C++ normal génèrera le même code machine.
En C++, dans le cas d'un itérateur, il peut y avoir une différence de performance, ou pas. Cela dépend si le compilateur peut inliner le code de operator++ et du constructeur de copie et s'il est assez intelligent pour optimiser. Mais, comme ce n'est ni plus fatiguant ni moins lisible d'écrire ++i que i++ alors, quand on ignore la valeur retournée, on écrit ++i, ce qui évite de se prendre la tête.

[BugFactory]

Possible, mais maintenant, admettons que ce soit la seule raison(j'ai des doutes), et penses business : tu as des séniors efficaces qui bossent rapidement en procédural, et des juniors inefficaces qui se traînent en objet. Sur le marché du travail, tu ne trouve rien d'autre que ce que tu as déjà. Qu'est-ce qui est le plus rationnel?

Tu me fais encore tiquer! "Marché du travail" et "rationnel". Les RH recrutent les juniors pour les payer moins cher. Qu'ils aient besoin de supervision et finissent par coûter trois fois plus cher est le problème du service informatique.
Mais il s'agit de problèmes organisationnels, pas de programmation. Si on veut comparer orienté objet et procédural, il faudrait que ce soit dans des conditions similaires.

Je travaille en SSII depuis des années, ce qui m'a permis de voir de nombreux projets. Dont plusieurs ou une application web Java devait parler à un mainframe COBOL. Et j'ai eu aussi bien le cas où l'équipe web était efficace et l'équipe mainframe non que l'inverse. Et même une fois où les deux étaient efficace, le rêve. Je ne pense pas qu'orienté objet ou procédural soit le facteur le plus important dans la réussite d'un projet. Ce n'est même pas le second ni le troisième. L'expérience des développeurs et la conduite de projet par exemple sont bien plus important. Ça rend difficile d'évaluer ces deux méthodes à partir d'un retour d'expérience.

[Neckara]

J'ai pris l'habitude, ça coute 10 minutes, et je ne créais pas ce genre de fonctions tous les jours, non plus. Sur des applis de 10, 20, 30 ans d'âge, on passe beaucoup plus de temps en maintenance. Sur les nouvelles, c'était mon standard. Rapport cout-bénéfice généralement immédiat.

Si tu as du code existant, il est normal de le réutiliser. Tu ne vas pas t'amuser à réécrire le même code en moins optimisé si tu en a déjà un qui marche très bien .

De toute évidence, on a pas le même vocabulaire. [...] je parle d'optimisations simples et qui restent lisibles. Si vous appelez ça "bonnes pratiques", ma foi, je prends.

Toutes les optimisations ne sont pas nécessairement des optimisations prématurées. Je te parle bien d'optimisation prématurées.

En soit, c'est presque une tautologie de dire que les optimisation prématurées sont mauvaise, l'aspect "mauvais" étant déjà dans l'adjectif "prématuré".

Sauf si ce que tout le monde appelle "standard" est, de facto, dans votre définition, un dogme.

? De quelle définition qui serait mienne parles-tu ?

Revenons au niveau business. On a deux doctrines, on doit en choisir une, et on en a une qui est plus performante si on trouve des gens de qualité, et l'autre qui fait moins de dégats si on trouve des médiocres.

Je ne suis déjà pas d'accord avec cette hypothèse. Pour moi rien ne permet d'affirmer cela.

Si tu es peu compétent, peu importe le langage, tu pisseras du code dégueulasse quelque soit le paradigme.

Je sais que je parle à un prof, alors ma réponse va sans doute être très, très mal perçue, mais...la qualité de la formation est une illusion. Enfin, jusqu'à un certain point. De nombreuses personnes n'ont pas la tournure d'esprit(je ne parle ni d'intelligence ni de potentiel ni de qualités, hein, juste de tournure d'esprit) pour faire un code correct. On peut leur donner le meilleur prof de l'univers, elles n'y arriveront jamais. Ça se mesure, hein.

Je dirais plutôt que la formation est de qualité, mais que la sélection par les examen est pourri (on fait passer tout le monde).

À noter aussi que les meilleurs élèves partent à l'étranger, font des thèses, ou lancent leur propre start up. Et les mauvais, tu les retrouves dans les SS2I "prédactrices" (?) qui vont coder plus plusieurs clients, ils sont donc beaucoup plus visibles. Encore pire si les entreprises se les refilent entre elles (i.e. fait un mois à gauche, un mois de chômage, etc.).

C'est le mien aussi - il faut connaitre tous les outils dans la boite à outils, et utiliser ceux qu'on a sans se poser de question - si ce n'est celle de l'utilité. Savoir si c'est du pur stylé? Si c'est maintenable et performant, honnêtement, la pureté du style, je m'en cogne. Il faut que ça marche, et que les gens qui passent derrière puissent maintenir. La qualité attendue des gens qui passeront derrière est donc un critère vital de choix - rien à voir entre mon éditeur de logiciels actuel, et les banques ou je traînais avant.

Je suis d'accord qui faut choisir les bons outils.
Mais cela ne signifie pas que ce soit de la faute à la POO. La faute est ici à l'incompétence des utilisateurs qui fait que tu ne peux pas utiliser la POO si l'utilisateur n'est pas assez compétent. Mais cela n'est pas un réel problème de la POO, mais de la formation des utilisateurs.

Sachant qu'il ne faut pas aussi confondre POO et langages. On peut utiliser des sous-ensembles de langages pour coder plus simplement, tout en conservant une approche POO. I.E. ne pas utiliser toutes les fonctionnalités du langage.

[foetus]

Je ne pense pas qu'orienté objet ou procédural soit le facteur le plus important dans la réussite d'un projet

Moi, je pense qu'avec la POO, c'est plus facilement de sandboxer les développements. Si le développeur fait de la m*rd*, il n'y aura quasi que sa brique qui posera problème.
C'est d'ailleurs, pour cela que les juniors sont capables de travailler : ils n'ont pas besoin de comprendre l'existant, juste savoir comment faire une brique logicielle.

Parce que le procédural, a quand même tendance à partir en plat de spaghettis 1) la prise en main n'est pas évidente 2) il faut un minimum de compétences pour ne pas couler le code.

[Rizzen]

C'est pile poil ce que je reproche aux dirigeants d'équipes de devs... et ce que je reproche aux devs de laisser faire. Et j'ajouterais aussi le gros problème des agences dans la stratégie "à quoi bon faire les choses proprement, maintenables, évolutives, etc., sachant que ceux qui feront la version suivante, ce sera sans doute un autre, sinon, au pire, on refacturera plein pot."

Mais, vraiment, côté développeurs, trop nombreux sont ceux qui n'osent pas dire "stop, on ne fait pas ça", quand un truc n'est pas raisonnable/légal/propre/sécurisé/... et se contentent de faire ce qu'on leur dit, alors que C'EST NOTRE EXPERTISE, si ce n'est pas nous qui y mettons un halte-là, qui va le faire ?

Entièrement d'accord avec toi, et j'ai trop souvent eu ce débat avec les équipes pour faire comprendre que chacun est responsable de ce qu'il produit et que si il estime que ce n'est pas bon, il faut dire stop, que cela plaise ou non.

[Lcf.vs]

Entièrement d'accord avec toi, et j'ai trop souvent eu ce débat avec les équipes pour faire comprendre que chacun est responsable de ce qu'il produit et que si il estime que ce n'est pas bon, il faut dire stop, que cela plaise ou non.

Perso, je vais même plus loin (à vrai dire, elle est d'un chef de projet que j'ai eu) :

Chacun est aussi responsable de ce qu'il voit et laisse passer, car pas mandaté pour, par exemple.

Laisser passer un truc pas sécure, pas propre, etc., c'est donner son aval à ce qui a été fait, dès lors, on est tout aussi responsable de ce qu'a fait l'auteur.

[pboulanger]

La POO n'est qu'un paradigme de programmation parmi tant d'autres... C'est un outil utile pour certaines tâches et inadapté pour d'autres... Il faut utiliser l'outil adapté au besoin...

[el_slapper]

(.../...)Mais il s'agit de problèmes organisationnels, pas de programmation. Si on veut comparer orienté objet et procédural, il faudrait que ce soit dans des conditions similaires.
(.../...)

D'ou ma conclusion : "ça dépend". Ca dépend d'un tas de paramètres, et les gens qu'on a à disposition sont un paramètre très important. Si dans ton monde les gens qui font de l'objet sont des cadors et les gens qui font du procédural des ânes, pourquoi se faire chier avec du procédural? Je tenais juste à dire que l'inverse existait aussi - et que donc l'objet comme choix par défaut me paraissait bien dogmatique, comme position.

Si tu as du code existant, il est normal de le réutiliser. Tu ne vas pas t'amuser à réécrire le même code en moins optimisé si tu en a déjà un qui marche très bien .

Cas vécu : du code de 36 ans d'âge, qui marche très bien, et qui est inmaintenable. Et il faut faire des maintenances. La décision n'est pas facile, je te garantis. Il est très tentant de tourner autour et de mettre des rustines en amont ou en aval. Ce qui empire encore la situation. D'un autre coté, si on refond, le risque tant coté métier que coté performances est massif. On a refondu, mais avec des moyens massifs de test systématiques(on faisait tourner un mois complet de prod, et j'avais fait un outil de comparaison données par donnée - ça a ramené un nombre invraisemblable de bugs).

Je ne suis déjà pas d'accord avec cette hypothèse. Pour moi rien ne permet d'affirmer cela.

Si tu es peu compétent, peu importe le langage, tu pisseras du code dégueulasse quelque soit le paradigme.

Ben, le discours que j'ai entendu de la plupart des jeunes diplômes était "objet bien, reste caca". Ca me semble être un biais assez fort dans nombre de formations.

Je dirais plutôt que la formation est de qualité, mais que la sélection par les examen est pourri (on fait passer tout le monde).

ce qui revient au même, juste vu par l'autre bout de la lorgnette : la formation est de qualité, mais tout le monde n'a pas le niveau pour mériter de passer. Et passe quand même.

À noter aussi que les meilleurs élèves partent à l'étranger, font des thèses, ou lancent leur propre start up. Et les mauvais, tu les retrouves dans les SS2I "prédactrices" (?) qui vont coder plus plusieurs clients, ils sont donc beaucoup plus visibles. Encore pire si les entreprises se les refilent entre elles (i.e. fait un mois à gauche, un mois de chômage, etc.).

Là, tu prêches un convaincu - encore qu'on trouve pas mal d'affabulateurs en startup aussi. Nettement moins qu'en SSII, certes, mais il y en a. Sinon, 100% d'accord. des gens que la SSII replace tous les deux mois, qui se font virer de chez tous les clients, mais jamais de leur SSII, j'en ai vu plus d'un.

Je suis d'accord qui faut choisir les bons outils.
Mais cela ne signifie pas que ce soit de la faute à la POO. La faute est ici à l'incompétence des utilisateurs qui fait que tu ne peux pas utiliser la POO si l'utilisateur n'est pas assez compétent. Mais cela n'est pas un réel problème de la POO, mais de la formation des utilisateurs.

En gros d'accord, là aussi. J'irais plus loin que la formation, et je parlerais du niveau global de compétences(qui englobe un tas de trucs, donc évidemment la formation), mais sinon, on est d'accord. Sauf que ça marche aussi sur le procédural. On a mis sur le dos du procédural les faiblesses des gens qui en faisaient. Pour pouvoir vendre la soupe "objet". (c'est exactement pareil entre waterfall et agile, des gens intelligents qui savent tordre leur waterfall pour s'adapter et éviter l'effet tunnel, ça existe, mais on met les echecs sur le dos de la méthode plutôt que des gens - et je suis plutôt partisan de l'agile)

L'auteur du blog trouve des défauts à l'objet, défauts dont il existe des solutions, que les gens compétentes connaissent et appliquent. Le procédural, c'est pareil. C'est tout ce que je voulais dire. Les gens sont plus importants que les méthodes.

[onilink_]

Perso j'aime bien la POO, mais avec modération.

Au début de mon projet, je sortais de l'école ou on apprenait à faire de l'UML et utiliser de la POO à toutes les sauces.
Résultats, j'ai commencé mon jeu bourré de POO pour utiliser de la POO, et à de nombreux endroits j'ai fait de l'héritage et du polymorphisme plutôt que de la simple composition, ce qui a posé de nombreux problèmes par la suite.

Le soucis à mon avis ce n'est pas la POO, c'est la façon dont on la vend: tout doit être OO partout (ou faire semblant de l'être)! Y a qu'a voir Java qui ont pris ça un peu trop au pied de la lettre au point ou on encapsule Main dans une classe
Forcement, ceux qui ont fait les frais d'un trop plein de POO vont maintenant la critiquer... quitte à généraliser et sortir des choses absurdes.

[Pyramidev]

La POO n'est qu'un paradigme de programmation parmi tant d'autres... C'est un outil utile pour certaines tâches et inadapté pour d'autres... Il faut utiliser l'outil adapté au besoin...

De mon côté, je vois l'héritage de la POO comme une fonctionnalité bancale qu'on n'utiliserait presque jamais si on travaillait avec des langages mieux conçus que ceux qui sont connus dans l'industrie.

Je copie-colle un extrait d'un message que j'avais écrit il y a deux mois :

L'héritage de la POO version Java a les inconvénients suivants :

• On mélange deux concepts qui auraient dû être séparés : les mixins et le polymorphisme. Pour rappel, conceptuellement, un mixin, c'est une sorte d'héritage sans sous-typage : si une classe A utilise un mixin B, alors A récupère automatiquement tout le contenu de B, mais l'utilisateur de A ne sait pas que ce contenu vient de B. B ne sert qu'à factoriser du code. Les mixins sont moins verbeux que l'encapsulation. On peut les utiliser avec parcimonie. Il ne faut pas en abuser, sinon, on se retrouve avec des classes qui ont une longue liste de méthodes éparpillées dans plein de fichiers différents, dont des méthodes qu'elles n'auraient pas dû avoir. Les mixins risquent de rigidifier le code, donc ce concept n'aurait pas dû être mélangé à du sous-typage qui rigidifie le code encore plus.
• La POO version Java impose que, dans le code d'une classe ou d'une interface, il faut connaître la liste exhaustive des types parents. L'une des conséquences est que cela empêche de combiner deux types abstraits a posteriori : il faut soit éditer le code de ces deux types abstraits pour qu'ils dérivent d'un même nouveau type, soit passer par des wrappers.
• La POO version Java a un polymorphisme qui repose sur le sous-typage, ce qui affaiblit le typage et limite les possibilités d'effectuer des contrôles rigoureux lors de l'analyse statique du code.
  Par exemple, si une fonction prend deux paramètres et retourne une valeur, en pure POO, on ne peut pas restreindre à la compilation le type du deuxième paramètre en fonction du premier et on ne peut pas restreindre le type de retour en fonction des deux autres types. On peut en programmation générique, mais pas en pure POO.
  Autre exemple : si un langage contrôle à la compilation quels types d'erreurs une fonction peut retourner et si une fonction est pure, alors, quand on écrit du code réutilisable avec des callbacks, on a rapidement besoin de pouvoir faire ce genre de chose : soit f une fonction qui prend en paramètre une callback et qui ne peut pas avoir d'effets de bord autres que ceux de la callback. Quand on sait que la callback est pure alors on sait que l'appel de f pour cette callback-là est pur. Et quand on sait que la callback peut lancer des erreurs X et Y, alors on sait que l'appel de f pour cette callback-là pourra lancer des erreurs X et Y. Java n'a pas été conçu pour que le compilateur sache propager ce genre de contrôle dans un contexte de polymorphisme. C'est pourquoi les checked exceptions sont un échec en Java et qu'il n'y aura probablement jamais de contrôles sur les fonctions pures dans les futures versions du langage.

La POO version Java a au moins un avantage : il n'y a pas de polymorphisme accidentel. Quand on veut modifier le code, on sait différencier assez facilement les fonctions spécifiques à une classe des fonctions liées à d'autres classes par un type parent commun. Ce n'est pas comme le duck typing avec lequel il est parfois périlleux de renommer une méthode.

Mais il n'y a pas besoin de la POO pour avoir cet avantage. Avec les typeclasses de Haskell et les traits du Rust, on évite aussi le polymorphisme accidentel et on n'a aucun des 3 inconvénients cités ci-dessus.

Par contre, si on se limite aux langages connus dans l'industrie, alors l'héritage peut sembler un bon choix, car les langages ne fournissent pas toujours d'autres fonctionnalités plus efficaces pour faire du polymorphisme.

[gl]

Moi, je pense qu'avec la POO, c'est plus facilement de sandboxer les développements. Si le développeur fait de la m*rd*, il n'y aura quasi que sa brique qui posera problème.
C'est d'ailleurs, pour cela que les juniors sont capables de travailler : ils n'ont pas besoin de comprendre l'existant, juste savoir comment faire une brique logicielle.

Tu n'as besoin de l'OO pour ça, une forme de modularité suffit amplement.

[BugFactory]

Par exemple, si une fonction prend deux paramètres et retourne une valeur, en pure POO, on ne peut pas restreindre à la compilation le type du deuxième paramètre en fonction du premier et on ne peut pas restreindre le type de retour en fonction des deux autres types.

La surcharge de méthode ne permet-elle pas de faire ça?

Si dans ton monde les gens qui font de l'objet sont des cadors et les gens qui font du procédural des ânes, pourquoi se faire chier avec du procédural?

Si on force des "ânes" en procédural à faire de l'objet, ça fera des ânes en objet et vice-versa. Et je te trouve un peu dur. J'ai rarement vu des ânes, comme tu dis. Du code catastrophique pondu par des juniors non encadrés? Tout le temps.

[gl]

Par contre, si on se limite aux langages connus dans l'industrie, alors l'héritage peut sembler un bon choix, car les langages ne fournissent pas toujours d'autres fonctionnalités plus efficaces pour faire du polymorphisme.

Je regrette de ne pas pouvoir plussoyer plusieurs fois ce message !


Je pense que tu mets le doigt sur les plus importants problèmes (au moins de mon point de vue) :

• Le manque de diversité dans les fonctionnalités proposés par la plupart des langages mainstream. C'est d'ailleurs une des raisons pour laquelle j'ai une préférence pour des langages plus "boîte à outil" comme C++ et Python, et que je regrette souvent l'absence de fonctionnalités présentes ailleurs.
• Le manque de curiosité de certains développeurs (malheureusement très nombreux) qui ne sortent que peu de leur langage de prédilection ou de langages assez proches. Je trouve ça assez triste d'autant que voir ce qui se fait ailleurs aide aussi à avoir un meilleur code chez nous (oui, je suis convaincu qu'étudier Lisp, Erlang, Haskell, Prolog, Forth ou Self aide à produire du meilleur Java, C++ ou PHP).

[BugFactory]

Moi, je pense qu'avec la POO, c'est plus facilement de sandboxer les développements. Si le développeur fait de la m*rd*, il n'y aura quasi que sa brique qui posera problème.
C'est d'ailleurs, pour cela que les juniors sont capables de travailler : ils n'ont pas besoin de comprendre l'existant, juste savoir comment faire une brique logicielle.

Parce que le procédural, a quand même tendance à partir en plat de spaghettis 1) la prise en main n'est pas évidente 2) il faut un minimum de compétences pour ne pas couler le code.

En théorie, l'objet permet de sandboxer, en effet. En théorie, un senior décide de l'architecture, crée des interfaces et laisse les juniors les implémenter. En pratique, les juniors sont lachés seuls sur un nouveau projet. Les mêmes développeurs qui font des erreurs sont aussi ceux qui introduisent des couplages forts et créent des problèmes structurels à l'échelle de toute l'application. Et c'est APRES qu'on m'appelle à la rescousse... Bref, l'avantage technique est comme d'habitude perdu pour des économies de bouts de chandelles.

Je trouve que la programmation objet est en fait bien pratique pour le débogage et le refactoring du plat de spaghetti. Le simple fait de pouvoir mettre un point d'arrêt dans un setter aide énormément. Avoir les traitements liés aux données limite les endroits où on doit chercher.

Pour en revenir à l'article initial, l'auteur note que la POO dévie l'attention des dévs de la résolution des problèmes. C'est vrai, mais ce n'est pas un bogue, c'est une fonction. Avec l'expérience, j'ai remarqué qu'une approche "model driven" fonctionne mieux avec la POO. Une fois qu'on a bien réfléchi au modèle de données, les différentes couches de l'application s'empilent assez naturellement. Il est assez facile d'écrire du code réutilisable dans ce cas. Ce n'est pas forcément le cas avec la programmation procédurale, où en se concentrant sur une tâche à la fois, on aboutit trop facilement à un code monolithique et non réutilisable, et à copier coller du code d'une fonction à une autre. Ce n'est certes pas le cas de code procédural bien conçu, mais c'est plus facile de faire du code objet bien conçu. Mais en objet, il ne faut pas tant penser aux tâches à résoudre qu'à un domaine applicatif à modéliser. C'est une approche TRÈS contre-intuitive pour un esprit humain, et difficile à appréhender sans expérience. Quand j'étais débutant, je trouvais la programmation procédurale bien plus compréhensible. Il a fallu que je me force pour maîtriser l'objet.

[el_slapper]

(.../...)Si on force des "ânes" en procédural à faire de l'objet, ça fera des ânes en objet et vice-versa. Et je te trouve un peu dur. J'ai rarement vu des ânes, comme tu dis. Du code catastrophique pondu par des juniors non encadrés? Tout le temps.

Je force un peu le trait, mais pas tant que ça; citons Neckara, qui est aux premières loges :

Je dirais plutôt que la formation est de qualité, mais que la sélection par les examen est pourri (on fait passer tout le monde).

Donc il y a des gens qui ne font pas l'affaire sur le marché. Pour tout un tas de raisons(en particulier les biais de recrutement, mais aussi des niveaux d'exigence différents suivant les endroits), ils ne sont pas équitablement répartis, mais on les trouve au contraire en grumeaux, en gros paquets. Ma conclusion n'est pas qu'il faut les reconvertir(ce qui, comme tu le soulignes fort justement, serait catastrophique). Ma conclusion est qu'il ne faut pas s'en servir du tout.

[psykokarl]

En théorie, l'objet permet de sandboxer

Oui l'objet permet en théorie de sandboxer ... comme n'importe quel paradigme. L'important est de pouvoir isoler les variables d'entrées qui permettent d'anticper le comportement un sous ensemble de code sans avoir à s'intéresser au détail de l'implémentation. L'objet le permet mais ne l'impose pas (loin de la). A contrario avec de la rigueur on peut faire du code propre avec du gosub voir du goto. L'objet est un facilitateur mais il n'est pas le seul et il ne dispense pas de la connaissance des bonnes pratiques qui elles sont transcourantes.
Comme vous l'avez judicieusement remarquer, éviter le couplage fort entre des bouts de code que l'on veut indépendant est l'une de ces bonnes pratiques.
Du code procedural monolitique bien structuré permet de shunter une sous-procédure en deux lignes et de la remplacer par n'importe quel bout de code ayant la meme morphologie. Le jeu de la composition d'objet oblige parfois à faire de la spéléo. Il suffit de cacher quelques jeux de references cycliques dans ce dédale est on est obligé de faire touner le code avec des valeurs d'entrée (dont on ignore évidement la valeur) afin de trouver le bug/comment ca marche.

Pour en revenir à l'article initial, l'auteur note que la POO dévie l'attention des dévs de la résolution des problèmes.C'est vrai, mais ce n'est pas un bogue, c'est une fonction.

Le souci est que coder en objet est une chose, structurer son code en est une autre. De temps a autre, il arrive de devoir faire un setter avec un code de qui tient sur 200 lignes. Evidement ca fait gueuler sonar et il faut envisager de peter une archi ntiers bien ficellée parce que 200 lignes+, ca fait trop procédural.
Par manque de temps, il faut donc créer les sous methodes validationPartie1, validationPartie2 ... validationPartieN (en esperant ne pas dépacer le nombre de méthodes limite par classe). On se retrouve avec n méthodes parfaitement modulaires mais totalement inutile si utilisées séparément ou pas dans le bon ordre. Par sur qu'on y gagne au change...

Une fois qu'on a bien réfléchi au modèle de données, les différentes couches de l'application s'empilent assez naturellement. Il est assez facile d'écrire du code réutilisable dans ce cas. Ce n'est pas forcément le cas avec la programmation procédurale, où en se concentrant sur une tâche à la fois, on aboutit trop facilement à un code monolithique et non réutilisable, et à copier coller du code d'une fonction à une autre. Ce n'est certes pas le cas de code procédural bien conçu, mais c'est plus facile de faire du code objet bien conçu. Mais en objet, il ne faut pas tant penser aux tâches à résoudre qu'à un domaine applicatif à modéliser.

C'est le noeud du problème. Le temps de reflexion en amont minoré par l'apport de l'expérience pour ceux qui en ont peut faire la différence, mais ce temps est un luxe. Pour le reste, il faut clairement faire la différence entre le paradigme du langage qui facilite un type de représentation et l'agencement des briques de code qui releve de l'architecture. Par exemple, il est faux de dire que l'objet permet de moins penser au taches a résoudre pour se concentrer sur d'avantage sur l'applicatif. C'est la structure du code qui le permet. Les taches a résoudre sont souvent prise en charge par le framework et il arrive d'avoir à créer des taches a résoudre malgré que l'on code en objet. L'important est justement de différencer quand le code résout une tache et donc on doit étendre le framework de quand le code permet une mise en oeuvre purement applicative et doit permettre une reactivité pour contenter un client qui a la caractéristique de ne pas trop savoir ce qu'il veut. En dépit des outils qu'il offre, l'objet seul ne dit pas comment faire la différence.
L'objet ne sauve du copier coller. Si on copie colle des fonctions en procédural, en objet on copie colle des classes ... et dans les deux cas, gare au code mal néttoyé. Quelqu'un qui sait coder de façon structurer le fera aussi facilement en objet qu'en procédural.
Quelque part, le procédural permet de reperer plus facilement celui qui sait structurer son code. Le procédural à pour caractéristique de ne rien cacher et surtout pas la misère. L'objet cache mieux la misère mais ne la suprime pas forcément...

[walfrat]

Pour reprendre ce qui a été dis sur le fait que dans du procédural, tu peux te contenter de mettre à jour un module et pas tout retester le système, je pense que tu as surtout un client qui a une culture très différente des miens.

Déjà : en Java, tu peux découper tes développements en plusieurs JAR et donc potentiellement en mettre un jour un seul (et tu peux même les mettre dans le serveur plutôt que le WAR pour pas relivrer un WAR complet).

Mais je vois déjà très peu de développeur intéressé par faire ça, comme dise certain, parce qu'ils n'ont sans doute pas ce qu'il faut pour être un développeur qui fait son boulot correctement, mais d'autres parce qu'ils ont simplement été habitué qu'aujourd'hui dans le monde professionnel, il est difficile de justifier à sa hiérarchie et son client autre chose que développer des nouvelles fonctionnalités, besoin technique ? Passer du temps à refactorer un code existant pour supporter une nouvelle fonction ? Beaucoup de temps de validation pour une fonction qui semble simple mais est par nature laborieuse à tester ? Dur.

[Jamatronic]

Est-ce une grosse erreur de considérer la POO comme standard de l'industrie pour l'organisation des bases de code ?

Non, ce n'est pas du tout une erreur, puisqu'il y a trop de développeurs qui n'ont vraiment pratiqué que cela.

[oooopppp]

Bonjour à tous,
Perso, la poo en PHP m'a tellement gonflée qu'en fait je m'en sert juste pour grouper des fonctions public static que je range dans des classes au nom logique et ce qui est cool c'est que je peux appeler ces fonctions dans n'importe quelle autre classe au besoin, bon vous allez peut être dire que je fais de la merde mais grâce à un autoloader qui me charge toutes mes classes à l'index et bien j'enchaîne assez rapidement de grosses applications, qui sont fiables sans bug et le client est content car les délais et les prix sont très bas. Pour preuve, je viens de coder un système de vente en ligne multi vendeurs avec chaque son propre paiement par CB et le tout en Ajax et en ... 1 mois et une semaine, ça fonctionne bien, pas de bug et le code est super maintenable, d'ailleurs je compte le faire évoluer en travaillant sur un clone, c'est simple, clair, ça fonctionne et si demain qqun reprends mon code, ça sera clair pour lui ! En même temps je me suis mis à apprendre Java et bien sûr je mange bien de l'héritage et de l'encaps. je sent déjà que ça va être chiant au possible, comme apprendre 36 langage ... L'informatique est décidément très illogique, beaucoup trop complexe et dispersée chaqun a bien fait sa tambouille dans son coin et c'est tout pourrit ... Franchement ça aurait été sympa de se poser 5 minutes et de collaborer ? Quand je vois Facebook avec react et Google avec angular j'ai qu'une envie c'est de claquer la tête de l'un contre l'autre en espérant leur faire rentrer un peu de plomb dans la tête !