Journal Le problème de la POO pratiquée par des étudiants

19
26
avr.
2011

Pour ceux qui visitent LinuxFR en espérant parler de logiciel libre, ce journal part d'un contenu trouvé sur rstat.us, le Tweeter libre. Si la programmation n'est pas votre tasse de thé, vous pouvez maintenant zapper sur un autre journal.

Michael Sokol a exprimé sur son blog un billet sur la Programmation Orientée Objet. Pour résumer son propos, il remarque que la POO se résume à créer plein de classes, plein d'histoires d'héritages et d'abstractions, et qu'au final on obtenait un logiciel avec une structure tellement rigide que ça en réduit la possibilité de réutilisation du code, et il appelle ce concept la Programmation Orientée Classe.

J'ai eu l'impression de voir là une description de la POO enseignée dans les écoles, où on nous demande dans les specs de projets de mettre des classes abstraites et des interfaces java à tout va. J'ai donc demandé au monsieur ce que pouvait être de la POO non scolaire :

I guess prototype-based OOP (like JS) or ducktyping (polymorphism w/out inheritance) would be good examples of non-SOOP.

Ou en français :

Je pense que la POO à prototype (comme en Javascript) ou le duck typing (polymorphisme sans héritage) sont de bons exemples de POO non scolaire.

