Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #121
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 047
    Points : 4 482
    Points
    4 482
    Par défaut
    J'avais oublié de répondre sur ce point :
    Citation Envoyé par yahiko Voir le message
    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.

  2. #122
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 336
    Points : 28 719
    Points
    28 719
    Par défaut une mauvaise compréhension des concepts, quand ce n'est pas une ignorance
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #123
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2015
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Associations - ONG

    Informations forums :
    Inscription : mai 2015
    Messages : 33
    Points : 99
    Points
    99
    Par défaut
    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

  4. #124
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 997
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 997
    Points : 15 807
    Points
    15 807
    Par défaut
    Citation Envoyé par Patrick Ruiz Voir le message
    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



    Citation Envoyé par Edrixal Voir le message
    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
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  5. #125
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 062
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 062
    Points : 28 052
    Points
    28 052
    Par défaut
    Citation Envoyé par nyx86 Voir le message
    (.../...)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.

    Citation Envoyé par Mat.M Voir le message
    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.

    Citation Envoyé par Mat.M Voir le message
    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/

    Citation Envoyé par Jeff Atwood
    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é.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Discussions similaires

  1. Microsoft exhorte le gouvernement britannique à ne pas imposer ODF comme standard
    Par Hinault Romaric dans le forum Logiciels Libres & Open Source
    Réponses: 18
    Dernier message: 28/02/2014, 11h27
  2. ECMA International adopte JSON comme standard
    Par Stéphane le calme dans le forum Actualités
    Réponses: 10
    Dernier message: 22/10/2013, 01h12
  3. Yahoo! considère toujours Bing comme un concurrent
    Par Katleen Erna dans le forum Actualités
    Réponses: 3
    Dernier message: 26/08/2009, 04h47
  4. [E07] Produit considérant les blancs comme "zero"
    Par BME2411 dans le forum Excel
    Réponses: 10
    Dernier message: 15/01/2009, 11h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo