Discussion :

[Pyramidev]

J'avais oublié de répondre sur ce point :

La programmation fonctionnelle a un côté "esthétique" indéniable, et c'est très bien si on en reste à des fonctions "simples". Mais dès qu'il faut faire des accès en bases, des I/O, enfin des trucs qui font vraiment des choses, cela ne relève plus du monde des fonctions. Et pourtant, c'est indispensable pour une "vraie" application.

Dans un style le plus fonctionnel possible, on gère les effets de bord par des callbacks. Par exemple, pour pouvoir lire la base de données, il faut passer au moins une callback de paramètre en paramètre, d'une fonction de haut niveau jusqu'à la fonction qui appellera effectivement cette callback.

On garde alors les bénéfices des fonctions pures :

• Les dépendances de chaque fonction sont explicites. Pour savoir de quoi dépend le comportement d'une fonction, on regarde la liste des paramètres en entrée.
• Les tests unitaires sont faciles à écrire.

[koala01]

Salut,

Je n'ai pas lu toutes les interventions, il y aura donc sans doute des redites...

Je crois, pour ma part, que le problème n'est pas ** forcément ** à chercher au niveau de la POO en elle-même, mais bien au niveau de la mauvaise compréhension des concepts qui la soutiennent.

A commencer sans doute par le concept même de paradigme, dont wikipedia indiquait à l'époque qu'il s'agit

de rails dont il est dangereux de s'écarter, car cela occasionne des catastrophes

Le texte ayant changé depuis, j'ai fait cette citation de tête, et peut-être pas repris les termes exacts.

Mais combien de développeurs sont encore intimement persuadés qu'il est dangereux de s'écarter du paradigme qu'ils ont décidé d'utiliser Pire encore : combien de langages fournissent le moyen correct d'intégrer correctement les différents paradigmes

Or, le fait est que certains langages (je pense notamment à C++) nous démontrent tout le contraire, en nous permettant de mélanger allègrement les trois paradigmes pourtant distincts que sont

• le paradigme procédural pur
• le paradigme orienté objets
• le paradigme générique

Juste après la notion de paradigme, j'aurais tendance à citer la notion d'encapsulation parmi celles qui sont -- à tout le moins -- très souvent mal comprises:

Combien de développeur sont, encore à l'heure actuelle, persuadés d'encapsuler parfaitement leurs données en fournissant un code ressemblant à

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
class MaClasse{
public:
    /* il faut sans doute d'autres fonctions qui pourraient être nécessaires*/
    void setX(int newX){
        x = newX;
    }
    int getX() {
        return x;
    }
private:
    int x;
}

(avec les adaptations éventuelles au langage utilisé)

Qu'on se le dise : ce code représente beaucoup de choses, mais ce n'est absolument pas un exemple correct d'encapsulation! L'encapsulation devrait nous faire réfléchir à l'interface de nos classes en termes de services rendus de manières à ce que tous les calculs et vérifications nécessaires soient effectués par les différentes fonctions qui seront appelées.

Assez paradoxalement, l'encapsulation n'est même pas un concept limité à la POO : dés que le langage propose certains mécanismes susceptibles d'éviter à l'utilisateur d'un agrégat de donnée (une structure, une classe ou un enregistrement, selon le nom qu'on lui donn) connaitre la manière dont les données sont organisées "en interne", la notion d'encapsulation devient possible.

La structure FILE du langage C en est le parfait exemple : on dispose de "tout ce qu'il faut" pour pouvoir la manipuler à son aise, alors que très peu de gens savent exactement de quelle données elle est composées (pire : sa composition a de fortes chances de varier en fonction du système sur lequel elle est utilisée).

Un accesseur (la fonction getX() ) peut, dans certains cas, correspondre à un service rendu par la classe, mais les mutateur (la fonction setX(int newX)) ne devrait pas exister, car elle oblige l'utilisateur de la classe à effectuer lui-même les différents calculs et vérifications pour déterminer la nouvelle valeur de x. Au risque qu'il se trompe lors du calcul, ou qu'il oublie de vérifier l'une ou l'autre des règles imposées par la classe.