Quel est l'avis des programmeurs qui trainent sur LinuxFR sur cette histoire de POO ?

  • # Ça rejoint les typeclass de haskell, template du C++, Go

    Posté par . Évalué à 10.

    En C++ on aime bien utiliser des templates pour faire du polymorphisme là où en java on ferait de l'héritage (ou du moins un implements interface). C'est en quelque sort du ducktyping à la compilation. « tiens, il essaye d'utiliser la méthode moo(), on va voir si ça existe pour le type. Si ça existe pas, je plante et râle très copieusement à la compilation ». Ainsi, tout objet qui a une opération < pourra être utilisé dans un map.

    Les typeclass de haskell définissent des signatures que doivent avoir les "objets". Et tout "objet" qui a la signature implémente la typeclass, sans se prendre la tête sur les classes abstraites, interface que java aime tant. « Si l'objet a la fonction print alors il printable »

    Enfin Go s'est fait remarqué parcequ'il ne gère carrément pas l'héritage et fait du polymorphisme un peu à la Haskell. La structure de données, et le traitement sont deux choses strictement orthogonales, là où la POO classique veut les réunir.

    Personnellement, j'aime bien cette tendance et je m'en réjouis.

  • # Poooo!

    Posté par (page perso) . Évalué à 10.

    Ici on est des vrais, on fait du C.
    C'est peut-être moins classe (ouch, le jeu de mots ;) ), mais c'est vachement plus sympa o/

    • [^] # Re: Poooo!

      Posté par . Évalué à 3.

      Pffffff, ici on écrit nos binaires directement. L'assembleur c'est trop haut niveau, et en plus il risque d'y avoir des bugs dans l'outil. C'est le seul moyen d'être sûr que ta chaîne de compilation n'a pas de bug ou de trou de sécurité. Ben oui, y'a pas de chaîne de compilation ;)

      Sinon, le bon outil pour la bonne tâche, toussa...

    • [^] # Re: Poooo!

      Posté par . Évalué à 3.

      Et de la généricité avec des pointeurs de fonctions. On est au niveau de javascript niveau souplesse, c'est sur /o

      • [^] # Re: Poooo!

        Posté par . Évalué à 6.

        c'est reloud ces \ qu'il faut doubler pour qu'ils ne sautent pas

        • [^] # Re: Poooo!

          Posté par . Évalué à -1.

          Ça sert à quoi le bouton prévisualiser d'après toi ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Poooo!

            Posté par . Évalué à 6.

            Ça ne sert à rien pour les gens qui utilisent Monboob et leur logiciel de mails pour troller.

            Et le comportement souhaitable et logique, dans la rédaction d'un texte formaté, c'est que le '\' permette d'échapper le suivant seulement si il s'agit d'un caractère de formatage, et que dans le cas contraire il soit affiché et non ignoré.

            • [^] # Re: Poooo!

              Posté par (page perso) . Évalué à -2.

              Mauvais logiciel, changer de logiciel.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Poooo!

                Posté par . Évalué à 7.

                Ton commentaire n'est pas très sympa pour NoNo< qui a quand même passé du temps bénévolement sur cette nouvelle version de DLFP^WLinuxFr.Org.

                • [^] # Re: Poooo!

                  Posté par (page perso) . Évalué à -1.

                  Linuxfr est un site web, pas un logiciel.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Poooo!

                    Posté par . Évalué à 3.

                    Je l'aurait dis autrement. Quand on utilise monboob, on utilise linuxfr comme un service et l'interface utilisateur (celle qui est censées gérer les problèmes d'interface chaise/clavier) c'est monboob.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Poooo!

                      Posté par . Évalué à 7.

                      En l'occurrence avec Monboob l'interface utilisateur c'est ton client mail, ça peut donc être aussi bien mutt que Thunderbird ou gmail.

                      Je n'ai pas dit que l'absence de la prévisualisation est une gêne, c'est un choix qui est fait lorsqu'on utilise Monboob et ma critique était juste sur le système de markdown de LinuxFr qui a un comportement que je ne juge pas user friendly lorsqu'on tape un unique backslash dans un cas où il n'y a aucune ambiguïté sur son utilisation et qui permet d'éviter ces soucis.

                      Il me semblait que ce markup était justement prévu pour être le plus naturel possible et laisser le texte lisible même lorsque l'on lit la source. Ce n'est donc pas normal de devoir doubler systématiquement les backslashes.

                      • [^] # Re: Poooo!

                        Posté par (page perso) . Évalué à -1.

                        Ce n'est donc pas normal de devoir doubler systématiquement les backslashes.

                        Ça me semble normal comme comportement, GCC fait la même chose sur les const char, TeX aussi…

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Poooo!

                          Posté par . Évalué à 7.

                          Justement, il y a une différence entre la syntaxe des chaînes dans un langage de programmation, et un langage de markup à destination de non techniciens. Je ne sais pas ce que tu n'as pas compris dans « être prévu pour être le plus naturel possible ».

                          • [^] # Re: Poooo!

                            Posté par (page perso) . Évalué à -4.

                            LaTeX est aussi à destination de non techniciens.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                            • [^] # Re: Poooo!

                              Posté par . Évalué à 7.

                              et son succès parmi eux est fla-grant.

                              • [^] # Re: Poooo!

                                Posté par (page perso) . Évalué à 8.

                                En Allemagne les étudiants écrivent leurs mémoires en LaTeX, pas seulement les informateux, les physiqueux et les matheux mais aussi les économeux et sûrement d'autres encore. De plus il existe sur le sujet une littérature raisonnable en langue allemande depuis beaucoup plus longtemps qu'en langue française [*]

                                L'utilisation de LaTeX par des non techniciens, comme les choix de tous logiciels, c'est aussi une affaire de culture.

                                [*] Et deux des distibutions principales de TeX sont organisées par des allemands (MikTeX et teTeX), juste comme ça, en passant.

                            • [^] # Re: Poooo!

                              Posté par . Évalué à 3.

                              LaTeX ne fait pas d'échappement du caractère antislash comme le fait GCC.

                              Pour faire des antislash en latex, le plus simple est de se mettre dans un mode verbatim, dans ce cas la il n'y a pas d'échappement à faire. Et franchement, je vois pas l'utilité de mettre un antislash ailleurs que dans un verbatim dans un document correctement typographié (sauf en math, mais dans ce cas c'est backslash, parce que c'est pas n'importe quel antislash).

            • [^] # Re: Poooo!

              Posté par . Évalué à 2.

              Quand on fais un usage qui est plus de l'ordre du hack que d'autre chose d'un logiciel, faut pas s'étonner de ne pas avoir toutes les fonctionnalités prévues. Sinon je peux très bien dire que linuxfr est mal foutu parce qu'il n'est pas agréable à utiliser avec curl.

              De plus je suis persuadé que les utilisateurs de Monboob sont friand de logiciels comme markdown (txt2tags, restructuredtext,...) pour rédiger leur documents (et s'ils ne le sont pas ils devraient s'y mettre ؟).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Duck typing

    Posté par (page perso) . Évalué à 2.

    On ne dit pas duck typing mais sous-typage structurel. Et puis de toute manière, le typage dynamique, ça ne veut rien dire.

    (Et maintenant, on va voir s'il y a des trolleurs spécialistes en théorie des types qui traînent sur Linuxfr.)

    http://en.wikipedia.org/wiki/Structural_type_system

    • [^] # Commentaire supprimé

      Posté par . Évalué à 6.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Duck typing

        Posté par . Évalué à 2.

        C'est son alter égo version typage statique.

      • [^] # Re: Duck typing

        Posté par . Évalué à 0.

        C'est son alter égo version typage statique.

      • [^] # Commentaire supprimé

        Posté par . Évalué à 2.

        Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: Duck typing

          Posté par (page perso) . Évalué à 1.

          Oui, donc en fait, le duck typing c'est du sous-typage structurel, mais sans le typage. Du coup, pour le duck, je comprends.

          Il faudrait juste m'expliquer pourquoi ils appellent ça typing.

          • [^] # Re: Duck typing

            Posté par . Évalué à 2.

            Il faudrait juste m'expliquer pourquoi ils appellent ça typing.

            Car ce terme veux dire en gros: C'est l'ensemble des attributs et méthodes de l'objet qui définissent sont type.

            En gros plutôt que dire: Ma méthode doit recevoir une instance du type X
            Tu dis: Ma méthode doit recevoir un objet implémentant une méthode coin()

            La majorité des langages "duck typé" sont des langages à typage dynamique, mais tu as des exceptions comme Scala. Bref les notion de "duck typing" et de dynamicité du typage sont orthogonales ou presque.

            • [^] # Re: Duck typing

              Posté par (page perso) . Évalué à 4.

              En gros plutôt que dire: Ma méthode doit recevoir une instance du type X
              Tu dis: Ma méthode doit recevoir un objet implémentant une méthode coin()

              C'est exactement la définition du (sous-)typage structurel.

              In structural typing, an object or term is considered to be compatible with another type if for each feature within the second type, there must be a corresponding and identical feature in the first type.
              http://en.wikipedia.org/wiki/Structural_type_system

              Je ne vois vraiment pas ce qu'il y a en plus, et plus je lis dessus, plus j'ai l'impression que c'est un joli mot inventé pour expliquer avec les mains un concept de théorie des types, inventé par des gens qui ne connaissaient pas ladite théorie.

              Ce n'est pas grave, et si ça aide à le populariser, tant mieux, mais ce qui me gêne c'est qu'on répète partout que c'est différent : j'aimerais qu'on me donne un exemple faisable avec l'un et pas avec l'autre, pour être clair. Je n'ai strictement rien vu qui les différencie pour l'instant.

              • [^] # Re: Duck typing

                Posté par . Évalué à 2.

                Et tu es allé voir ce qu'ils disaient ici ?

                http://lambda-the-ultimate.org/node/1201

                Généralement les gens qui interviennent sur ce site sont loin d'être des manches...

                • [^] # Re: Duck typing

                  Posté par (page perso) . Évalué à 3.

                  Oui, et en gros tu as deux catégories de gens : ceux qui disent que c'est pareil (c'est-à-dire, essentiellement, ceux qui connaissent OCaml), au motif que ça permet de faire exactement la même chose (avec en plus la sûreté du typage dans le cas d'OCaml) et ceux qui disent que c'est différent, parce que tu vois, moralement, quand même, le canard, c'est quand tu regardes le truc, et puis c'est coin coin alors c'est un canard... sans donner aucun exemple convaincant. Merveilleusement résumé par :

                  Aha, Leibniz equality ;-).

                  Le seul qui ressorte un peu du lot, c'est celui qui parle de conversion de type (genre entier <=> string <=> float à la demande), à la PHP, là je reconnais que ça n'a rien à voir avec le typage structurel, mais ce n'est généralement pas ce que les gens entendent par duck typing il me semble (on entend beaucoup plus parler de méthodes que de conversion de types).

                  Cela dit, si c'est vraiment ça le duck typing, je préfère ne pas en entendre parler :-) (va débugguer un programme avec ces conversion implicites, un pur plaisir...).

            • [^] # Re: Duck typing

              Posté par (page perso) . Évalué à 3.

              En gros plutôt que dire: Ma méthode doit recevoir une instance du type X
              Tu dis: Ma méthode doit recevoir un objet implémentant une méthode coin()

              C'est exactement l'analyse que fait le compilateur OCaml lorsqu'il lit quelque chose comme ça:

              # let send x = x # send;;
              val send : < send : 'a; .. > -> 'a = <fun>
              

              Après évaluation send est une fonction acceptant tout objet admettant une méthode send et appelant ladite méthode desuss: c'est exactement ce que tu dis.

              Dans les archives de la mailing list de OCaml j'ai retrouvé ça:

              Dario wrote:

              Re: Smells like duck-typing
              --8<--
              I am going for the no-inheritance object solution: [...] it allows code reuse thanks to OCaml's structural subtyping feature (the "duck" in this thread's title).

              Les gens intervenant sur la liste sont certainement aussi peu manches que ceux de lambdathe-ultimate.org et apparemment personne n'a crié au scandale en voyant que quelque'un prétendait assimiler le duck typing au typage structurel.

              Et pour l'instant aucun des arguments ici ne permet de vraiment faire la différence. Qu'est-ce que peut faire le duck-typing que ne permet pas le typage structurel?

    • [^] # Re: Duck typing

      Posté par (page perso) . Évalué à 10.

      Le duck typing c'est facile:

      \_o< COIN !

  • # Titre pathétique

    Posté par (page perso) . Évalué à 3.

    Ne voyant pas bien le rapport entre la nationalité d'une personne et sa compétence en programmation, j'ai supprimé la seconde partie du titre, qui est à peu près aussi lamentable que « tous les Français sont racistes ».

    • [^] # Re: Titre pathétique

      Posté par . Évalué à 8.

      On n'a plus le droit d'être pathétique, sur Linuxfr ? J'espérais qu'au moins ici la modération n'aurait lieu que pour éviter l'illégalité.

    • [^] # Re: Titrepathétique

      Posté par . Évalué à 10.

      Pourquoi est-ce que les [CENSURÉ PAR LE COMITÉ DE LA PENSÉE CONSENSUELLE DE LINUXFR.ORG] devraient se sentir davantage offensés par ce journal que les étudiants ?

      • [^] # Re: Titrepathétique

        Posté par . Évalué à 4.

        Moi aussi je dénonce et je demande le retrait du mot étudiant du titre !

        • [^] # Re: Titrepathétique

          Posté par . Évalué à 2.

          En fait il suffirait de retirer le "problème" pour ne plus risquer de choquer.

          • [^] # Re: Titrepathétique

            Posté par . Évalué à 2.

            Ce serait un premier pas appréciable, mais la référence aux étudiants reste discriminatoire.

            En plus, POOh, c'est très vulgaire, et ça pourrait choquer nos amis anglophiles. Je pense qu'il faudrait l'enlever aussi.

      • [^] # Re: Titrepathétique

        Posté par . Évalué à 3.

        Parce qu'un étudiant est pas censé avoir d'expérience.

        Tandis qu'un roumain ... euh, un roumain ? Ah merde c'est une nationalité, si ça se trouve il est étudiant. Il est pas censé être mauvais ou inexpérimenté en info parce qu'il est roumain.

    • [^] # Re: Titre pathétique

      Posté par . Évalué à 8.

      à partir de dorénavant, quand votre prestataire vous déçoit grandement, ne dites plus "travail d'arabe" mais "travail d'étudiant".

      • [^] # Re: Titre pathétique

        Posté par . Évalué à 10.

        C'est déjà très couru, seulement on dit pas étudiant mais stagiaire.

        • [^] # Re: Titre pathétique

          Posté par . Évalué à 4.

          Remarque, la qualité du code est peut être proportionnelle au salaire et au coefficient de casse gueulisme du sujet.

  • # Rigidité

    Posté par . Évalué à 10.

    Quel est l'avis des programmeurs qui trainent sur LinuxFR sur cette histoire de POO ?

    Mon avis à moi, et je suis brièvement passé par là, c'est que, plus qu'une histoire de POO, c'est ce qu'on obtient quand on apprend aux gens à suivre des méthodes rigides sans laisser place à la créativité et à la souplesse. Je me souviens de méthodes d'une lourdeur effrayante pour concevoir des schémas de bases de données relationnelles ; je ne doute pas que les méthodes en question soient efficaces, mais dans la plupart des projets on n'a pas besoin de ça, on a besoin de rapidité et d'adaptabilité. C'est pour ça que les machins très à la mode de "programmation agile" marchent aussi bien.

    Le problème, c'est qu'on ne peut pas prendre un étudiant inculte et lui faire faire de la programmation agile, il faut qu'il ait déjà un peu de bouteille pour avoir la bonne intuition et ne pas se lancer dans des impasses.

    • [^] # Re: Rigidité

      Posté par . Évalué à 5.

      Je me souviens de méthodes d'une lourdeur effrayante pour concevoir des schémas de bases de données relationnelles

      C'était quoi ? Parce que le modèle entité-association ou l'UML ça le fait très bien (c'est vrai faut se poser quelques minutes pour réfléchir). Les cas où ça paraît lourd sont généralement les cas où ils serait intéressant de se tourner vers du noSQL.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Rigidité

        Posté par . Évalué à 2.

        Je me suis dépêché d'oublier les détails de la méthode, quelqu'un pourra corriger/compléter, mais ça ressemblait à ça:
        - faire un schéma au niveau niveau conceptuel
        - traduire ça en tables et relations de la manière la plus puriste qui soit, donc potentiellement inefficace
        - analyser les requêtes qu'on va faire
        - en fonction de ça, revenir sur les décisions en fusionnant des tables, en transformant des associations en entités, etc.
        - implémenter

        Dans l'absolu c'est une bonne méthode, mais les étapes d'analyse/optimisation sont coûteuses, et ne devraient souvent être faites qu'à postériori si c'est nécessaire.

        • [^] # Re: Rigidité

          Posté par (page perso) . Évalué à 4.

          Justement, dans une application normale, seules les deux premières (et la dernière) étapes sont nécessaires. Le reste, c'est de l'optimisation (et donc fait a posteriori si nécessaire uniquement). De plus, avec un peu de bouteille, on peut faire une bonne conception dès le départ…

          • [^] # Re: Rigidité

            Posté par . Évalué à 3.

            C'est ce que je veux dire: il ne faut pas systématiquement optimiser, mais il ne faut pas non plus être trop con lors de la conception du premier schéma. L'idéal est d'avoir une approche pas trop mauvaise au début mais rapide à faire et facilement adaptable aux nouveaux besoins qui apparaîtront après. Pas facile à enseigner, ça.

            • [^] # Re: Rigidité

              Posté par (page perso) . Évalué à 8.

              J'ai déjà constaté qu'enseigner des trucs comme « il n'y a pas de bonne ni de mauvaise conception » servait surtout aux étudiants à justifier tout et n'importe quoi. Il me semble qu'enseigner un truc un peu rigide, quitte à ce que des libertés soient prises avec tout ça face à une situation professionelle, me semble une meilleure méthode d'enseignement que d'essayer de transmettre des notions floues qui naviguent entre deux eaux.

              C'est un peu comme en typographie : enfreindre une règle, ce n'est pas très grave tant qu'on en est conscient et qu'il y a une bonne justification derrière. C'est nettement « moins pire » que d'enfreindre une règle parce que l'on ne la connait pas.

              • [^] # Re: Rigidité

                Posté par . Évalué à 2.

                Ben si, il y a de mauvaises conceptions. Une conception rigide quand le cahier des charges est fluide, c'est mauvais. Une hiérarchie de classes hyper poussée et des imbrications dans tous les sens alors que ce n'était pas nécessaire, c'est mauvais. D'un autre côté, une mauvaise encapsulation des données, c'est mauvais aussi.

                Pour moi, une bonne conception doit inclure une certaine flexibilité (sauf cas particuliers qui nécessitent une spécification stricte). Mais la flexibilité est difficile à enseigner, c'est énormément lié à l'expérience.

              • [^] # Re: Rigidité

                Posté par . Évalué à 5.

                Il ya une bonne conception et une mauvaise conception.

                C'est comme les chasseurs :)

                Plus serieusement, oui, il ya de tres mauvais design, et de tres bon. Le probleme c'est qu'ils sont interchangeables en fonction du probleme a resoudre. Eric Evans donne comme exemple 2 cartes, une de chine assez funky d'il ya qq siecles (qui cite, pour un des pays limitrophes "ici vivent des gens de grande taille") et une mappemonde des plus banals.

                Les 2 sont de tres bon designs.
                Le premier est tres bon pour un chinois en chine. La deuxieme est mauvaise pour un chinois en chine parce qu'il ya beaucoup de bruit et manque d'information.
                La deuxieme est excellente pour les navigateurs sur bateaux, la ou la premiere leur est totalement inutile.

                C'est le truc de base a retenir: tout comme les 2 cartes precedentes repondent a un besoin precis, on ecrit une application qui repond a une problematique particuliere. Le design reflete cette problematique.

                Il est vain de faire une solution soit disant generique qui repondra aussi a d'hypothetique problemes futures encore inconnus. Un bon design est un design adapte a la problematique traitee. Si la problematique change, on changera le design. Un excellent design permettra lui de modifier l'appli en question a moindre cout, mais a ce niveau la, c'est plus de la technique, ca devient un art :)

                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: Rigidité

                Posté par . Évalué à 2.

                Bonsoir,

                Sans tomber dans l’extrême "ni bon, ni mauvais", je pense qu'il est préférable de ne pas trop être rigide en enseignement.

                Il y a de mauvaises conceptions, mais je me souvient de discutions passionnées avec mon prof de génie logiciel ou chaque projet défendait sa vision à grand coup d'arguments. J'ai trouvé cela plus instructif que des cours plus rigides.

                Après, dans la "vraie vie", il y a beaucoup plus de contraintes et pas forcément techniques, mais justement autant en profiter pendant la phase idyllique de notre boulot :)

                • [^] # Re: Rigidité

                  Posté par (page perso) . Évalué à 1.

                  En fait, plus précisément, je disais plutôt qu'il n'y a jamais qu'une bonne conception. Mais ça suffisait à décrédibiliser pas mal de corrections.

              • [^] # Re: Rigidité

                Posté par (page perso) . Évalué à 4.

                J'ai déjà constaté qu'enseigner des trucs comme « il n'y a pas de bonne ni de mauvaise conception » servait surtout aux étudiants à justifier tout et n'importe quoi.

                Dans l'introduction à son traité d'harmonie, Théodore Dubois fait remarquer que de nombreuses règles figurant dans son traité sont enfreintes par les maîtres: il rappelle alors que le traité est destiné aux étudiants et que ces règles les dispenseront de commettre les fautes de goût les plus évidentes (j'ajouterais: et à organiser leurs connaissances): ils s'en affranchironr lorsque leur goût sera formé et éduqué.

                Il ne faut pas perdre de vue que les connaissances dispensées dans un cours sont préparées pour leur public (en principe!): qu'il faille ensuite abandonner certaines règles dures et dogmes est un évidence --- mais ce n'est pas une raison pour jeter le cours avec l'eau du bain comme le font un peu vite certaines personnes.

                C'est un peu comme en typographie : enfreindre une règle, ce n'est pas très grave tant qu'on en est conscient et qu'il y a une bonne justification derrière.

                Ça va dans le sens de Dubois, on peut aussi relier à cette idée la parole de Baudelaire selon laquelle rien n'est plus facile que le vers libre: c'est facile pour lui, parcequ'il est formé.

              • [^] # Re: Rigidité

                Posté par (page perso) . Évalué à 4.

                Le pire étant peut être d'apprendre par cœur des règles sans avoir la moindre idée d'où elles sortent, en quoi elles sont pertinente et dans quel cadre.

        • [^] # Re: Rigidité

          Posté par . Évalué à 3.

          Ta description me fait penser à la méthode Merise (informatique). Personnellement, une fois passé le petit temps d'apprentissage, je trouvais la chose facile, rapide et pratique. Ça avait le gros avantage de t'obliger à bien réfléchir à la conception de ton programme avant de te lancer dans l'écriture de code à la rache.

        • [^] # Re: Rigidité

          Posté par . Évalué à 2.

          Cette méthode permet d'avoir un bon shemas de base de données, sans avoir les années d’expériences pour pouvoir parler de thèmes aussi précis que la fluidité, la rigidité et la flexibilité. De plus ça s'accommode très bien à l'expérience que tu gagne et qui te permet de straper des étapes. Enfin l'étape 3 permet d'avoir un oeil critique de son travail.

          Dans la pratique tu fais l'étape 1, 2 et 5. Les étapes 3 et 4 est faite après la programmation de l'application ou par de mauvaises performances de celle-ci. Bref par manque de temps et pour simplifier le travail des étudiants on le présente ainsi, mais ça ne me semble pas être une mauvaise méthode.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Rigidité

          Posté par (page perso) . Évalué à 2.

          Dans les méthodes qu'on enseigne maintenant, il est expliqué qu'il faut suivre un schéma itératif.

          Donc les étapes que tu as donnés sont plus ou moins les mêmes, mais on fait d'abord une première ébauche avec seulement les entités principales, puis en passant aux prochaines étapes on peut se rendre compte plus vite si on est dans le bon ou pas, et adapter en conséquence.

          Si on fait tout séquentiellement, et qu'on a fait une erreur à la première étape mais qu'on s'en rend compte qu'à l'implémentation, ça a un impact bien plus négatif.

          « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

  • # Méthodes abstraites ou finales

    Posté par (page perso) . Évalué à 6.

    Une bonne partie des défauts de la POO décrite dans l'article peuvent être évités en appliquant quelques règles de bonne conduite, suffisamment reconnues pour être pratiquées par les outils d'analyse de code automatique (genre PMD ou Checkstyle pour le Java) : limiter la profondeur des hiérarchies, ne définir que des méthodes abstraites ou finales (s'interdisant ainsi la surcharge de méthodes, extrêmement délicate à assurer), penser « API » quelque soit l'application.

    Le fait est que la POO, c'est bien, mais comme tout paradigme, il est tout à fait possible de faire n'importe quoi avec, notamment des sacs de nœuds inextricables et impossibles à réutiliser…

  • # Héritage...

    Posté par . Évalué à 10.

    Personnellement (mais attention, je ne suis pas un spécialiste de la question), je trouve qu'on a fait de l'héritage un des trucs-super-que-ça-existe-donc-faut-l'utiliser-absolument-sinon-on-n'est-pas-un-vrai-programmeur-objet.

    Je sais que l'un ne remplace pas l'autre, mais j'ai beaucoup plus souvent besoin de la composition que de l'héritage: "a-un" plutôt que "est-un". Et la composition, je trouve qu'on n'en parle pas assez quand on parle de programmation objet.

    Je répète: suis pas spécialiste, et je suis donc ouvert à tout commentaire qui pourrait élever mon point de vue...

    • [^] # Re: Héritage...

      Posté par . Évalué à 3.

      L'héritage a le défaut de rendre la hiérarchie des classes trop rigides s'il est utilisé à mauvais escient. D'ailleurs, les patern Strategy et le Decorator préfère la composition pour éviter ce genre de soucis, en regroupant les comportements similaires dans des classes.

    • [^] # Re: Héritage...

      Posté par . Évalué à 2.

      Je suis entièrement d'accord avec toi, autant on nous apprend l'héritage en cours, je comprends bien la notion et ça a l'air vachement bien, mais au final on tombe quand même assez rarement sur des cas où je vois une réelle logique, alors que la composition (je savais même pas que ca avait un nom) me semble être une option beaucoup plus logique ... Et j'ai vu pas mal de code où de l'héritage était utilisé alors que la composition me parraissait carrément plus appropriée.

      • [^] # Re: Héritage...

        Posté par . Évalué à 3.

        Peut-être que la notion de composition a des racines mathématiques traumatisantes pour les étudiants qui ont eu à faire de l'analyse au lycée et en premier cycle. ;-)

        Alors que l'héritage, on peut l'expliquer sans passer par des gros mots mathématiques (oui bon OK, on peut parler composition sans parler de maths, mais honnêtement, je vois bien plein de profs céder à la facilité ... « C'est comme la composition que vous avez apprise en Seconde »)

        Plus sérieusement, pendant des années la notion de composition était plus ou moins « réservée » aux langages fonctionnels parce que par définition ils la permettent (absence d'effets de bord, tout ça). Mais depuis quelques années maintenant on observe une vraie convergence de notions issues des mondes fonctionnels et objet, parfois sous forme de mécanismes cachés, parfois sous forme d'ajouts à la syntaxe du langage.

        Le seul problème que je vois à l'héritage en POO, c'est qu'effectivement il n'est pas expliqué aux étudiants (dont j'ai fait partie) à quel point la chaîne d'héritage est « figée ». En C++ il existe bien l'héritage multiple qui assouplit pas mal de choses, mais manque de bol, il est tellement facile de merder avec que mes profs en avaient vaguement parlé, mais avaient dit un truc du genre : « C'est comme le goto. Vous avez intérêt à avoir une vraie bonne raison de l'utiliser que vous pouvez justifier dans vos programmes. » (avec un indice additionnel du genre « pas besoin de goto ou d'héritage multiple dans les projets qu'on vous donnera » pour bien nous dissuader).

        • [^] # Re: Héritage...

          Posté par . Évalué à 5.

          C'est marrant, lors de ma formation, on nous a bien expliqué la notion d'héritage multiple et même donné des exemples d'utilisation saine...

          Comme quoi ça dépend vraiment des profs sur lesquels on tombe ^^

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Héritage...

            Posté par . Évalué à 1.

            Ça peut être sain, mais pourquoi devoir faire de l'héritage en faisant une tâche bien définie ? En utilisant l'héritage, est-ce que l'on ne tombe pas quelque part dans une « réinvention de la roue » ? Je veux dire , si on a besoin de deux classes pour faire deux choses différentes, l'héritage n'apporte pas grand chose là dedans.

            Par exemple, j'ai l'impression que avec QT, l'héritage est très utilisé, mais brouille peut être un peu les pistes. On se retrouve avec x qui hérite de y et ainsi de suite, sans y voir une cohérence claire dès le début. Enfin ce n'est que mon avis, peut être que l'héritage apporte quelque chose si on se place d'un point de vue ensembliste pour le code. Ça simplifie peut être aussi l'appréhension du code par un humain.

            Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

            • [^] # Re: Héritage...

              Posté par (page perso) . Évalué à 4.

              Par exemple, j'ai l'impression que avec QT, l'héritage est très utilisé, mais brouille peut être un peu les pistes.

              Un des gros intérêt de l'héritage, c'est le polymorphisme et c'est pour ça que Qt l'utilise beaucoup, parce qu'il est nécessaire de connaitres les méthodes implémenté par les éléments graphiques pour pouvoir les intégrer.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Héritage...

            Posté par . Évalué à 0.

            Et c'est quoi les utilisations saines?

            En 10 ans de dev intensif, jamais je ne me suis dit "pinaise, l'heritage multiple simplifierais mon probleme".

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

            • [^] # Re: Héritage...

              Posté par . Évalué à 4.

              Dans 99% des cas je dirais les mixins.

              Le meilleur exemple que j'ai sous la main c'est le module Enumerable de Ruby Extrait:

              The Enumerable mixin provides collection classes with several traversal and searching methods, and with the ability to sort. The class must provide a method each, which yields successive members of the collection

              Si tu défini une collection personnalisée tu n'est pas obligé d'hériter de Array ou Hash pour récupérer toutes les méthodes qu'on trouve sur les collections.

              Même genre en python avec les Threading/Forking servers.

        • [^] # Re: Héritage...

          Posté par . Évalué à 2.

          scala possède une concepte assez surprenant qui consiste a avoir un héritage dyanmique (new ClassA() extends ClassB grosso modo). Je l'ai jamais utilisé mais peut être que ça apporte un vrai plus.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Héritage...

            Posté par . Évalué à 2.

            Dans Lisaac, l'exemple était sur Isaac OS qui pouvait avoir des drivers de hardware héritant d'un bus PCI ou USB dynamiquement. Le but est de pouvoir traiter tous les composants PCI ou tous les composants USB d'un coup.

            "La première sécurité est la liberté"

  • # Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

    Posté par . Évalué à 7.

    Pour commencer, une précision : je "développouille". Je n'ai jamais écrit de codes gigantesques ou travaillé dans des équipes de développement. Toujours est-il que j'aime automatiser tout ce qui peut l'être et que, quand le besoin s'en fait sentir, je code de petits utilitaires (quitte à avoir la doc du langage sur les genoux si je le découvre). J'ai eu l'occasion d'approcher la programmation orientée objet dans un contexte scolaire et les années de programmation procédurale que j'avais déjà m'ont toujours fait dire aux enseignants : "Bof, c'est juste une organisation différente du code. Je vous fait la même chose sans objets". Personne ne m'a jamais exposé la chose de telle façon que je finisse par dire "Woah... Comment j'ai pu vivre tout ce temps sans ça..."

    Petit défi donc : quelqu'un saurait-il dans l'assemblée "vendre le concept" de programmation orientée objet ? Qu'est-ce qui devrait le rendre incontournable et faire rougir de honte les réfractaires qui, semble-t-il, se débrouillent pourtant très bien sans ?

    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

      Posté par . Évalué à 9.

      À l'usage, je pense qu'il n'y a pas de « meilleur style de programmation » et qu'en fait, le paradigme à adopter est celui qui se rapproche le plus des données que tu souhaites manipuler.

      Bof, c'est juste une organisation différente du code. Je vous fait la même chose sans objets"

      Ah, mais tout est là : la programmation orientée objet est avant tout une histoire de conception et même si un langage orienté objet en lui-même est quand même préférable au quotidien, un modèle bien conçu peut virtuellement être implémenté ensuite dans n'importe quel langage. C'est ce que tente GTK, par exemple, même si ses casts incessants finissent par devenir lourdingues à force. Tu es donc peut-être le M. Jourdain de la POO.

      Pour le reste, tu peux essayer le raisonnement par l'absurde. Je ne sais pas quels langages tu utilises, mais essaie par exemple de programmer en C sans jamais recourir aux structures, par exemple. On se rend compte alors que ces structures sont en fait un embryon de programmation orientée objet, dans le sens où l'on réunit sous une même entité tous les attributs d'une chose identifiée et délimitée.

      L'exemple par lequel on commence souvent sont les nombres complexes. On peut passer sur le fait que tu ne puisses pas directement, en C, utiliser les opérateurs habituels -,+,*,/ dont tu fais un usage quotidien sur les nombres ordinaires. Mais même en définissant une bête fonction AddComplex (a_real,a_imag,b_real,b_imag), comment fais-tu pour renvoyer à la fois la partie réelle et la partie imaginaire ? Tu te retrouves à devoir ajouter deux pointeurs de variables dans tes arguments pour stocker le résultat.
      Imagine un programme scientifique entier écrit de cette façon, toujours sans structure. C'est faisable, mais c'est très lourd, et cela nécessite une grande rigueur en amont, à cause d'une raison simple : le langage en lui-même n'étant pas adapté, la conception se fait en amont en suivant une méthode qui s'y substitue.

      • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

        Posté par . Évalué à 0.

        comment fais-tu pour renvoyer à la fois la partie réelle et la partie imaginaire ?

        euh je retourne la structure pourquoi?
        Le problème se pose lorsqu'il y a des pointeurs dans la structure

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

          Posté par (page perso) . Évalué à 2.

          Le monsieur a dit « sans structure ».

          • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

            Posté par . Évalué à 5.

            Il n’est peut-être pas d’accord avec l’idée que les structures sont « des embryons d’un objet ». En tout cas c’est mon avis : les structures sont juste une structure de donnée qui permet, à l’instar d’un tableau, de regrouper plusieurs variables de types différents (contrairement à un tableau). Mais elles n’ont rien à voir avec la programmation objet : pas de lien particulier entre code et structure de donnée, pas de restriction d’accès aux membres de la structures, encore moins tout ce qui peut faire la force de la programmation objet…

            Considérer le cas contraire revient à considérer tout code comme objet, où chaque variable, même de type le plus simple qui soit, est un objet qu’on manipule…

            • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

              Posté par . Évalué à 6.

              Considérer le cas contraire revient à considérer tout code comme objet, où chaque variable, même de type le plus simple qui soit, est un objet qu’on manipule…

              C'est ce que font les langages objets où même l'entier est un objet comme un autre.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                Posté par . Évalué à -2.

                hou la toi tu n'as jamais fais de java.
                Il y a une différence monstre entre

                int plop=126;
                int ploc=126;
                Integer pico=new Integer(126);
                Integer nano=new Integer(126);
                plop++ == ploc++; // true
                pico++ == nano++; // FALSE
                plop++ == ploc++; // true
                pico++ == nano++; // TRUE
                plop++ == ploc++; // true
                pico++ == nano++; // *FALSE*
                

                Et oui je sais sur Integer faut utiliser .equals. == est une égalité sur les références pour les type objets (string, leopard, voiture...) et une égalité de valeur pour les types primaires (int, float...)

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                Posté par . Évalué à -3.

                hou la toi tu n'as jamais fais de java.
                Il y a une différence monstre entre

                int plop=126;
                int ploc=126;
                Integer pico=new Integer(126);
                Integer nano=new Integer(126);
                plop++ == ploc++; // true
                pico++ == nano++; // FALSE
                plop++ == ploc++; // true
                pico++ == nano++; // TRUE
                plop++ == ploc++; // true
                pico++ == nano++; // *FALSE*
                

                Et oui je sais sur Integer faut utiliser .equals. == est une égalité sur les références pour les type objets (string, leopard, voiture...) et une égalité de valeur pour les types primaires (int, float...)

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

              Posté par . Évalué à 4.

              les structures sont juste une structure de donnée qui permet, à l’instar d’un tableau, de regrouper plusieurs variables de types différents (contrairement à un tableau).les structures sont juste une structure de donnée qui permet, à l’instar d’un tableau, de regrouper plusieurs variables de types différents (contrairement à un tableau).

              Non, ce n'est pas tout-à-fait exact. Ça, ce serait plutôt le « array » du PHP.

              Mais elles n’ont rien à voir avec la programmation objet : pas de lien particulier entre code et structure de donnée, …

              Eh si, justement : le type. En C, en tout cas. Une structure définie en C correspond à un nouveau nom de type, et le compilateur ne te laissera pas passer un autre type de donnée ou une structure différente sans se plaindre. Ceci garantit à la fonction qui utilise l'instance de cette structure que toutes les variables sous-jacentes sont disponibles (après, qu'elles aient été initialisées correctement, c'est une autre histoire).

              pas de restriction d’accès aux membres de la structures, encore moins tout ce qui peut faire la force de la programmation objet…

              Oui, mais justement : la « programmation orientée objet », c'est le fait d'orienter la conception de son code et l'organisation de ses données autour d'une notion. Et toutes les facilités dont tu parles ont émergées d'elles-mêmes une fois les choses présentées de cette façon.

              • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                Posté par . Évalué à 0.

                Eh si, justement : le type.

                Où on en revient à ce qu'il a dit : à moins de considérer les int, char, int*, float, double comme objet, les type structure, et soyons fous union, ne sont pas des objets.

                et le compilateur ne te laissera pas passer un autre type de donnée ou une structure différente sans se plaindre.

                ah bon?????
                C'est pourtant à ça que serve les cast (ahhh les joies du void* ); ce qui est quand même pratique car s'il le compilo râlait dès qu'on faisait un malloc, y aurait un bon paquet de truc inutile à chaque compile ^^

                Ceci garantit à la fonction qui utilise l'instance de cette structure que toutes les variables sous-jacentes sont disponibles

                Mon petit doigt me dit que union vient foutre la merde dans ce souhait pieux :D

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                  Posté par . Évalué à 3.

                  Perso j'ai même du mal le C comme un langage typé, quoiqu'on déclare ça ne fait que réservé une zone de la stack que l'on malmène comme on veut.

                  • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                    Posté par . Évalué à 5.

                    Et ça change quoi ?

                    Les types en C existent et sont reconnus par le compilateur, qui se plaint s'ils ne correspondent pas. Le fait que tu puisses explicitement demander à écrire dans une zone mémoire ne regarde que toi, ensuite. Le compilo et le langage qu'il traite n'ont rien à voir dans l'affaire…

                    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                      Posté par . Évalué à 2.

                      Ben non justement, enfin certains compilos surement, mais là en testant vite fait et en -Wall, je fais n'importe quoi avec mes types, et au mieu le compilo gueule lorsque je file un pointeur au lieu d'un entier. C'est pas obligatoirement une critique, ça apporte une certaine souplesse, mais à mon avis c'est source de bugs

                • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                  Posté par . Évalué à 3.

                  ah bon????? C'est pourtant à ça que serve les cast (ahhh les joies du void* ); ce qui est quand même pratique car s'il le compilo râlait dès qu'on faisait un malloc, y aurait un bon paquet de truc inutile à chaque compile ^^

                  C'est bien ce que je dis : tu es obligé de faire un cast explicite pour convertir un type dans un autre avant de le passer à ta fonction. Dans ce cas, tu ne pourras pas dire que le compilateur ne t'as pas prévenu. C'est bien toi qui lui dit alors « Non, mais c'est bon, je sais ce que je fais ». Et encore, ça passe quand tu fais un cast sur un pointeur de structure. Si tu passes la structure elle-même, tu ne peux pas la transtyper directement vers une autre, et ça ne compilera pas du tout.

                  A contrario, tu peux caster de la même façon les instances de variables d'un langage orienté objet. Donc l'argument ne tient pas, ici.

                  Mon petit doigt me dit que union vient foutre la merde dans ce souhait pieux :D

                  Absolument pas.

                  « union » permet de passer une instance de quelque chose dont le type est l'un de ceux énumérés par « union ». Un exemple assez parlant de combinaison struct/union sont les XEvent de X-Window. XEvent est une union de structures plus spécialisées comme XKeyEvent, XButtonEvent, XMotionEvent, XExposeEvent, etc. et qui partagent toutes un membre commun initial en début de déclaration , «int type », qui en plus est lui-même inclus par l'union. Et comme le C garantit que les adresses des membres d'une structure progressent dans l'ordre où ils ont été déclarés et que le padding ne peut se trouver qu'après un membre (C99 6.7.2.1§13), alors on est sûr que ce membre sera bien commun à XEvent et toutes les autres structures unies en dessous, quel que soit le compilateur.

                  À ce stade,

                  — la totalité de l'objet est donc transmis lorsque X-Window émet un événement ;
                  — il contient la totalité des informations qui le décrivent (comprendre : ce n'est pas un message qui invite le programme à aller se renseigner) ;
                  — « XEvent » contiendra toujours l'événement en entier même si la norme évolue (il faudra recompiler le programme mais pas le réécrire) ;
                  — même s'il faut consulter « type », le programme peut savoir de façon déterministe quel objet il a reçu ;
                  — Une fonction faite pour traiter un événement en particulier aura besoin que tu lui passes, non pas XEvent, mais l'un de ses membres explicitement, qui lui a le type qui correspond à la signature de la fonction. Donc, tout le contrôle peut être fait à la compilation, et il n'y aucun magic cast qui entre en jeu pour faire fonctionner le modèle.

                  À lire un autre de tes commentaires, il semblerait que, pour toi, un objet est une classe qui dérive de Object, par opposition, donc, aux types natifs. Si c'est bien le cas et que c'est là, pour toi, le dogme central de la programmation orientée objet, alors il faudrait au moins que tu pratiques d'autres langages de manière sérieuse pour te faire une idée objective… (sans mauvais jeu de mot).

                  • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                    Posté par . Évalué à 0.

                    Alors en non objet j'ai fait du
                    * fortran
                    * COBOL (heureusement je n'en fais plus)
                    * bash (et pas qu'un peu)
                    * perl (mais sans me servir des trucs objets)
                    * C
                    * caml (et pas Ocaml)
                    * lisp (enfin elisp plutôt)
                    Et si oui on peut faire de l'objet en perl, et que les structures peuvent s'en approcher, c'est très loin de ce qu'on peut faire en POO, ou alors faut faire de l'utilisation avancé avec des pointeur de fonctions contenus dans la structure)
                    Alors oui, on peut faire de la programmation qui s'en rapproche, et ça m'arrive de le faire, mais si j'ai besoin des mécanismes objets, j'utilise du C++.

                    considérer que le C est objet parce qu'il permet d'agréger des données entre elle c'est un poil poussé il te manque quand même
                    * le constructeur
                    * le polymorphisme
                    * le destructeur (si ce n'est pas automatique et qu'il faut appeler manuellement une fonction pour libérer des connerie d'une variable de la pile, c'est de la bidouille)
                    * le coté généricité fourni par les template (les macros, ça fait pas vraiment parti du langage). Alors y a moyens de faire des acrobaties, mais faut faire super gaffe

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                      Posté par . Évalué à 3.

                      Je n'ai pas dit le contraire.

                      J'ai dit que, d'une part, la programmation orientée objet était avant tout une histoire de conception avant d'utiliser un langage lui-même orienté objet et que, d'autre part, quand on commençait à utiliser les structures pour réunir sous une même égide les différents attributs d'une entité donnée (ex : complexe), c'était un embryon de programmation orientée objet.

                      C'est bien ça que l'on a dit dès le départ.

                    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

                      Posté par . Évalué à 2.

                      Et si oui on peut faire de l'objet en perl, et que les structures peuvent s'en approcher, c'est très loin de ce qu'on peut faire en POO, ou alors faut faire de l'utilisation avancé avec des pointeur de fonctions contenus dans la structure)

                      J'ai toujours cru que le principe des pointeurs de fonction membres étaient quelque chose qui "cassait" la POO, je veux dire que la POO pure n'accepte pas ce genre de concept. Parce qu'il est sémantiquement mauvais de chercher à appeler une méthode d'un objet sans toucher à l'objet. Il existe des mécanismes pour sans passer peut être un peu plus verbeux mais pas vraiment plus complexes.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # POO en Perl

                      Posté par . Évalué à 1.

                      Et si oui on peut faire de l'objet en perl, et que les structures peuvent s'en approcher, c'est très loin de ce qu'on peut faire en POO, ou alors faut faire de l'utilisation avancé avec des pointeur de fonctions contenus dans la structure)

                      ???
                      Tu as loupé des trucs, notamment bless (c’est la fonction qui attache un objet à sa classe, appelée normalement dans le constructeur).

                      En fait, c’est tout le contraire de ce que tu dis : il y a ce qu’il faut en Perl (5) pour faire tout ce qui est classique en POO (y compris des destructeurs, pas comme en Ruby), mais par contre, il n’y a pas de structures (dans le sens où tu sembles l’entendre, qui ressemble à ce que c’est en C).
                      À croire que tu te trompes de langage...

                      Pour la base de la POO en Perl, voir par exemple .

                      Cela dit, il paraît que la couche objet d’origine de Perl 5 (avec quelques aspects un peu artisanaux) n’est plus à la mode et que le dernier truc à la mode, c’est Moose.

                      Enfin là, je fais référence à Perl 5 (le plus utilisé pour l’instant). Perl 6 est un autre langage...

                      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

                      • [^] # Re: POO en Perl

                        Posté par . Évalué à 1.

                        je parlais de la POO en C pur ; lorsque j'ai besoin d'un truc nécessitant de l'objet, j'ai rarement besoin du perl ;)

                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

      Posté par . Évalué à 3.

      j'ai appris l'intérêt au cours d'un stage Java :
      - il s'agissait d'écrire un monopoly,
      - les spécifications sont venues au gré de l'avancement du cours,
      - nous étions assistés par le prof pour l'analyse (classe en particulier),

      Pour ma part, ne connaissant pas l'objet avant, j'avais toujours la plus grande peine du monde :
      - à adapter un logiciel, si je n'avais pas pensé à tout et dès le début ; parfois une nouvelle spécification devenait très difficilement réalisable à cause de la conception initiale,
      - au contraire, en POO, il est souvent bien plus facile de reprendre et d'ajouter quelques fonctions ; généralement on appelle cela des verrues, des patchs, ...

      Les premières difficultés consistent à isoler les classes, les méthodes puis les interactions entre objets. Mon expérience actuelle est basée principalement sur PHP ; je l'utilise a toutes les sauces et principalement pour de la ligne de commande, un peu comme certains le feraient avec Perl, python, ruby. Je n'ai pas un très bon niveau en POO, mais globalement, j'ai toujours réussi à faire ce que je voulais assez simplement. Ce n'est pas le cas avec le C, autre langage que j'ai utilisé avant.

      Des mécanismes d'encapsulation des données sous forme de classes (structure) existent en particulier avec les librairies Gtk. Cela existait aussi avec Xt et Motif. L'écriture de nouvelles classes était particulièrement fastidieux. J'ai fait un peu de php-gtk2 il y a quelques temps. Il était vraiment trivial de spécialiser des objets et avec qq lignes de code.

      Pour bien répondre à la question, il faudrait proposer un exercice.

    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

      Posté par (page perso) . Évalué à 4.

      Salut,

      c'est pas une histoire de meilleur concept. Ce sont juste des conceptions différentes.
      À partir de là, je ne crois qu'il y ait besoin de te vendre quoi que ce soit. Et oui bien sûr, on peut se débrouiller sans et oui tout ce qu'on fait dans un concept, on peut le faire dans un autre. Il suffit de voir tout ce qu'ont fait des millions de développeurs dans le monde, qu'ils utilisent une logique impérative, fonctionnelle, objet, déclaratif, etc. en-veux-tu-en-voilà (et avant ça y a des dizaines d'années, des programmes étaient entièrement écrit en assembleur, c'est dire si on peut tout faire quel que soit la "famille" du langage).

      Par contre c'est simplement que certains concepts s'adaptent plus aisément à certains problèmes que d'autres.
      Par exemple, si je développe un programme où les données rentre, sont traitées, sortent constamment, je vois tout de suite du fonctionnel: t'as une entrée, une sortie et une boîte noire au milieu.
      L'objet est vraiment très agréable et permet des designs très "évident" (donc agréable à utiliser) pour tous les problèmes avec des "entités", que l'on peut conceptualiser, qui ont des caractéristiques et qui peuvent effectuer certaines actions.
      Etc.

      En fait il faut juste voir des classes de problématiques et ce qui permettra de faire la plus jolie et évidente API (soit parce que c'est le but final, ou soit parce qu'on va l'utiliser soi-même). Ça n'empêche pas qu'il y a en fait 1000 autres designs possibles pour la même fonctionnalité et qu'un autre design dans une tout autre logique peut également être très agréable.
      C'est juste une question de choix.

      Enfin y a la question du langage à utiliser. Personnellement je m'adapte. Quand j'écris en OCaml par exemple, je pense essentiellement soit classe soit fonctionnel. Mes programmes n'auront (presque) jamais la moindre boucle, je préfère les retours de fonctions aux références, et je m'arrange pour que mes fonctions récursives soient toujours terminales (sauf si la complication apportées ne vaut pas le gain. Ça arrive parfois, par exemple pour les fonctions qui auront des appels récursifs peu profond par design).
      Si par contre j'écris en C, je fais des boucles, des paramètres par références et du massivement impératif comme tout le monde.
      Il faut savoir profiter des forces d'un outil.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?

      Posté par . Évalué à 9.

      "Bof, c'est juste une organisation différente du code. Je vous fait la même chose sans objets"

      Bien sur que tu peux, les deux langages etant turing complet, tu peux faire strictement la meme chose, idem en assembleur ou en brain fuck.

      La question pertinente est combien de temps et quel effort il aura fallu pour arriver au meme resultat? Pour quelle robustesse? Et ensuite, quelle souplesse as tu dans la maintenance et les evolutions qui ne manqueront pas d'arriver?
      L'imperatif le plus courant, le C, apporte en plus son lot de problemes dus a son aspect bas niveau qui peut te peter a la gueule assez facilement.

      L'objet apporte une facon de modeliser les problemes qui correspond mieux a ce qu'on voit dans le monde reel.
      Un moteur est compose de pieces (donnees), un comportement (vroum vroum) et une interface publique (pour le champignon et le glouglou du moteur). Il encapsule un comportement pour le cacher du reste du monde qui n'en a cure (ton champignon marchera pareil que ca soit un diesel, un v12 ou un moteur de meule).

      On a pas d'un cote une structure de donnees et de l'autre un set de logique, les deux sont lies.

      Une modelisation plus proche du monde reel veut dire une modelisation plus simple pour l'humain qui, quoi qu'on en dise, vit dans le monde reel, est fortement influence par le monde reel et a un instinct de reptilien du monde reel. Ca veut dire une implementation plus simple par le reptilien sus cite, et une comprehension plus simple par ses pairs reptiliens.

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

  • # Programmation Orienté CoinCoin

    Posté par . Évalué à 10.

    Le Duck Typing semble tout désigné pour la programmation des coincoins !

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

  • # Il y en a d'autres

    Posté par (page perso) . Évalué à 9.

    ce journal part d'un contenu trouvé sur rstat.us, le Tweeter libre.

    rstat.us, ce n'est pas le Tweeter libre, il y a aussi Identi.ca (basé sur StatusNet) qui existait bien avant lui.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Plusieurs

    Posté par . Évalué à 10.

    De ce que je me rappelle de mes cours d'objet a la fac, en gros, on a t'apprends "un objet, c'est comme un struct c, sauf qu'a la place de definir les function a part, tu les mets a cote de ta struct. Ah, et pis on peut heriter en objet, ca c'est bien." Du coup les etudiants apprennent a heriter comme des porcs et paf. Ca aide pas :)

    Un des gros problemes c'est que la plupart des devs ne savent pas encapsuler. Ca se limite generalement a ce qu'on leur a appris a l'ecole, a savoir "rendre les champs prives et mettre des getters/setter publics dessus".

    Je passe mon temps a batailler pour convaincre qu'un code du genre:

    public class FooService {
    public void performBla(Bar bar, Bla bla){
    if(bar.getA() == bla.getB()){
    bar.setB(null);
    }
    bla.setBar(bar);
    }
    }
    

    Pourquoi? Tout passe par bar. La logique appartient a bar. Ce code est un pur code c. Les objets sont des structs et la methode est une function C qui manipule ces structs. Et pour beaucoup, ca c'est du code objet (certains diraient meme de qualite).

    Les concepts de base d'encapsulation genre un root aggregate qui s'occupe d'implementer les regles de manipulations d'une "liste" plutot que d'exposer au monde entier les regles de manipulation de la dite liste sont inconnus de beaucoup. Et pourtant, ca doit etre le pattern le plus utile en development "entreprise". C'est extremement rare de devoir manipuler directement une liste qui n'appartient pas a l'objet courant, et pourtant je vois ca pourtant dans le milieu.

    Certains me regardent meme avec des yeux tout ronds quand je suggere que les maps sont le demons et totalement injustifiees dans 90% des cas ou elles sont utilisees et devraient etre remplacees par un root aggregate d'objets haut niveau, bien plus puissant, souple et fiable.

    L'autre effet de bord du manque d'encapsulation c'est que le code devient illisible et masque toute la logique metier. 99 things every developer should know en montre un exemple du genre:

    if(portfolio.getBrokers().get(brokerId).length != 0){
    blabla
    }
    

    la ou ca devrait etre un :
    if(broker.canSeePortfolio(porftolio)){
    // blabla
    }
    

    Un bug dans la premiere version est dur a detecter a la relecture alors que ca va etre evident dans le deuxieme. Pourquoi? Absence d'encapsulation, la logique de visibilite d'un portfolio est extraite de l'objet et repandue partout dans le code, ce qui a pour effet de bord de ne pas pouvoir utliiser le langage du domaine dans le code. La deuxieme version se lit comme une phrase naturelle ('fin presque...) et ca saybien.

    Mais ca va plus loin que ca.

    La delegation est laissee de cote face a l'heritage, et ca c'est mal. Bon, a leur decharge, Java supporte mal la delegation.

    Et pire encore, l'heritage est sur utilise, pour de mauvaise raisons (les deux plus courantes: heritage pour heriter de donnees au lieu de composer, et heritage simplement pour differencier 2 types d'objets tres proches mais legerement differents). J'ai bosse sur un projet recemment avec une hierarchie de 7 niveaux. L'effet de bord le plus visible c'est qu'on devait utiliser des generics comme des gorets pour s'en sortir, et tout le monde sait que les generics java sont tres tres tres mauvais. Un peu de rafactoring et paf, ca tombe a 2 niveaux, plus de generics, un bon millier de lignes de code purement et simplement supprimees du source. Et accessoirement, un code achement plus simple a lire.

    Les pseudos pattenrs a la con J2EE de l'eopque doree du debut des annees 2000 ont fait beaucoup de mal. Surtout quand tout ce dont on avait besoin en fait, c'etait de l'inversion of control. Une fois spring amene dans un projet, n'importe quel projet J2EE se limite a qq patterns usuels sorti du Gang of four et roule ma poule.

    MVC a ete particulierement mal interprete dans le monde java, ou la plupart des devs l'ont compris comme "ma vue, c'est ma jsp, mon modele c'est un objet avec attributs et sans aucune methode, et mon controller c'est un foutoir sans nom ou je met des "services" qui implementent la logique metier".

    Ca s'appelle l'anemic object anti pattern, c'est un anti pattern, et le resultat direct c'est qu'on fait de la programmation imperative avec des C structs et pas de l'objet.

    Alors, certes, le prototypage apporte une certaine souplesse, qui est appreciable dans certains cas, nefaste dans d'autres. Mais ca change pas le fond du probleme, le mec qui ecrit le code ne saura probablement pas s'en servir. Donne du javascript a n'importe quel dev Java de base, il te pondera de la merde pareille.

    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: Plusieurs

      Posté par (page perso) . Évalué à 4.

      Je l'ai peut-être déjà utilisé sans connaitre son nom (ou pas) mais je ne connais pas le design pattern "root aggregate d'objets haut niveau" (en tant que remplaçant de Map).

      As-tu un exemple de code par exemple ? J'ai tapé (et il n'a pas aimé) sur Google "root aggregate" mais je n'ai rien eu de bon.

      • [^] # Re: Plusieurs

        Posté par . Évalué à 1.

        Avec "design pattern root aggregate" dans l'ami Google, je trouve pas mal de résultats assez clairs

      • [^] # Re: Plusieurs

        Posté par . Évalué à 3.

        L'idee c'est qu'un ensemble d'objets est lie ensemble par le root aggregate, qui est responsable de fournir des methodes d'acces aux dits objets et maintenir la cohesion du tout en forcant toute manipulation de l'ensemble a passer par lui. T'as un point central d'acces a ces objets, ce qui concentre la logique au bon endroit et permet d'implementer la logique metier proprement.

        T'as bien evidemment toujours le droit de recuperer un seul objet de l'ensemble et le manipuler comme tu veux, mais tu dois le recuperer via le root. Souvent t'as un backpointer vers le parent, qui te permet d'implementer a moindre cout des gardes fous ou d'acceder aux freres de l'objet en question.

        L'interet immediat c'est que ca te garantit que ton graphe d'objet est toujours consistant (au sens anglais, le francais me vient pas a l'esprit, desole), l'autre interet c'est la lisibilite du code, sans compter les trucs habituels, encapsulation donc refactoring facilite, reutilisablite du code etc.

        Pour les maps le gros problemes c'est que c'est un gros sac offrant tres peu de souplesse niveau manipulation, sans compter que ca retire beaucoup de semantique.

        Transforme ca en une liste d'objets liant la cle a la valeur (ce qui te permet en cado bonux de rajouter de la logique sur cette association), le tout lie ensemble par un root aggregate, tu gagnes enormement:
        - clarte, tu as un objet qui a une semantique claire et pas un sac fourre tout
        - lisibilite, les objets exterieurs accedent a tout ce beau monde via des methodes au nom explicite et a la semantique claire (cf l'exemple du portefeuille d'action plus haut ou la premiere version est incomprehensible face a la deuxieme qui est clair comme de l'eau de roche)
        - souplesse, tu peux aisement rajouter/supprimer des attributs sans peter tout ton code
        - puissance tu peux maintenant tres aisement ajouter des methodes donnant un acces plus fin aux elements de la map

        Et en plus t'as transforme une map qui est une structure relativement complexe en liste qui est achement plus simple a manipuler et serialiser (tous les lanagages n'ont pas de maps supportant un objet enmcle, par exemple, ou pas simplement).

        Un livre de chevet indispensable a tout dev objet: domain driven design d'eric evans. Ca changera probablement la vision que les sceptiques ont de l'objet. Et bien evidemment le gang of four.

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: Plusieurs

          Posté par (page perso) . Évalué à 4.

          Je ne vois pas forcément ce que tu veux dire avec la notion de map. Pour moi l'utilisation de la map permet justement d'accéder en O(1) (dans le cas d'une hashmap) à un élément quand tu connais sa clé. Remplacer la map par une liste n'est pas très performant. Du coup je ne suis pas sur de comprendre ce que tu veux dire.

          • [^] # Re: Plusieurs

            Posté par . Évalué à 2.

            A moins que ta list contienne 1 000 000 d'elements, ca va pas faire une grosse difference. Ca va potentiellement meme etre plus lent de calculer ton hash que d'iterer 100 elements d'un tableau.

            Tout depend de ce que tu manipules, mais la performance a pas forcement un gros impact sur tes performances, si ca en a un. Par contre t'as un tres gros gain sur la qualite de ton code.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: Plusieurs

            Posté par . Évalué à 2.

            Je trouvais cette exemple assez clair pourtant:
            if(portfolio.getBrokers().get(brokerId).length != 0){
            blabla
            }
            ->
            if(broker.canSeePortfolio(porftolio)){
            // blabla
            }

            En fait, tu dissimules les manipulations de l'ensemble Map derrière des interrogations métiers. De cette manière , tu n'exposes pas directement un Map avec toutes les manipulations que celui-ci permet.
            De plus, c'est beaucoup plus simple à lire car la programmation est alors très littérale.
            La complétion automatique et l'ensemble des méthodes exposés te permet alors de réutiliser plus rapidement l'objet.

        • [^] # Re: Plusieurs

          Posté par . Évalué à 5.

          ton graphe d'objet est toujours consistant (au sens anglais, le francais me vient pas a l'esprit, desole)

          Cohérent

          (Parce que je sais qu'avoir un mot sur le mot de la langue peut être aussi agaçant qu'une parenthèse pas fermée.

          • [^] # Re: Plusieurs

            Posté par . Évalué à 2.

            avoir un mot sur le mot de la langue

            Le bout que tu cherches est : bout

            (oui, j'ai fait la même erreur que lui, mais moi c'est volontaire :-p )

        • [^] # Re: Plusieurs

          Posté par . Évalué à 4.

          J'ai du mal à voir en quoi les map sont des "sac fourres tout" avec cet exemple. Souvent en java j'utilise des maps privés comme des systèmes d'indexation (et en java, je crois que c'est le seul système d'indexation qui existe), autrement dit, c'est souvent du style map[obj.id] = obj; et je vois pas en quoi c'est incompatible avec la clarté/lisibilité/amour/.... sachant que ça n'a pas beaucoup de différence avec une liste d'objet.

      • [^] # Re: Plusieurs

        Posté par . Évalué à 1.

        Il veut peut-être parler du God object.

        • [^] # Re: Plusieurs

          Posté par . Évalué à 3.

          Non, c'est pas ca. Le root aggregate se concentre uniquement sur la manipulation d'un ensemble clairement defini, pas sur tout et n'importe quoi. Il faut aussi que l'ensemble ait une cohesion et qu'il existe des regles de manipulation dudit ensemble, sinon ca sert pas a grand chose a part rajouter une classe pour rien.

          C'est un concept qu'on retrouve dans la vraie vie. Un ensemble se manipule plus proprement et simplement quand tout se fait un point d'entree designe.
          Une equipe est mieux geree par un chef d'equipe plutot que d'avoir des gens qui prennent des ressources de leur cote.
          Un stock en magasin se doit d'etre gere par quelqu'un sinon ca devient le bordel. J'ai la flemme de chercher mais on peut trouver d'autres exemples.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: Plusieurs

            Posté par (page perso) . Évalué à 1.

            Pour toutes celles et ceux qui souhaiteraient en savoir davantage sur le sujet du Root Aggregate et sur d'autres bonnes pratiques de conception, je vous invite à lire travaux de Eric Evans sur le Domain-driven design et ceux de Martin Fowler.

            Alexandre COLLIGNON

    • [^] # Re: Plusieurs

      Posté par . Évalué à 1.

      D'une manière générale, la conception des programmes informatiques telle qu'elle est trop souvent enseignée en se focalisant sur des détails triviaux et parfois hors sujets (car les sujets difficiles peuvent être et sont le plus souvent dans des domaines totalement distincts) de COO à la C++ ou Java est extrêmement préoccupante et a bien du faire perdre 10 à 20 ans à l'évolution des compétences moyennes des programmeurs.

      Le problème de ce type de conception est qu'elle tend à produire des programmes à l'architecture naives car n'ayant trop peu de structure de plus haut niveau, et l'architecture induite par une simple hiérarchie de classe n'est guère plus structurante qu'une architecture basée sur une programmation par découpage hiérarchique en fonctions (et parfois elle peut même l'être moins). Du coup les étudiants affectés ont la fausse sensation, n'ayant que travaillés pour la plupart sur des projets simples pour lesquels se contenter d'une telle hiérarchie ne pouvait pas plus faire de mal que n'importe quelle autre approche, que le découpage en hiérarchie de classe est une bonne chose quasi-absolue voire même suffit voire même ils sont totalement aveuglés au point de dénigrer des approches supérieures. Certains langages ne facilitent pas la tache en rendant exagérément facile leur approche native et contre intuitifs et nécessitant un apprentissage spécifique les autres patterns, ou encore en fournissant des mécanismes de résolution d'une classe restreinte de problèmes qui "anesthésie" de par la terminologie employé (et quelques fois même par un mauvais enseignement les indiquant là où ils ne suffisent pas) l'utilisateur vis à vis d'une classe plus grande de problèmes, que du coup il ne traite pas, conduisant au fil du temps à une mauvaise architecture irrattrapable (ex : private / protected / public à la C++ n'est pas intrinsèquement une mauvaise chose mais trop souvent c'est employé là ou en fait une vraie structure opaque et de la vraie modularité seraient infiniment supérieures, et ceux dans toutes les phases du développement).

  • # Les Fonctions Génériques

    Posté par (page perso) . Évalué à 1.

    Pour moi, l'intérêt de la POO, ce sont les Fonctions Génériques.

    En Common Lisp, qui dispose d'un des systèmes objets les plus complets, tout fonctionne par la « surcharge ». On définit une fonction générique, par exemple la somme +, puis on la spécialise en différentes méthodes, par exemple une méthode pour additionner les nombres complexes, une méthode pour additionner les réels, une pour les fractions. L'avantage, c'est qu'on peut à tout moment étendre notre fonction générique. Par exemple, je peux définir moi-même une manière de sommer les vecteurs.

    Je n'en parle pas très bien mais c'est, je trouve, un fonctionnement assez différent de ce qui se fait en Java ou en C++. Les méthodes ne dépendent pas des objets : ainsi une méthode qui prend deux objets différents en argument, comme par exemple la somme d'un complexe et d'un réel, ne dépend ni de la classe Complex, ni de la classe Real, mais juste de la fonction générique +.

    Cette manière de programmer est décrite dans le SICP (sans toutefois utiliser le système d'Objets), et dans le PCL.

    • [^] # Re: Les Fonctions Génériques

      Posté par . Évalué à 3.

      Je ne vois pas en quoi c'est différent de ce que l'on fait en C++ avec la spécialisation de méthodes templates.

      • [^] # Re: Les Fonctions Génériques

        Posté par (page perso) . Évalué à 1.

        Je ne vois pas en quoi c'est différent de ce que l'on fait en C++ avec la spécialisation de méthodes templates.

        Je ne programme plus en C++ depuis longtemps, mais de souvenir, on peut surcharger les opérateurs et ce n'est pas la peine d'utiliser des templates pour ça si?

        • [^] # Re: Les Fonctions Génériques

          Posté par . Évalué à 3.

          Je pense que le terme « méthode » ne doit pas avoir la même signification dans les deux langages (de toutes façons, en C++, ce sont des « fonctions membres »).

          Sinon, l'intérêt du template est justement de ne pas avoir à réécrire le code correspondant. Les types génériques dans le code sont remplacés par celui que tu spécifies et, seulement alors, la fonction est compilée dans cette version, ce qui, généralement, produit du code machine complètement différent selon l'objet manipulé alors que l'algorithme reste rigoureusement identique.

          Ensuite, le programmeur peut ensuite écrire lui-même certaines versions de la fonction template pour certains types explicitement. C'est utile, par exemple, si tu fais un container à objet. La plupart du temps, tu stockeras des pointeurs ou des références vers tes (gros) objets. Mais si ce sont des caractères individuels que tu comptes stocker, alors il vaut mieux les enregistrer directement puisque les pointeurs qui les référencent seront entre 4 et 8 fois plus gros que les caractères eux-mêmes.

          Mais les templates ne sont pas liés en eux-mêmes à la surcharge des opérateurs, ni à celle des fonctions membres, d'ailleurs.

  • # Real Programmers use Fortran

    Posté par (page perso) . Évalué à 2.

    Quel est l'avis des programmeurs qui trainent sur LinuxFR sur cette histoire de POO ?

    Fortran ne prend aucune disposition pour faciliter la programmation orientée objet, c'est bien la preuve que cette méthode est inutile. La bible du génie logiciel a été écrite par Ed Post en 1982. Ce texte est à lire d'urgence et tout le reste est à oublier.

  • # La POO

    Posté par (page perso) . Évalué à 5.

    C'est CACA.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.