Discussion :

[Patrick Ruiz]

La POO n’est pas meilleure que la programmation fonctionnelle et vice versa, d’après Dave Farley
D’avis que c’est au programmeur de choisir le paradigme qui convient le mieux au problème à résoudre

Il existe une panoplie de manières d’aborder la programmation informatique. Dans le jargon du milieu, on parle de paradigme de programmation. En incluant celui dit impératif, on répertorie à minima trois grandes familles et leurs dérivés. Certaines de ces approches font quasiment office de norme dans l’actuelle industrie de la programmation informatique. C’est par exemple le cas de la programmation orientée objet dont l’usage prédominant dans la filière peut laisser penser qu’il s’agit d’une meilleure approche que la programmation fonctionnelle. Des intervenants de renom de la filière comme Dave Farley sont d’avis qu’aucun de ces paradigmes n’est supérieur à l’autre et qu’il revient au programmeur de choisir celui qui convient le mieux au problème à résoudre.

La programmation orientée objet consiste en la définition et l’interaction de briques logicielles appelées « objets. » Un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait interagir avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ; l'interaction entre les objets via leurs relations permet de concevoir et réaliser les fonctionnalités attendues, de mieux résoudre le ou les problèmes.

La programmation fonctionnelle pour sa part peut être considérée comme l'opposé de la programmation orientée objet. Les objets encapsulent un état interne ainsi qu'une collection de méthodes qui permettent de modifier cet état. Les programmes consistent à appliquer les bons changements à ces états. La programmation fonctionnelle impose d'éviter au maximum ces changements d'états en travaillant sur des données qui traversent un flux de fonctions.

« Ma position n'est pas que je déteste la programmation fonctionnelle et que j'aime la POO ou vice versa, mais plutôt que je considère chacune de ces approches comme des outils plutôt que comme des sujets de débats futiles », déclare Dave Farley.

La sortie de Dave Farley fait pourtant suite à des développements antérieurs qui suggèrent de passer à l’approche fonctionnelle

En effet, à mi-parcours de l’année 2019, Ilya Suzdalnitski de l’entreprise Replicon affirmait que « considérer la programmation orientée objet comme standard de l’industrie pour l’organisation des bases de code est, pour lui, une grosse erreur. » Son développement laissait filtrer que l’usage de la programmation orientée objet dévie l’attention des développeurs de ce qui doit la retenir : la résolution des problèmes. « L’approche orientée objet introduit plus de complexité que l’inverse surtout pour des bases de code importantes », avait-il souligné avant d’ajouter qu’ « il est difficile d’écrire du code orienté objet aisé à maintenir, les tests unitaires sont difficiles à appliquer à une base de code montée suivant l’approche orientée objet, le refactoring de code est une vraie galère sans des outils comme Resharper. »

L’ingénieur de Replicon avait insisté sur ceci que la racine des maux avec la POO telle que pratiquée via des langages comme Java ou C# est qu’elle n’est pas implémentée telle qu’Alan Kay l’a conçue. « On n’aurait jamais dû parler de concepts comme l’héritage, le polymorphisme ou avoir à traiter avec une myriade de patrons de conception », avait-il souligné. Ilya Suzdalnitski accusait les langages phares du moment de mettre en avant une POO qui ne s’aligne pas sur la définition originelle de l’encapsulation et sur la communication par messages entre programmes indépendants.

« En Erlang, on pratique la programmation orientée objet sous sa forme la plus pure. À l’inverse des langages de programmation phares, Erlang s’appuie sur l’idée centrale de la POO – les messages. Dans ce langage, les objets communiquent via des messages immuables », avait-il indiqué.

Au travers de cet exemple, l’ingénieur de Replicon suggérait que programmation fonctionnelle et programmation orientée objet « pure » sont une seule et même chose. En droite ligne avec ce détail, il avait surtout mis en avant la supériorité de la programmation fonctionnelle vis-à-vis de la POO telle que pratiquée avec Java, C#, C++ et autres.

« Le but ultime de tout développeur de logiciel devrait être d'écrire du code fiable. Rien d'autre n'a d'importance si le code est bogué et peu fiable. Et quelle est la meilleure façon d'écrire un code fiable ? Simplicité. La simplicité est le contraire de la complexité. Erlang est probablement le langage le plus fiable au monde. La majeure partie de l'infrastructure mondiale des télécommunications (et donc de l'Internet) s'appuie sur ce dernier. Certains des systèmes écrits en Erlang ont une fiabilité de 99.999999999 % », avait-il insisté.

« L’on est quelque part au milieu d’une transition du style programmation orientée objet vers celui dit fonctionnel », estime Richard Feldman. « Des langages de programmation comme Kotlin prennent à la fois la programmation orientée objet et celle dite fonctionnelle en charge. C’est quelque chose que vous n’auriez pas vu dans une FAQ du langage Java dans les années ‘90. En fait, de plus en plus de langages mettent en avant le support du style fonctionnel en avant comme argument de vente. Les développements en cours laissent penser que de plus en plus d’acteurs de la filière sont d’accord que l’approche fonctionnelle est bonne », ajoute-t-il.

Il y a quelques mois, l’étude « Emploi développeur 2022 » est parue sur cette plateforme. En tête de liste des langages les plus demandés et les mieux payés, on retrouve Java. Sa première présentation officielle s’est faite le 23 mai 1995 au SunWorld comme langage de programmation structuré, impératif et orientée objet. C’est Java 8 (sorti en 2014) qui est venu mettre les développeurs qui font usage de ce langage de programmation sur les rails du style fonctionnel au travers des expressions lambdas. En fait, la remarque de Feldman vaut pour bon nombre de langages de cette enquête dvp pour lesquels on note que de plus en plus de livres orientés programmation fonctionnelle paraissent.

Source : Dave Farley

Et vous ?

POO ou fonctionnel : lequel des paradigmes a eu le plus d’influence sur vous ? Pour quelles raisons ?
Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
Voyez-vous l'impact de l'approche fonctionnelle s'étendre au point qu'elle s'impose comme une norme ?
Votre expérience des tests unitaires et du refactoring de code a-t-elle souvent été pénible sur des bases de code montées en s’appuyant sur l’approche orientée objet ? Si oui, pourquoi ?
Partagez-vous l’avis selon lequel la gestion des états est plus complexe avec la POO qu’avec l’approche fonctionnelle pour des bases de code importantes ?

Voir aussi :

La programmation orientée-objet est-elle dépassée ? Une école en sciences informatiques l'élimine de son programme d'introduction
Faut-il éviter de distraire les débutants avec l'orientée objet ?
Comment pourriez-vous expliquer l'orienté objet ? Steve Jobs a essayé d'expliquer ce concept

[Ryu2000]

POO ou fonctionnel : lequel des paradigmes a eu le plus d’influence sur vous ? Pour quelles raisons ?

Le développement orienté objet est le paradigme qui a le plus d'influence sur moi, parce que c'est qu'on retrouvait le plus souvent à l'école.
Cela dit on a fait de la programmation fonctionnelle avec le langage "Scheme" (je me rappelle qu'il y avait beaucoup de parenthèses ouvrantes et de parenthèses fermantes).

J'aimais beaucoup le langage Java est en Java tout est objet.
En développement orienté objet il est plus simple de faire des diagrammes UML.

[eric44000]

Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?

L'approche fonctionnelle est réputée pour avoir une complexité moindre que l'OO. Mais on pourrait le dire également entre l'OO (C++) et l'impératif (C). Et parfois entre le C et l'assembleur (bien que les compilateurs C soient très performants).

Mais il arrive aussi (et c'est très souvent le cas) que la complexité ne soit pas rédhibitoire. Et si c'était le cas, rien n'empêche de programmer en OO et de faire une application fonctionnelle pour la partie critique (certains langages sont même multiparadigme).

Donc vouloir faire du paradigme fonctionnel un standard, oui mais pas à cause de la complexité. L'argument premier est la sécurité du code. Reste que la majorité du code est écrit en OO et que cela demande beaucoup de personnel pour le maintenir.

[OuftiBoy]

L'approche fonctionnelle est réputée pour avoir une complexité moindre que l'OO. Mais on pourrait le dire également entre l'OO (C++) et l'impératif (C). Et parfois entre le C et l'assembleur (bien que les compilateurs C soient très performants).

J'aime bien le concept de la POO, sur le papier, ça semble être une bonne solution. Mais au fil des années, force est de constater qu'elle engendre des sources imbuvables et incompréhensibles. La notion d'héritage fait qu'on se retrouve avec des couches et couches d'abstractions, et cela devient vite très lourd à comprendre. Je répète souvent d'on "lit" 100x plus un code source qu'on "écrit" ce dernier. Si on veut essayer de garder le contrôle, il faut:
- Programmer pour des interfaces
- préférer la composition à l'héritage

L'encapsulation, n'est pas non plus vraiment un plus, ça complexifie plus que ça n'aide. Avant, en programmation structurée, on avait des fonction du genre open(&file) où file était une "structure" et maintenant on fait file.open() où file est on "objet". Il ne serait jamais venu à quelqu'un l'idée de faire sqrt(&File) (calculer la racine carrée d'un nombre). L'encapsulation n'apporte pas vraiment un plus, on "lie" les data avec les fonctions qui peuvent les utiliser, donc on crée une "class", et arrive vite les soucis de l'héritages.

Le polymorphisme et/ou la surcharge des opérateur, ça ne rend pas non plus le code plus clair. Quand on lit un source et qu'on tombe sur un "a = a + b" (a et b étant des objets), on ne sait pas dire exactement ce que fait le "+". Il faut connaître les couches en dessous pour comprendre.

Je n'ai rien contre la POO, mais il faut qu'elle soit extrêmement bien appliquée. Et tout le monde sait qu'on a pas toujours le temp de bien penser les choses.

Mais il arrive aussi (et c'est très souvent le cas) que la complexité ne soit pas rédhibitoire. Et si c'était le cas, rien n'empêche de programmer en OO et de faire une application fonctionnelle pour la partie critique (certains langages sont même multiparadigme).

Il faut bien distinguer la complexité d'un problème de la complexité de la solution de ce problème. Avec la notion "d'héritage", il y le biais qu'on essaye de "prévoir" dès le début comment le problème va évoluer, et très vite on se retrouve avec des couches sur des couches. Je tente de m'en tenir au concept KISS.

Donc vouloir faire du paradigme fonctionnel un standard, oui mais pas à cause de la complexité. L'argument premier est la sécurité du code. Reste que la majorité du code est écrit en OO et que cela demande beaucoup de personnel pour le maintenir.

La sécurité du code est certes très importante, mais cette sécurité ne doit pas être obtenue via un complexité inutile du code source, car quand le code source devient imbuvable, on a plus de risque d'introduire des problèmes de sécurité.

Ma petite conclusion:

Quelque soit le langage ou son paradigme, il faut surtout savoir ce qu'on fait, pourquoi on le fait, pourquoi on le fait d'une manière ou d'une autre, et le faire le plus simplement possible. Pour qu'un programme puisse évoluer en toute quiétude, il faut avant tout que son code source reste lisible et compréhensible le plus facilement possible.

BàV. Et Peace & Love.

[eric44000]

Il faut bien distinguer la complexité d'un problème de la complexité de la solution de ce problème. Avec la notion "d'héritage", il y le biais qu'on essaye de "prévoir" dès le début comment le problème va évoluer, et très vite on se retrouve avec des couches sur des couches. Je tente de m'en tenir au concept KISS

Tout à fait, la complexité que Dave Farley parle est différente de la complexité que vous évoquez avec les couches et surcouches de la POO. Encore que je ne trouve pas que les notions d'héritage soient complexes. Je la verrai plutôt dans les design patterns (quoique tout s'apprend). Un des arguments de la POO par rapport à au paradigme impératif était que la POO évitait le "Spaghetti code" qui lui était vraiment compliqué.

En fait, la POO évite la complexité avec UML mais complique tout avec les méthodes agiles. D'ailleurs SCRUM conseille de réécrire le code constamment pour entre autre éviter de complexifier l'architecture.

[denisys]

OuftiBoy
Le 01/08/2024 à 14:13
J'aime bien le concept de la POO, sur le papier, ça semble être une bonne solution. Mais au fil des années, force est de constater qu'elle engendre des sources imbuvables et incompréhensibles.

Sauf si tu lit la documentation technique !
Au fait , la méthodologie dite : SCUM .
Elle inclue combien de temps , dans l'entretien et la rédaction de la documentation technique ?

[OuftiBoy]

Tout à fait, la complexité que Dave Farley parle est différente de la complexité que vous évoquez avec les couches et surcouches de la POO. Encore que je ne trouve pas que les notions d'héritage soient complexes.

La notion d'héritage n'est pas complexe en elle-même, mais son utilisation peut vite, elle, devenir complexe.

Je la verrai plutôt dans les design patterns (quoique tout s'apprend). Un des arguments de la POO par rapport à au paradigme impératif était que la POO évitait le "Spaghetti code" qui lui était vraiment compliqué.

Les "Design Patterns" ne sont qu'une compilation de "bonnes pratiques", sur lesquels on a posé un "formalisme". Je pense que tout le monde a plusieurs fois utilisé un "Design Pattern" sans même s'en rendre compte. Suivant le langage utilisé, certains de ces "Design Pattern" sont complétement inutiles, car les fonctionnalités du langage peut permettre de s'en passer. L'excès d'applications de ces "Design Patterns" peut vite rendre les choses plus compliquées que nécessaire. Il m'arrive aussi souvent de voir passer du code qui a abusé des ces "Design Patterns", alors qu'une solution plus simple aurait pu suffire.

Puisqu'on par cuisine , La POO aide à éviter du code "Spaghetti" , mais on se retrouve avec une "lasagne" . Ma préférence, ce sont les "raviolis" .

En fait, la POO évite la complexité avec UML mais complique tout avec les méthodes agiles. D'ailleurs SCRUM conseille de réécrire le code constamment pour entre autre éviter de complexifier l'architecture.

Si on doit trop souvent "refactoriser", c'est que le problème à traiter n'était pas clairement définit à la base, ou qu'on l'a mal compris, ou que le client l'a mal exprimé, ou qu'on a tenté de "prédire" l'avenir. Je laisse à Madame Irma le soin de prédire l'avenir, moi j'en suis incapable .

Il est plus facile de refactoriser un code bien clair et modulaire (mes raviolis) qu'un code "Spaghetti" ou "Lasagne".

Concernant UML, j'avoue que je ne suis pas fan. C'est bien souvent à cause de ces UML qu'on produit du code avec trop d'abstractions ou rempli de cas inutiles pour le problème posé. Avec l'expérience, on voit vite si ce que l'on nous demande a bien été réfléchit ou pas. Il m'arrive de laisser passer quelques réunions avant de commencer quoi que ce soit. Je laisse les choses se "décanter" d'elles mêmes.

Un des problème que l'on rencontre souvent, c'est que les besoins ne sont pas exprimés par les utilisateurs (celui qui utilise le programme au final), mais par un intermédiaire, qui a souvent une vision moins "terre à terre", ce qui n'aide pas à garder les choses le plus simple possible.

BàV et Peace & Love.

[OuftiBoy]

Sauf si tu lit la documentation technique !

Malheureusement la "documentation technique" est souvent encore plus imbuvable que le code source . Si le code source reste clair, simple, limpide, il n'y a pas besoin de "documentation technique", qui, en plus, n'est bien souvent pas/plus mise à jour au fil de l'avancement d'un projet . La meilleur "documentation technique" est selon moi le code source en lui-même .

Au fait , la méthodologie dite : SCUM .
Elle inclue combien de temps , dans l'entretien et la rédaction de la documentation technique ?

Tout comme je ne suis pas fan d'UML, je ne suis pas fan de "Méthodologie". Je suis plutôt adepte du "Bon sens". Le problème des "Méthodologies", c'est un peut le même que celui d'UML, ou des "Design Patterns". A trop suivre des règles, on emprunte souvent des chemins plus compliqués que nécessaire, ce que je tente d'éviter au maximum .

Perso, je tiens à jour, en collaboration avec mon "client" (souvent mon chef de projet), un document où se trouve "ce qu'on a fait", "pourquoi on l'a fait" et "comment on l'a fait". Quand le projet évolue, on met à jour ce document ensemble (avant de modifier la moindre ligne de code), qui permet de garder à jour une "spécification" bien plus utile qu'une "documentation technique".

Mais ceci n'est que mon avis. Je ne prétend pas avoir de solution miracle. C'est mon expérience qui m'a mené à faire les choses ainsi. D'autres ont certainement d'autres besoins, dépendant de la nature du projet, j'en suis bien conscient.

Cette même expérience m'a fait conclure que le plus important, c'est de garder un code source clair et le plus simple possible.

BàV et Peace & Love.

[walfrat]

Malheureusement la "documentation technique" est souvent encore plus imbuvable que le code source . Si le code source reste clair, simple, limpide, il n'y a pas besoin de "documentation technique", qui, en plus, n'est bien souvent pas/plus mise à jour au fil de l'avancement d'un projet . La meilleur "documentation technique" est selon moi le code source en lui-même .

Tout comme je ne suis pas fan d'UML, je ne suis pas fan de "Méthodologie". Je suis plutôt adepte du "Bon sens". Le problème des "Méthodologies", c'est un peut le même que celui d'UML, ou des "Design Patterns". A trop suivre des règles, on emprunte souvent des chemins plus compliqués que nécessaire, ce que je tente d'éviter au maximum .

Perso, je tiens à jour, en collaboration avec mon "client" (souvent mon chef de projet), un document où se trouve "ce qu'on a fait", "pourquoi on l'a fait" et "comment on l'a fait". Quand le projet évolue, on met à jour ce document ensemble (avant de modifier la moindre ligne de code), qui permet de garder à jour une "spécification" bien plus utile qu'une "documentation technique".

Heu, alors l'UML , les design pattern, ne sont pas des méthodologie pour moi, ce sont des outils pour répondre à un problème, et certains en font une méthodologies de "toujours plier ton problème pour que ça rentre dans un design pattern". Bref il y a beaucoup de monde pour qui le but c'est d'éviter d'avoir du "bon sens", autrement dit de réfléchir.

L'usage des design pattern, c'est justement du pur bon sens : "il répond entièrement à mon problème, je l'utilise, sinon je vais devoir adapter, voir faire autrement.

Personnellement de mon côté, le plus gros manque ne sont pas des documentations techniques pour commenter le code une fois produit, mais des spécifications/prérequis techniques qui permettent de structurer la démarche du développeur, et qui mèneront à des développeurs différents à une résultat de code pour le même genre d'élément techniques relativement proche.

[OuftiBoy]

Heu, alors l'UML , les design pattern, ne sont pas des méthodologie pour moi, ce sont des outils pour répondre à un problème, et certains en font une méthodologies de "toujours plier ton problème pour que ça rentre dans un design pattern". Bref il y a beaucoup de monde pour qui le but c'est d'éviter d'avoir du "bon sens", autrement dit de réfléchir.

Je me suis surement mal expliqué. L'UML et les "Design Patterns", je ne les vois pas non plus comme des "Méthodologies", mais bien comme des outils. Ce que je n'aime pas, c'est comme vous le dites, qu'on en abuse pour "plier" pour que ça rentre dans les clous, alors que des solutions plus existe, en réfléchissant un peu.

L'usage des design pattern, c'est justement du pur bon sens : "il répond entièrement à mon problème, je l'utilise, sinon je vais devoir adapter, voir faire autrement.

Oui, c'est du bon sens, mais ça ne doit pas être utilisé pour être utilisé, si un moyen plus simple existe, je ne dis rien de plus. Il ne faut pas arriver à ce que l'on sorte un canon pour tuer une mouche.

Personnellement de mon côté, le plus gros manque ne sont pas des documentations techniques pour commenter le code une fois produit, mais des spécifications/prérequis techniques qui permettent de structurer la démarche du développeur, et qui mèneront à des développeurs différents à une résultat de code pour le même genre d'élément techniques relativement proche.

Oui, le début est parfois difficile, car souvent on ne sait pas où on va. C'est pourquoi je tente de "temporiser", de laisser se décanter les choses avant de débuter vraiment.

BàV et Peace and Love.

[Mat.M]

Je me suis surement mal expliqué. L'UML et les "Design Patterns", je ne les vois pas non plus comme des "Méthodologies", mais bien comme des outils.

je pense que les design patterns et UML ont été crée dans un esprit "d'industrialisation " d'un projet informatique.
Bref ne pas réinventer à chaque fois la roue.
Pour ça on regarde si on a pas des objets modulaires en stock et on les réutilise ça évite de perdre son temps à faire du code supplémentaire.
Donc oui on peut parler d'outils.

[SQLpro]

et surtout garder en tête que si l'on accède à une base de données, ce qui est le cas de 99 % des applications, aucune base de données n'est réellement objet ni même orientée objet.... Donc se rajoute le problème d'impédance entre le monde objets et les base de données a eut pour résultat de créer de nouvelles couches d'interface imbitables (ORM, Frameworks....) qui vautrent les applications et les rendent hyper lentes...

Il y a longtemps, j'avais écrit cet article pour "le monde informatique"... Il revient d'actualité !0
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

A +

[SQLpro]

...J'aimais beaucoup le langage Java est en Java tout est objet....

Non, c'est aussi un langage OO (orienté objet). On y trouve des scalaires (nombre, chaines de caractères et des opérateurs sur ces scalaires. Un des rares langage purement objet est Small Talk


A +

[Ryu2000]

On y trouve des scalaires

Ouais ok, on peut dire qu'en Java il y a les objets et les types primitifs. (et il existe des classes qui correspondent aux types primitifs, comme int et Integer)

Bon apparemment depuis 2015 il y a moyen de faire de la programmation fonctionnelle avec Java, il y a une histoire de lambda.
Je ne me suis pas tenu à jour au niveau de Java.
Ça va être chiant si un jour je passe un entretien pour un poste de développeur Java.
J'étais un peu près à jour en 2014.

[esperanto]

Déjà faudrait savoir de quoi on parle. Est-ce que je fais nécessairement de la programmation fonctionnelle quand j'utilise des lambdas en Java? Pour ma part, oui quand je les imbrique dans des map et autres collect (mais même là ce n'est que partiellement du fonctionnel car on peut modifier le contenu des variables), mais pas quand je les utilise dans la gestion des événements, comme implémentation d'un ActionListener par exemple: là, je considère le lambda comme juste une expression plus simple (et plus efficace semble-t-il) que les classes anonymes, mais ça reste fondamentalement une implémentation du design pattern Stratégie, comme c'était le cas avec les classes anonymes d'ailleurs.

A l'inverse je n'ai pas vraiment l'impression de programmer "objet" quand un framework Java m'impose l'utilisation de POJO et que toutes les méthodes intelligentes sont reléguées dans des DAO et autres » services » à l'implémentation unique: dans un tel cas il y a certes héritage mais pas de polymorphisme, et pour moi la programmation objet, c'est bien le deuxième point qui est important, plus que le premier! Combien de fois j'ai vu des DAO dont les méthodes contenaient des cascades de IF juste parce qu'il fallait surtout rien faire dans les POJO...

Les design patterns, rien contre tant que le mot design indique qu'on désigne un principe indépendamment du langage. Par contre si ça revient à prendre au pied de la lettre les exemples fournis dans la documentation d'un framework, sans chercher à comprendre pourquoi ils ont utilisé telle variable plutôt qu'une autre, ne venez pas vous plaindre ensuite de voir votre travail "piqué" par les méchantes IA, parce que ce qu'on attend d'elles, c'est qu'elles respectent leur code à la lettre sans réfléchir, ce qui ne devrait pas être votre cas. A vous de voir....

Avant, en programmation structurée, on avait des fonction du genre open(&file) où file était une "structure" et maintenant on fait file.open() où file est on "objet". Il ne serait jamais venu à quelqu'un l'idée de faire sqrt(&File) (calculer la racine carrée d'un nombre)

Non mais il pourrait vouloir écrire open(socket) comme il le ferait sur un fichier, et là, pas sûr qu'un langage non-objet accepte cela sans broncher. Alors que socket.open() le langage va juste vérifier si la classe socket a bien la bonne méthode, qui n'est pas forcément la même que celle pour un fichier. Encore une fois, la POO ce n'est pas que l'héritage, mais aussi le polymorphisme!

L'encapsulation, n'est pas non plus vraiment un plus, ça complexifie plus que ça n'aide.

Si l'encapsulation c'est juste écrire objet.X() plutôt que objet.x, sans qu'il ne soit autorisé de faire autre chose dans la méthode X() qu'un bête "return x", alors je suis d'accord. Les POJO pour moi, n'ont d'objet que le nom. Par contre décider si ça n'est pas dangereux d'exposer la variable x, éventuellement juste en lecture, c'est ça l'encapsulation. Si on prend la mauvaise définition, forcément ça complexifie.

et surtout garder en tête que [...] aucune base de données n'est réellement objet ni même orientée objet.... [...] a eut pour résultat de créer de nouvelles couches d'interface imbitables (ORM, Frameworks....) qui vautrent les applications et les rendent hyper lentes...

A qui la faute? Ce sont vos amis DBA qui ont tout fait pour démolir à coup de benchmarks truqués les tentatives de bases de données objet formalisées par feu l'organisme ODMG. Dans le même temps, aucune base SQL n'a su correctement implémenter le modèle relationnel-objet qui était prévu par SQL 3 (pas d'héritage de tables en Oracle ou Sybase, et pas d'héritage de types dans Postgresql). Dommage, le modèle relationnel-objet n'était pas mauvais. Et ensuite ça vient se plaindre que les gens utilisent des ORM (et pourtant je suis d'accord avec vous sur le côté imbitable des ORM, mais pour ce qui est des responsabilités...)

[Invité]

là, je considère le lambda comme juste une expression plus simple (et plus efficace semble-t-il) que les classes anonymes, mais ça reste fondamentalement une implémentation du design pattern Stratégie, comme c'était le cas avec les classes anonymes d'ailleurs.

Je me permets d'ajouter cette petite compilation de critiques de l'excellent refactoring.guru dans laquelle apparait ta critique .

Je profite de cette source pour ajouter qu'en effet, les Design Pattern sont des outils à la structuration, mais pas seulement !

[OuftiBoy]

Non mais il pourrait vouloir écrire open(socket) comme il le ferait sur un fichier, et là, pas sûr qu'un langage non-objet accepte cela sans broncher. Alors que socket.open() le langage va juste vérifier si la classe socket a bien la bonne méthode, qui n'est pas forcément la même que celle pour un fichier. Encore une fois, la POO ce n'est pas que l'héritage, mais aussi le polymorphisme!

Avec n'importe quel langage "strong typed", l'erreur sera découverte à la compilation. L'Héritage, c'est pas la panacée. comme je disais plus haut, on remplace les spaghettis par des lasagnes. Je préfère programmer pour des interface, et l'encapsulation n'apporte rien. Le modèle POO de Python est bien mieux que le modèle POO de C++. Il faut privilégier la composition à l'héritage.

Si l'encapsulation c'est juste écrire objet.X() plutôt que objet.x, sans qu'il ne soit autorisé de faire autre chose dans la méthode X() qu'un bête "return x", alors je suis d'accord. Les POJO pour moi, n'ont d'objet que le nom. Par contre décider si ça n'est pas dangereux d'exposer la variable x, éventuellement juste en lecture, c'est ça l'encapsulation. Si on prend la mauvaise définition, forcément ça complexifie.

Je n'ai jamais touché à Java, les "POJO", je ne sais même pas ce que c'est . Mais en Python, on résout le problème par convention. Tout ce qui commence par un underscore ("_") ne doit pas être utilisé directement en écriture. C'est du simple bon sens. Et ça évite de devoir faire des getter/setter inutiles. Mais si besoin on peut en faire. Je trouve que laisser simple ce qui l'est est une bonne pratique.
Lier les données aux fonctions dans une classe (encapsulation), n'apporte rien, que du contraire. Même la STL du C++ ne le fait pas, il doit y avoir une raison .

Quant au polymorphisme, ça n'apporte pas grand chose. Faire obj += x au lieu de obj.add(x), ou add(obj, x), bof, pas grande utilité.

A qui la faute? Ce sont vos amis DBA qui ont tout fait pour démolir à coup de benchmarks truqués les tentatives de bases de données objet formalisées par feu l'organisme ODMG. Dans le même temps, aucune base SQL n'a su correctement implémenter le modèle relationnel-objet qui était prévu par SQL 3 (pas d'héritage de tables en Oracle ou Sybase, et pas d'héritage de types dans Postgresql). Dommage, le modèle relationnel-objet n'était pas mauvais. Et ensuite ça vient se plaindre que les gens utilisent des ORM (et pourtant je suis d'accord avec vous sur le côté imbitable des ORM, mais pour ce qui est des responsabilités...)

Les ORM sont juste une abomination. On tente de fusionner 2 principes. Il suffit d'une simple couche d'abstraction pour passer d'un objet à la DB ou l'inverse. Les ORM ne font que compliqué les choses.

Attention hein, je n'ai rien pour ou contre la POO, c'est juste un paradigme parmi d'autres.

BàV. et Peace & Love.

[Bousk]

Toutes les quelques années un nouveau guru crie que machin est mieux que truc dans tel cas alors que truc est mieux que bidule dans tel autre et qu'il faut savoir faire la part des choses.
Pourquoi donner autant d'attention à un énième enfonceur de portes ouvertes ?

[Madmac]

Les ORM sont juste une abomination. On tente de fusionner 2 principes. Il suffit d'une simple couche d'abstraction pour passer d'un objet à la DB ou l'inverse. Les ORM ne font que compliqué les choses.

L'intérêt des ORM est que vos n'êtes pas captif à une base de donnée spécifiquement. Par exemple, pouvez passez à MySQL à PostgreSQL sans trop d'effort grâce au ORM. Les besoin d'une entreprises changent au fil des années.

Personnellement, je préfère le prix de cette complication, que de devoir repartir de zéro.

[OuftiBoy]

L'intérêt des ORM est que vos n'êtes pas captif à une base de donnée spécifiquement. Par exemple, pouvez passez à MySQL à PostgreSQL sans trop d'effort grâce au ORM. Les besoin d'une entreprises changent au fil des années.

Personnellement, je préfère le prix de cette complication, que de devoir repartir de zéro.

Je ne peux qu'être d'accord "en théorie" avec vous sur le principe, mais (y'a toujours un mais) dans la vie réel, complexifier les choses avant que cela ne soit nécessaire, c'est souvent la porte ouverte à des usines à gaz. Et si... ajoutons cela, et si... ajoutons cela, etc.

Il me semble qu'il doit y avoir un juste milieux.

- Par exemple, ajouter la couche ORM avant de basculer sur une autre base de donnée, ce n'est pas repartir de zéro.
- De même, s'il y a une simple couche pour faire la translation entre le monde "Objet" et le monde "Base de donnée relationnel", il ne devrait y avoir qu'une partie de cette couche qu'il faudra éventuellement adapter. Si dans cette couche, on utilise du SQL standard pour lire/écrire les objets dans la base de donnée, le changement de base de donnée ne devrait pas poser trop de soucis.
- De ce que j'en sais, tous les ORM ne supportent pas forcément toutes les BD de la même manière. Si l'ORM choisit ne supporte pas de la même manière les 2 BD, la complexité ajoutée par l'ORM choisit au départ vas forcément complexifier le passage d'une DB à l'autre.

Je ne suis pas un spécialiste dans ce domaine, et je ne prétend pas avoir "la vérité", mais j'utilise toujours, quelque soit la solution à apporter à une demande, de m'en tenir au principe KISS. Dites moi si je me trompe, mais "DB relationnel + ORM" == "DB objet". De ce que que j'en sais, les "BD objet" n'ont pas connus un grand succès.

Mais, comme dit ci-dessus, je ne suis pas un spécialiste en la matière, et si je peux apprendre de ce débat, j'en serais ravi .

Merci de votre contribution,

BàV et Peace & Love.