Un exemple correct d'encapsulation serait d'avantage proche de

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class Point{
public:
    /* il faut sans doute d'autres fonctions qui pourraient être nécessaires*/
    void move(int diffX, int diffY){
        /* on vérifie que la position à atteindre est "cohérente" et accessible */
        x+= diffX;
        y+= diffY;
    }
    int getX(){
        return x;
    }
    int getY(){
        return y;
    }
private:
    int x;
    int y;
}

Le troisième point souvent mal compris -- quand il n'est pas purement et simplement ignoré par de nombreux développeurs -- est d'avantage un principe qu'un concept. Je veux parler du principe de substitution de Liskov.

Combien de développeurs utilisant la POO n'en ont-ils même jamais entendu parler Combien de fois ai-je vu un développeur java ouvrir de grands yeux lorsque je lui en parlais Combien de développeurs java n'ont pas conscience d'utiliser le même principe lorsqu'ils décide d'extends une classe ou qu'ils décident d'implement une interface

Pire encore : parmi ceux qui disent le connaitre, combien de développeurs ne le comprennent-ils décidément que très mal

Je me souviens d'une très longue discussion dans la section C++ dans laquelle j'essayais de convaincre des développeurs pourtant chevronnés que ce n'est pas parce que le compilateur accepte quelque chose que le principe en question est respecté; que ce principe devait être respecté avant même que l'on décide de tracer la relation d'héritage dans shéma UML, ou d'écrire la moindre ligne de code.

Le temps a passé depuis, et pourtant, combien de développeurs seraient encore près à me contredire à ce sujet

Enfin, je dois reconnaitre un point comme correct: la POO n'est en aucun cas la panacée. Il y a de nombreux domaines dans lesquels la POO pose plus de problèmes qu'elle n'en résout.

Une approche Data Driven, avec une séparation claire des comportements et des données est souvent bien préférable; et l'immutabilité facilite énormément la tache du développeur pour toute une série d'agrégats de données.

Ce n'est, finalement, pas pour rien que l'on fait, en C++, la distinction entre les types de données qui ont sémantique de valeur et ceux qui ont sémantique d'entité.

Le problème étant -- encore une fois -- que trop de langages orientés objets interdisent au développeur de s'écarter du paradigme en question

[nyx86]

Bonjour à tous,

Ce sujet est passionant !

Cela fait 14 années que je suis dév, dans ma carrière j'ai mangé beaucoup de Symfony, beaucoup de Magento, de gros modèles OO pertinents, mais je reviens de plus en plus souvent aux fondamentaux dans les projets sur lesquels j'interviens, je fais également du machine learning en python et la première chose qui apparait est cette absence de tartine de design patterns à tout va ..

Quand le but des développeurs est d'implémenter tous les design patterns possibles et immaginable au sein d'un projet, qui résulte en une centaine de fichiers éclatés en un MVC avec des appels cycliques récursifs qui prend une semaine à comprendre / débugger, quand ta stack trace compte déjà plus de 100 éléments, que tu recherches désespérément ou aurait été setté une variables parmis 30k objets générés pour le simple affichage d'un page, qu'il te faut à minima 2 heures pour lancer les tests unitaires que tu ne peux lancer sans reproduire un agglomérat objet regroupant une commande avec des produits une adresse etc .. que tu peux reproduire par un simple json, pour une action qui pourrait être menée par un script bash + php me parait une dépense inutile de temps et de ressources humaines.

Je me suis mis à dos un jour mon DT, contraint à démissioner pour avoir simplement exposé le fait aux users qu'il était possible d'implémenter une spec plus rapidement afin de la tester et valider dans les meilleurs délais, puis ensuite découpler le code une fois validé, c'était selon lui "innacceptable et hérétique".

En tant qu'indépendant on me parachute souvent sur des projets qui ont acculé un retard de plusieurs mois voir années afin d'implémenter des solutions plus directes .. Ce qu'apprécie particulèrement les clients, vu que cela coûte moins cher et peut réduire la charge serveur par 10. En prouvant ceci il est assez étonnant d'avoir l'approbation d'autres développeurs qui me disent " C'est ce qu'on pense depuis le départ, mais on est contraint à toujours respecter toutes les guidelines et obéir au DT "..

