IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Débats sur le développement - Le Best Of Discussion :

Faut-il éviter d'utiliser des classes et s’appuyer autant que possible sur une approche fonctionnelle ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    2 070
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 2 070
    Points : 56 129
    Points
    56 129
    Par défaut Faut-il éviter d'utiliser des classes et s’appuyer autant que possible sur une approche fonctionnelle ?
    Faut-il éviter d'utiliser des classes et s’appuyer autant que possible sur une approche fonctionnelle ? Un point de vue d'Andy Peterson
    Basé sur son expérience en entreprise avec Typescript

    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 du paradigme orienté objet sur lequel il est possible de s’appuyer en Typescript qui, comme d’autres langages, donne également la possibilité de faire usage de l’approche fonctionnelle.

    Dans une publication parue il y a peu, Andy Peterson de l'entreprise Atomic Object explique pourquoi il ne fait pas un usage systématique des classes et s’appuie autant que possible sur une approche fonctionnelle. En fait, il s’agit d’une posture globale de l’équipe de développeurs de l’entreprise spécialisée en développement web, mobile, desktop et dispositifs matériels : programmation fonctionnelle à la place de la POO lorsque possible.

    L’un des principaux aspects qui oppose programmeurs orienté objet et fonctionnels est celui de la gestion de la propriété des objets au sein des bases de code – la notion d’état. Grosso modo, l’avis d’Andy Peterson tiré de son expérience dans l’écosystème Typescript est que l’approche fonctionnelle rend plus simple la gestion des états que la POO. Ce dernier s’aligne sur celui d’Ilya Suzdalnitski – ingénieur en informatique chez Replicon – qui souligne que la gestion des états est plus complexe avec l’approche orientée objet surtout pour des bases de code importantes.

    Nom : Andy peterson.png
Affichages : 22172
Taille : 94,6 Ko
    Andy Peterson

    « L’état en lui-même est assez inoffensif. La grosse difficulté naît avec ceux dits mutables surtout s’ils sont partagés. Le cerveau humain est la machine la plus puissante de l'univers. Cependant, nos cerveaux sont vraiment piètres au jeu de la gestion des états. Il est beaucoup plus facile de raisonner au sujet d'un morceau de code si vous pensez seulement à ce que celui-ci fait et non aux variables qu'il modifie au sein de la base de code. Programmer avec des objets mutables s'apparente à de la jonglerie mentale. Je ne sais pas ce qu'il en est de vous autres, mais moi je pourrais jongler avec deux balles. Donnez-moi trois balles ou plus et je les lâcherai toutes. Pourquoi donc essayons-nous d'accomplir cet acte tous les jours au travail ? Malheureusement, la gestion des objets mutables est au cœur même de la programmation orientée objet. Le seul but de l'existence de méthodes sur un objet est de pouvoir modifier ses propriétés », soulignait-il à mi-parcours de l’année précédente.

    D’après l’ingénieur de Replicon 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 », souligne-t-il. Ilya Suzdalnitski accuse 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.

    Richard Feldman (l’auteur de « Elm in Acrion ») est d’avis que « l’on est quelque part au milieu d’une transition du style programmation orientée objet vers celui dit fonctionnel. » « 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 2018 » 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.

    Nom : functional.png
Affichages : 7394
Taille : 242,3 Ko

    « C’est le signe que quelque chose a changé des années ‘90 à nos jours. L’approche fonctionnelle attire de plus en plus d’acteurs de la filière. Ce n’est plus qu’une question de temps pour la voir s’imposer », a conclu Feldman.

    Source : billet de blog

    Et vous ?

    Partagez-vous l’avis selon lequel la POO introduit plus de complexité que l’inverse pour des bases de code importantes ?
    Quelle est votre expérience avec l’approche fonctionnelle ? Introduit-elle moins de complexité que l’approche orientée objet ?
    Partagez-vous l’avis selon lequel l’approche fonctionnelle finira par s’imposer comme norme ?

    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

  2. #2
    Membre expérimenté
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mai 2019
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mai 2019
    Messages : 485
    Points : 1 385
    Points
    1 385
    Par défaut
    "lorsque possible"

    Bah en JS c'est tout le temps possible, c'est juste que, est-ce raisonnable ?

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Décembre 2009
    Messages
    14
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2009
    Messages : 14
    Points : 69
    Points
    69
    Par défaut retour vers le passé
    Avec le cloud, on recentralise tout dans des serveurs, comme sur les mainframes
    Avec le retour de la programmation fonctionnelle, on redécoupe tout en fonction

    bienvenu dans le monde des années 70

  4. #4
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 667
    Points : 3 814
    Points
    3 814
    Par défaut
    Le nom de "Ilya Suzdalnitski" mentionné ici m'a rappelé quelque chose quand je l'ai lu. Il me semblait déjà l'avoir vu quelque part sur DVP. Après recherche, je suis tombé sur ces deux articles :

    Deux articles où il y a des évangélistes de la programmation fonctionnelle qui disent que la programmation fonctionnelle c'est mieux que la POO. On se demande bien pourquoi.

    Et c'est encore pareil ici. Allez-y si vous avez envie de rapartir dans un débat "fonctionel ou objet ?" de plusieurs pages comme pour les deux autres articles (respectivement 7 et 11 pages).

  5. #5
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    Mai 2015
    Messages
    429
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2015
    Messages : 429
    Points : 1 631
    Points
    1 631
    Par défaut
    Avec le cloud, on recentralise tout dans des serveurs, comme sur les mainframes
    @xbrossard
    Sauf qu'appart la couche de donné, tous le travail est fait de plus en plus côté client avec HTML5.
    Bon, forcement la validation, l'auth, ...etc côté serveur, mais il faut bien qu'il serve à quelque chose .

    Avec le retour de la programmation fonctionnelle, on redécoupe tout en fonction
    @xbrossard
    Et en objet on redécoupe tout en classes, méthodes, accesseurs, ...etc et il faut tout un framework de test avec Mock et compagnies pour tester ne serait-ce qu'une petite classe isolé.
    C'est pas forcement pertinent de devoir sortir le bazooka pour dégommer une mouche.

    Enfin, concrètement, un dev s'adapte à la problématique du moment.
    Si le fonctionnel répond mieux à ses besoins, tant mieux si le langage l'y autorise.
    Si l'OO répond mieux au problème, alors banco.
    Par contre, dans tous les cas il va devoir découper sont problème en sous problèmes et donc en bloc fonctionnel que ce soit en impératif, fonctionnel ou objet.
    Si sont langage de prédilection lui laisse plus d’amplitude, c'est plutôt une bonne nouvelle de mon point de vue.
    Et puis bon, si vous manipulez de la data, vous faites déjà du fonctionnel (si c'est bien fait ).

    bienvenu dans le monde des années 70
    @xbrossard
    Et oui, ...du temps ou les programmes ne plantait quasiment pas lorsqu'ils sortaient en version final.
    Ou les programmes les plus fous tenaient sur 20 disquettes 8-5" et faisaient leurs taf sans besoin de patches.
    Le temps ou les sources étaient fournit au client sous forme de livret fournit dans la boite du logiciel, des fois que le logiciel lui appartienne .
    Le bon temps pour le coup.
    Si on était encore capable de faire des soft comme dans les années 70, mais avec la puissance de calcule actuel, je croit que vous seriez le premiers content de la vélocité obtenue.
    Pour l'instant, la montée en puissance à juste permit aux plus grand nombre de dév d'être moins regardant sur la qualité et les perfs , mais ça commence à ce voire avec la stagnation des perfs de nos machine.
    Enfin, je pense que c'est aussi ce phénomène qui explique, du moins en partie, l'augmentation exponentiel de nouveaux langages "remplaçant du C" ces dernières années.

  6. #6
    Membre expérimenté
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mai 2019
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Mai 2019
    Messages : 485
    Points : 1 385
    Points
    1 385
    Par défaut
    Citation Envoyé par defZero Voir le message
    Le bon temps pour le coup.
    Si on était encore capable de faire des soft comme dans les années 70, mais avec la puissance de calcule actuel, je croit que vous seriez le premiers content de la vélocité obtenue.
    Pour l'instant, la montée en puissance à juste permit aux plus grand nombre de dév d'être moins regardant sur la qualité et les perfs , mais ça commence à ce voire avec la stagnation des perfs de nos machine.
    Enfin, je pense que c'est aussi ce phénomène qui explique, du moins en partie, l'augmentation exponentiel de nouveaux langages "remplaçant du C" ces dernières années.
    Rien à voir, la complexité et les demandes sont de loin pas les mêmes par rapport à 1970, je te donne un contre exemple, faire le même code aujourd'hui qu'en 1970 ça demande moins de temps pour moins de lignes de code, quand aux bugs, c'est pareil, une app sortie en prod doit avoir un nombre de bug qui tends vers zéro. La seul différence, c'est qu'à l'époque on sortait pas tant que c'était pas parfait, maintenant si tu fais ça, tu mets la clef sous la porte avant même d'avoir sorti ton produit.

  7. #7
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Novembre 2009
    Messages
    2 032
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Novembre 2009
    Messages : 2 032
    Points : 5 470
    Points
    5 470
    Par défaut
    Citation Envoyé par L33tige Voir le message
    Rien à voir, la complexité et les demandes sont de loin pas les mêmes par rapport à 1970
    C'est clair qu'on ne demande pas les même choses !
    Aujourd'hui un "simple" site sous entend en fait qu'il est adaptable à tous les formats et tous les navigateurs! Avec bien sûr des specs qui sont toujours sur un post-it...
    Dans le domaine du jeu vidéo j'eu été surpris quand j'avais lu l'histoire de "ET" édité par Atari; Temps de dev 5 semaines pour un seul gus en 1982.
    Aujourd'hui en si peu de temps tu n'as rien de commercial ( il y a bien des exceptions comme 2048, mais il y a encore plus de chance de gagner au loto).


    Pour l'instant, la montée en puissance à juste permit aux plus grand nombre de dév d'être moins regardant sur la qualité et les perfs , mais ça commence à ce voire avec la stagnation des perfs de nos machine.
    Par contre je suis d'accord avec ça, la multiplication des outils fait que bien souvent aujourd'hui on est plus proche de l'assemblage que du développement au profit de la quantité plutôt que de la qualité.

  8. #8
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2007
    Messages
    871
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Février 2007
    Messages : 871
    Points : 1 502
    Points
    1 502
    Par défaut Je vois pas ou l'on veux en venir mais vu que c'est un actu le plus important c'est de dire n'importe quoi
    Bah en JS c'est tout le temps possible, c'est juste que, est-ce raisonnable ?
    JS n'est pas un langage fonctionnel, c'est un langage oriente fonction c'est pas du tout la meme chose...

    Avec le cloud, on recentralise tout dans des serveurs, comme sur les mainframes
    Avec le retour de la programmation fonctionnelle, on redécoupe tout en fonction

    bienvenu dans le monde des années 70
    Effectivement, le cloud avec scaling automatise c'est la meme chose que les mainframes, et la prog fonctionnel c'est la meme chose que les fonctions..

    Aujourd'hui un "simple" site sous entend en fait qu'il est adaptable à tous les formats et tous les navigateurs! Avec bien sûr des specs qui sont toujours sur un post-it...
    Dans le domaine du jeu vidéo j'eu été surpris quand j'avais lu l'histoire de "ET" édité par Atari; Temps de dev 5 semaines pour un seul gus en 1982.
    Aujourd'hui en si peu de temps tu n'as rien de commercial ( il y a bien des exceptions comme 2048, mais il y a encore plus de chance de gagner au loto).
    Comparer un jeu de 1982 et un triple A actuel, c'est pas mal comme comparaison, on pourrais aussi compare la chaine d'approvisionnement du moyen age avec notre economie actuelle ce serai tout aussi pertinent.



    Enfin parler juste de poo vs fonctionnel c'est reducteur, l'approche declarative existe aussi et toutes les nuances.

    Prenons exemple d'une approche poo stateless type microservice:
    Ce n'est pas vraiment de la poo, car stateless (a chaque appel le tout est reinstancie).
    Ce n'est pas non plus du fonctionnel car il a de l'heritage de la composition et un etat lors du traitement.

    Enfin on peut faire du declartif:
    Approche fonctionnelle n'est absolument pas contradictoire avec classes, il suffit de ne pas avoir de variable d'instances et ni de variable static par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public class Personne
    {
          DateTime  naissance;
          public Personne(DateTime  naissance){this.naissance = naissance;}
          public double GetAge()        { return (DateTime.Now - naissance).TotalSeconds; }
    }
    Au final rien de nouveau...

  9. #9
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Tech Lead
    Inscrit en
    Avril 2016
    Messages
    1 491
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Tech Lead

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 491
    Points : 6 196
    Points
    6 196
    Par défaut
    Citation Envoyé par mermich Voir le message
    Approche fonctionnelle n'est absolument pas contradictoire avec classes, il suffit de ne pas avoir de variable d'instances et ni de variable static par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public class Personne
    {
          DateTime  naissance;
          public Personne(DateTime  naissance){this.naissance = naissance;}
          public double GetAge()        { return (DateTime.Now - naissance).TotalSeconds; }
    }
    En fait, dans cet exemple, la méthode GetAge() va à l'encontre de la programmation fonctionnelle, car elle est non pure, à cause de l'appel à DateTime.Now.
    D'ailleurs, si on construit du code par dessus qui appelle Personne.GetAge, alors ce code ne sera pas testable, car son comportement dépendra directement de la date et heure courante, qui n'est pas paramétrable.

    Pour rendre ce code fonctionnel, au lieu d'appeler directement DateTime.Now dans le code "bas niveau", il faut passer de paramètre en paramètre la date et heure courante, soit sous forme de variable de type DateTime, soit sous forme de callback qui ne prend pas de paramètre et dont le type de retour est DateTime.
    Une première conséquence est que le code sera testable : lors des tests unitaires, on passe un paramètre sous contrôle où on choisit la date et heure fixée que l'on veut. En production, on passera la vraie date et heure ou la callback qui retourne la vraie date et heure.
    Une deuxième conséquence est que, du code appelé vers le code appelant, on conserve une dépendance explicite sous forme de paramètre : en lisant les signatures des fonctions, y compris l'appelant de l'appelant de l'appelant etc., on sait que cette date et heure fait partie des entrées.

  10. #10
    Expert éminent

    Homme Profil pro
    .
    Inscrit en
    Octobre 2019
    Messages
    1 608
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Aube (Champagne Ardenne)

    Informations professionnelles :
    Activité : .
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2019
    Messages : 1 608
    Points : 6 087
    Points
    6 087
    Par défaut
    Citation Envoyé par defZero Voir le message
    Et oui, ...du temps ou les programmes ne plantait quasiment pas lorsqu'ils sortaient en version final.
    Ou les programmes les plus fous tenaient sur 20 disquettes 8-5" et faisaient leurs taf sans besoin de patches.
    Le temps ou les sources étaient fournit au client sous forme de livret fournit dans la boite du logiciel, des fois que le logiciel lui appartienne .
    Le bon temps pour le coup.
    Si on était encore capable de faire des soft comme dans les années 70, mais avec la puissance de calcule actuel, je croit que vous seriez le premiers content de la vélocité obtenue.
    Pour l'instant, la montée en puissance à juste permit aux plus grand nombre de dév d'être moins regardant sur la qualité et les perfs , mais ça commence à ce voire avec la stagnation des perfs de nos machine.
    Enfin, je pense que c'est aussi ce phénomène qui explique, du moins en partie, l'augmentation exponentiel de nouveaux langages "remplaçant du C" ces dernières années.
    Les soft des années 80 n'ont rien a voir avec ceux d'aujourd'hui.
    Aujourd'hui un logiciel offre 1000 fois plus de fonctionnalitées que ceux développé dans les 80, aujourd'hui il faut que ton logiciel puisse fonctionner avec le SGBD du client, tu dois fournir une api pour la gestion des données, et évidement fournir une ihm sexy en html5 ou 50 utilisateurs pourrons utiliser ton soft en meme temps.
    c'est plus le truc en ligne de commande pouvant etre utilisé par 1 user à la fois et avec comme fonctionnalitées que 2-3 commandes ou boutons si il y'avait une IHM.

    D’ailleurs c'est a cause que la monté de la complexité du développmeent uqe l'on a inventé les IDE, les tests unitaires, les gestionnaires de version et le travail d'équipe,
    un exemple concret c'est celui du jeux videos, car si dans les années 80 un seul dev pouvais en 1ans faire un tetris avec 3 pauvre pixel animées aujourd'hui ce genre de soft se sera considéré comme une bouze, tu a besoin d'une équipe de graphiste, d'une équipe dédié a animations, a l'intelligence artificiel...etc. et au final tu arrive vite à sortir un jeux qui a coûté des millions.

    c'est comme comparé une video fais par un youtuber seul (le dev des années 80) et hollwood ou tu as un réalisateur, un cadreur, des graphistes, des enregistreur de son...etc.
    le youtuber ne fais pas de la merde au niveau du contenue hein mais d'un point de vue technique c'est a des années lumière de ce que vas te pondre un gros studio et forcément le youtuber te pondra du contue avec beaucoup de limitation comme le dev des années 80 incapable.

    tu me diras on est aller sur la lune avec la puissance d'une calculatrice casio, je te répondrais oui mais le soft a crasher pendant l’atterrissage. faire des tests automatisé, de l'integration continue sa demande du temps et de l'argent et plus de dev si tu veut avancer sinon tu mettrais 50ans a faire ton soft.

    je dis cela car a cette époque git ou svn n'existait pas, et je parle meme pas de genkins, de mockito, de junit...etc.

  11. #11
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2007
    Messages
    871
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Février 2007
    Messages : 871
    Points : 1 502
    Points
    1 502
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    En fait, dans cet exemple, la méthode GetAge() va à l'encontre de la programmation fonctionnelle, car elle est non pure, à cause de l'appel à DateTime.Now.
    Je sais tres bien que ce n'est pas fonctionnel pur, et si tu lis bien je n'ai pas prétendu que c’était du fonctionnel pur juste que l'on pouvait faire du fonctionnel en c#/java (meme si honnetement c'est pas la panacee). Ouais ok j'aurai dut indiquer que c'est du pseudo pur. Pour le coup des tests et de l'injections, il existe pas mal de procédés pour rendre le code testable que tu as deja cite.

  12. #12
    Membre du Club
    Profil pro
    Inscrit en
    Mars 2012
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2012
    Messages : 22
    Points : 69
    Points
    69
    Par défaut Encore une belle affirmation
    "Le cerveau humain est la machine la plus puissante de l'univers." Ben voyons, voilà une affirmation à l'image du dit cerveau. Quelle prétention !

  13. #13
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par xbrossard Voir le message
    Avec le cloud, on recentralise tout dans des serveurs, comme sur les mainframes
    Avec le retour de la programmation fonctionnelle, on redécoupe tout en fonction

    bienvenu dans le monde des années 70
    Pour information la POO date des années 60. https://en.wikipedia.org/wiki/Object...amming#History

  14. #14
    Membre éprouvé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Décembre 2008
    Messages
    107
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2008
    Messages : 107
    Points : 913
    Points
    913
    Par défaut
    chaque paradigme de programmation a ses avantages et ses inconvénients: chacun a été conçu pour résoudre une catégorie de problèmes. A chaque problème son outil... La POO est malheureusement survendu en école et trop mis en avant par certains langages...

  15. #15
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    J'invite tout de même tout le monde à lire l'article original dont le propos n'est pas complètement retranscrit ici.

    Tout d'abord, l'auteur du post original précise bien qu'il parle de son expérience avec le langage et l'écosystème TypeScript et admet que son propos aurait pu être différent s'il avait été un expert de Java ou C#, langages qui ont des mécanismes bien plus poussés pour gérer les classes que ne le permet TypeScript (et encore moins ECMAScript).

    L'un des reproches qu'il adresse à structuration du code avec des classes est qu'on a tendance, via l'héritage et la surcharge de fonctions, d'élargir les responsabilités des méthodes tout en gardant le même nom initial. Une simple méthode nommée "update" finissant par faire le café. Je ne sois pas sûr que ce soit le concept de classe qui soit à blâmer ici, davantage de la discipline, mais les classes favorisent peut-être peu trop la réutilisation des noms.

    Un autre reproche c'est que l'organisation du code avec des classes rend la base de code paradoxalement moins modulaire car on abouti régulièrement à des méga-classes avec des enfilades de propriétés et méthodes. A moins que TypeScript améliore son concept de classe partielle (les "mixins" n'étant qu'un bidouillage pas totalement satisfaisant selon moi) comme on peut le retrouver dans d'autres langages, C# par exemple, il est clair qu'en TypeScript, tout faire à base de classes n'est pas une bonne idée si on veut tendre vers la modularité. Il est effectivement préférable comme le remarque l'auteur d'utiliser le concept de modules, normalisé en ECMAScript qui plus est.

    L'auteur fait également mention de la difficulté à bien gérer les changements d'états interne des classes ce qui le pousse à utiliser une approche basée sur les fonctions (ce qui ne signifie pas qu'il s'agit d'une approche fonctionnelle au sens pur du terme). Mon opinion sur la question des états étant qu'ils sont inévitables dans une application du monde réel, mais qu'il faut bien sûr les limiter au maximum, les canaliser et les maîtriser, en repoussant le plus tard possible leur apparition dans le code, afin de limiter l'explosion combinatoire au moment d'élaborer les cas de tests.

  16. #16
    Membre éprouvé
    Homme Profil pro
    Everything
    Inscrit en
    Décembre 2013
    Messages
    361
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Italie

    Informations professionnelles :
    Activité : Everything

    Informations forums :
    Inscription : Décembre 2013
    Messages : 361
    Points : 1 277
    Points
    1 277
    Par défaut
    le but originel de la POO est la facilité de la réutilisation et le confinement des bug dans l'objet incriminé.

  17. #17
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Jiji66 Voir le message
    le but originel de la POO est la facilité de la réutilisation et le confinement des bug dans l'objet incriminé.
    Encore une preuve que le confinement n'est pas très efficace, alors...

  18. #18
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2003
    Messages
    321
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 321
    Points : 762
    Points
    762
    Billets dans le blog
    1
    Par défaut
    Un exemple vaudrait mieux qu'un long discours.

    Désolé l'argument des balles de jonglages ne me séduit pas : du concret !

  19. #19
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 674
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 674
    Points : 10 686
    Points
    10 686
    Par défaut
    Citation Envoyé par Jiji66 Voir le message
    le but originel de la POO est la facilité de la réutilisation et le confinement des bug dans l'objet incriminé.
    le but de la POO est avant tout de regrouper les traitements/ les messages, et leurs états s'il y en a.


    Citation Envoyé par yahiko Voir le message
    L'un des reproches qu'il adresse à structuration du code avec des classes est qu'on a tendance, via l'héritage et la surcharge de fonctions, d'élargir les responsabilités des méthodes tout en gardant le même nom initial.
    je pense que le problème de la POO c'est d'avoir une approche "proche du réel". Et donc, il y a toujours une adaptation du "monde réel" pour qu'il devienne du code informatique ... tout en respectant le cahier des charges
    Sans parler de ceux qui en rajoute parce que cela se passe "comme cela dans le réel" en utilisant des notions POO comme l'héritage qui ont des impacts lourds sur la conception mais qu'ils ne maîtrisent pas/ n’anticipent pas.

  20. #20
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2008
    Messages
    168
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Février 2008
    Messages : 168
    Points : 478
    Points
    478
    Par défaut
    Citation Envoyé par yahiko Voir le message
    J'invite tout de même tout le monde à lire l'article original dont le propos n'est pas complètement retranscrit ici.
    Merci pour le résumé

    Citation Envoyé par yahiko Voir le message
    L'un des reproches qu'il adresse à structuration du code avec des classes est qu'on a tendance, via l'héritage et la surcharge de fonctions, d'élargir les responsabilités des méthodes tout en gardant le même nom initial. Une simple méthode nommée "update" finissant par faire le café. Je ne sois pas sûr que ce soit le concept de classe qui soit à blâmer ici, davantage de la discipline, mais les classes favorisent peut-être peu trop la réutilisation des noms.
    Élargir les responsabilités, c'est bien le but de l'héritage. Garder le même nom de méthode pour des choses complètements différentes, c'est de la fainéantise. Ou de l’incompétence.

    Avant de coder, il faut réfléchir, et savoir ce qu'on veux faire. Et c'est là ou les ennuis commencent, et ce quelque soit le paradigme .

    Citation Envoyé par yahiko Voir le message
    Un autre reproche c'est que l'organisation du code avec des classes rend la base de code paradoxalement moins modulaire car on abouti régulièrement à des méga-classes avec des enfilades de propriétés et méthodes.
    Alors, de mémoire, dans un bouquin que j'ai lu quand j'étais jeune (y a un bail ) sur la programmation objet, l'auteur indiquait qu'une classe doit pouvoir être décrite sur une feuille A5.
    Par décrite, je parle des membres et attributs/propriétés.

    Citation Envoyé par yahiko Voir le message
    L'auteur fait également mention de la difficulté à bien gérer les changements d'états interne des classes ce qui le pousse à utiliser une approche basée sur les fonctions.
    Si tout est clair dans la tête du développeur et que les méthodes sont commentées comme il faut ("modification de l'attribut xxxx" par exemple), il n'y a pas de soucis à ce faire.

    Si il est bordélique et sais pas ce qu'il fait, .

Discussions similaires

  1. utilisation des classes et fonctions d'une dll c++ en vb
    Par rigane_med dans le forum VB.NET
    Réponses: 0
    Dernier message: 24/06/2011, 00h52
  2. Réponses: 6
    Dernier message: 09/02/2011, 10h15
  3. Réponses: 0
    Dernier message: 10/05/2010, 15h05
  4. utilisation des classes et fonctions d'une dll c++ en vb
    Par yuriashford dans le forum VB.NET
    Réponses: 2
    Dernier message: 26/05/2008, 15h21
  5. utiliser des classes dont on n'a pas le source
    Par kocin dans le forum Eclipse Java
    Réponses: 2
    Dernier message: 28/08/2004, 16h05

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