Je pense que tant qu'un développeur / directeur n'a pas été confronté à de fortes contraintes de budget / temps, personne ne considérera que la simplification d'un code est le garant du succès d'un projet.

Je ne partisan d'aucun paradigme, chacun apporte des solutions à des problématiques données.
Beaucoup de développeurs ignorent qu'ils font du fonctionnel / procédural au sein de leurs méthodes je trouve toujours cela toujours assez surprennant. Notamment lorsqu'un dev Java arrive sur son premier projet en php, il débarque avec ses habitudes, ses convictions .. C'est un peu comme passer de PHP à Javascript .. on y découvre moins de contraintes .. et cela déstabilise les gens qui défendent leur language / framework de base comme leur religion / leur sainte mère .. et c'est dommage de manquer à ce point d'ouverture ..

La Poo est bonne chose que l'on n'en abuse pas à tord et à travers, c'est puissant, mais tout comme pour les pratiques ( DevOps => Kubernetes || Openshift ), cela permet également d'industrialiser certaines erreurs afin d'en faire de belles catastrophes qui impactent beaucoup de personnes - surtout pour une prod qui tombe car le code consomme trop de ressources par rapport à ce qui lui est attribué, mais ceci est un autre débat

[Mat.M]

après ce dernier, cet état de choses résulte de la nécessité que l’approche orientée objet impose de se focaliser sur la notion d’abstraction et les nombreux modèles de conception.

la notion d'abstraction je dirai que c'est à 95% le problème des projets informatiques.
C.a.d que d'une personne à l'autre on ne conçoit pas forcément les choses de manière identique.

Ensuite le danger des objets mutables c'est de de définir des objets indéfinis
Ca.d que si on modifie les attributs d'une classe d'objet on risque de tourner en rond plus qu'autre chose

Justement, la problématique soulevé ici c'est de dire qu'il est plus compliqué en POO de ne pas finir par faire une usine à gaz.

bonjour je crois que je l'ai écris sur ce forum le risque avec la POO c'est de faire du code "lasagne" c.a.d qu'on empile des codes d'objet contrairement au code spaghetti où le code part dans tous les sens avec un langage procédural
Ensuite par principe lorsque l'on conçoit une classe c'est dans un mécanisme d'abstraction et l'abstraction de l'abstraction cela finit par mener à l'ensemble vide

[el_slapper]

(.../...)La Poo est bonne chose que l'on n'en abuse pas à tord et à travers, c'est puissant, mais tout comme pour les pratiques, cela permet également d'industrialiser certaines erreurs (.../...)

Si j'avais encore de la place dans ma signature, j'ajouterais ça. +1000. C'est comme tout, c'est un outil.

Bonjour je crois que je l'ai écris sur ce forum le risque avec la POO c'est de faire du code "lasagne" c.a.d qu'on empile des codes d'objet contrairement au code spaghetti où le code part dans tous les sens avec un langage procédural

Tiens, ça aussi, d'ailleurs. On peut faire du procédural propre, simple efficace - comme de l'objet, d'ailleurs. Mais ça nécessite de comprendre ce que l'on fait.

Ensuite par principe lorsque l'on conçoit une classe c'est dans un mécanisme d'abstraction et l'abstraction de l'abstraction cela finit par mener à l'ensemble vide

https://blog.codinghorror.com/it-cam...-architecture/

Patterns and practices are certainly good things, but they should always be framed in the context of a problem you're solving for the users. Don't succumb to the dark side.

Ce qui revient à ce qu'on m'a appris en école d'ingénieur(industrie, pas informatique) - il faut toujours faire une analyse de la valeur. Comparer le coût de ce que l'on va faire avec la valeur ajoutée. Il m'arrive fréquemment de rajouter des surcouches d'architecture, ce qui rend mon collègue dingue, mais je me suis toujours posé la question avant de savoir pourquoi je faisais ça. Et je ne me le permets que quand je sais que le code sera largement réutilisé. Quand c'est à usage unique, ben, une solution rapide - comme mon collègue les adore - est généralement le meilleur choix, en termes de coût-service-maintenabilité.