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 Tristramg . É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.
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par Jux (site web personnel) . Évalué à 1.
La notion de concepts (cf url 1) (interface à la Go) a d'ailleurs été proposé pour le nouveau standard C++0x. D'après wikipedia, la décision n'a pas encore été prise quant à l'inclusion ou pas dans le standard. En gros un concept permet de dire que tel paramètre générique doit fournir tel ensemble de fonctions.
Dans tous les cas, je trouve l'idée vraiment bonne. Ca permettrait de formaliser ce qui se fait aujourd'hui avec les templates et qui n'est pas toujours très lisible.
[1] http://en.wikipedia.org/wiki/Concepts_(C%2B%2B) (comment met-on un lien vers une url qui se termine avec une parenthèse ?)
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par Étienne . Évalué à 4.
La décision a été prise de ne pas l'inclure lors de la réunion du WG21 de juillet 2009 (voir par exemple http://herbsutter.com/2009/07/21/trip-report/ pour des explications de Bjarne Stroustrup)
Etienne
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par monsieurmoche . Évalué à 2.
En effet.
Et on était tous bien triste, ce jour là…
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par moi1392 . Évalué à 5.
En C++ on aime bien utiliser des templates pour faire du polymorphisme
c'est de la généricité, pas du polymorphisme.
Le polymorphisme est un mécanisme dynamique qui permet d'aiguiller le comportement d'opérations en fonction de des objets que l'on traite. Ces objets doivent avoir un lien entre eux que l'on nomme héritage.
La généricité est un mécanisme statique qui permet de réutiliser du code dans le contexte de différentes classes qui partagent une interface. L'interface partagée peut-être vide, c'est le cas des conteneurs de la stl, par exemple.
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par BFG . Évalué à 2.
Pourtant, la dénomination "polymorphisme statique" existe bel et bien pour désigner les templates de C++. Même Robert Martin emploie ces termes.
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par zul (site web personnel) . Évalué à 1.
J'aime bien les notions de polymorphisme paramètrique ("template") vs polymorphisme d'inclusions ("héritage")
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par Perthmâd (site web personnel) . Évalué à 5.
Ah bon ? Pourtant :
⊢ λx.x : ∀α.α → α
c'est bien une fonction polymorphe, pourtant, je ne vois nulle trace de décision dynamique en fonction du type... On a beau appeler polymorphisme des choses qui n'ont rien à voir, on utilise quand même des adjectifs pour les différencier : ad-hoc vs. paramétrique, ici.
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par Shuba . Évalué à 2.
Pour les gens qui parlent pas le lambda calcul, ça veut dire quoi?
[^] # Re: Ça rejoint les typeclass de haskell, template du C++, Go
Posté par Thomas Douillard . Évalué à 5.
A vue de nez ça définit la fonction identité, qui renvoie son paramètre. De manière complètement indépendante du type du paramètre, du coup, elle est identique pour tous les types.
# Poooo!
Posté par pyknite . É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 woopla . É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 Thomas Douillard . É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 Gniarf . Évalué à 6.
c'est reloud ces \ qu'il faut doubler pour qu'ils ne sautent pas
[^] # Re: Poooo!
Posté par barmic . É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 moules . É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 claudex . É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 moules . É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 claudex . É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 barmic . É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 moules . É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 claudex . Évalué à -1.
Ç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 moules . É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 claudex . É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 Gniarf . Évalué à 7.
et son succès parmi eux est fla-grant.
[^] # Re: Poooo!
Posté par Michaël (site web personnel) . É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 Batchyx . É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 barmic . É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 MrLapinot (site web personnel) . É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 Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Duck typing
Posté par Thomas Douillard . Évalué à 2.
C'est son alter égo version typage statique.
[^] # Re: Duck typing
Posté par MrLapinot (site web personnel) . Évalué à 1.
Le typage non-statique n'existe pas.
(On appelle ça un segfault, sauf qu'on l'enrobe dans une exception.)
[^] # Re: Duck typing
Posté par eric gerbier (site web personnel) . Évalué à 0.
même en perl ? :)
[^] # Re: Duck typing
Posté par Thomas Douillard . Évalué à 0.
C'est son alter égo version typage statique.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Duck typing
Posté par MrLapinot (site web personnel) . É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 Jean B . Évalué à 2.
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 MrLapinot (site web personnel) . Évalué à 4.
C'est exactement la définition du (sous-)typage structurel.
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 lasher . É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 MrLapinot (site web personnel) . É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 :
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 Michaël (site web personnel) . Évalué à 3.
C'est exactement l'analyse que fait le compilateur OCaml lorsqu'il lit quelque chose comme ça:
Après évaluation
sendest une fonction acceptant tout objet admettant une méthodesendet 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:
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 Lutin . Évalué à 10.
Le duck typing c'est facile:
\_o< COIN !
[^] # Re: Duck typing
Posté par chimrod (site web personnel) . Évalué à 8.
pan ! pan !
[^] # Re: Duck typing
Posté par Obsidian . Évalué à 6.
Ça, c'est l'implémentation du destructeur, en particulier.
# Titre pathétique
Posté par Benoît Sibaud (site web personnel) . É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 Yusei (Mastodon) . É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 moules . É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 scullder . Évalué à 4.
Moi aussi je dénonce et je demande le retrait du mot étudiant du titre !
[^] # Re: Titrepathétique
Posté par Yusei (Mastodon) . Évalué à 2.
En fait il suffirait de retirer le "problème" pour ne plus risquer de choquer.
[^] # Re: Titrepathétique
Posté par vazco . É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 Thomas Douillard . É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 Gniarf . É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 Jean B . Évalué à 10.
C'est déjà très couru, seulement on dit pas étudiant mais stagiaire.
[^] # Re: Titre pathétique
Posté par scullder . Évalué à 4.
Remarque, la qualité du code est peut être proportionnelle au salaire et au coefficient de casse gueulisme du sujet.
# Rigidité
Posté par Yusei (Mastodon) . Évalué à 10.
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 barmic . Évalué à 5.
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 Yusei (Mastodon) . É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 scand1sk (site web personnel) . É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 Yusei (Mastodon) . É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 scand1sk (site web personnel) . É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 Yusei (Mastodon) . É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 pasScott pasForstall . É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 Marc Dauwn . É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 scand1sk (site web personnel) . É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 Michaël (site web personnel) . Évalué à 4.
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.
Ç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 psychoslave__ (site web personnel) . É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 Anonyme . É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 barmic . É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 swilmet . É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.
# Méthodes abstraites ou finales
Posté par scand1sk (site web personnel) . É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 Serge Julien . É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 MyLordAngus . É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 Sébastien B. . É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 lasher . É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 fearan . É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 dave . É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 claudex . Évalué à 4.
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 pasScott pasForstall . É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 Jean B . É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:
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 lolop (site web personnel) . Évalué à 3.
C'est malin, à lire des journaux LinuxFr on finit par faire du code.
http://perso.limsi.fr/pointal/python:delegator
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Héritage...
Posté par barmic . É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 Nicolas Boulay (site web personnel) . É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 AP . É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 Obsidian . É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.
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 fearan . Évalué à 0.
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 Naha (site web personnel) . Évalué à 2.
Le monsieur a dit « sans structure ».
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par nicolas . É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 barmic . Évalué à 6.
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 fearan . Évalué à -2.
hou la toi tu n'as jamais fais de java.
Il y a une différence monstre entre
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 claudex . Évalué à 6.
Je ne crois pas qu'il parlait de Java, il visait plutôt Python par exemple.
« 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: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par barmic . Évalué à 3.
Excuse moi j'aurais du parler de langage objet pur. Java gère des type de base pour les entiers (tout type), les nombre à flottante et les booléen (il y en a d'autre je crois comme les octets), il existe d'autres langages objet (si si je te jure). Je crois par exemple que c'est le cas de Smalltalk.
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 yellowiscool . Évalué à 4.
Ah, qu'est-ce que c'est merdique l'absence d'un truc à la operator= en Java.
Envoyé depuis mon lapin.
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par fearan . Évalué à -3.
hou la toi tu n'as jamais fais de java.
Il y a une différence monstre entre
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 Obsidian . Évalué à 4.
Non, ce n'est pas tout-à-fait exact. Ça, ce serait plutôt le « array » du PHP.
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).
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 fearan . Évalué à 0.
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.
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 ^^
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 Alex . É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 Obsidian . É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 Alex . É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 Obsidian . Évalué à 3.
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.
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 fearan . É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 Obsidian . É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 barmic . Évalué à 2.
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)
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par fearan . Évalué à 2.
en fait si tu veux faire un truc qui ressemble a de la POO en C, tu n'as pas trop le choix pour le polymorphisme.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # POO en Perl
Posté par Arthur Accroc . Évalué à 1.
???
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 là.
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...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: POO en Perl
Posté par fearan . É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 Marc Quinton . É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 Jehan (site web personnel, Mastodon) . É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 Etienne Bagnoud (site web personnel) . Évalué à 5.
En C les paramètres sont toujours passés par valeur, il n'y a pas de "par référence". On le simule en utilisant les pointeurs, mais si tu veux modifier le pointeur lui-même, dans une fonction, tu vas passer un pointeur de pointeur. Voir aussi : http://c-faq.com/ptrs/passbyref.html
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par phoenix (site web personnel) . Évalué à 4.
Par contre en C++ tu peux faire du passage par référence au lieu d'écrire
appelé
tu peux faire
appelé
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par Guillaume Knispel . Évalué à 2.
Oui mais il s'agit juste de sucre syntaxique pour noter différemment un passage par pointeur. Un passage par référence plus "poussé" permet par ex de s'affranchir de tout problème de durée de vie des variables (et de tout type de variable).
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par pasScott pasForstall . Évalué à 9.
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.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Il y en a d'autres
Posté par claudex . Évalué à 9.
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 pasScott pasForstall . É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:
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:
la ou ca devrait etre un :
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 phoenix (site web personnel) . É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 windu.2b . Évalué à 1.
Avec "design pattern root aggregate" dans l'ami Google, je trouve pas mal de résultats assez clairs
[^] # Re: Plusieurs
Posté par pasScott pasForstall . É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 phoenix (site web personnel) . É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 pasScott pasForstall . É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 syj . É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 pititjo . Évalué à 5.
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 windu.2b . Évalué à 2.
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 Batchyx . É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 rewind (Mastodon) . Évalué à 1.
Il veut peut-être parler du God object.
[^] # Re: Plusieurs
Posté par pasScott pasForstall . É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 Alexandre COLLIGNON (site web personnel) . É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 Guillaume Knispel . É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 Rémi Birot-Delrue . É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 Batchyx . É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 Michaël (site web personnel) . Évalué à 1.
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 Obsidian . É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 Michaël (site web personnel) . Évalué à 2.
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.
[^] # Re: Real Programmers use Fortran
Posté par lasher . Évalué à 3.
Il existe une réponse à ça : l'histoire de Mel, un Vrai Programmeur.
http://www.obfuscation.org/deco/hack/StoryOfMel.html
[^] # Re: Real Programmers use Fortran
Posté par Michaël (site web personnel) . Évalué à 1.
Je la connaissais: elle est très marrante aussi :)
[^] # Re: Real Programmers use Fortran
Posté par Obsidian . Évalué à 2.
C'est le bon moment pour replacer ça, aussi :
http://thedailywtf.com/Comments/Perseverance-in-the-Face-of-Change-Requests.aspx#163800
# La POO
Posté par DLFP est mort . Évalué à 5.
C'est CACA.
DLFP >> PCInpact > Numerama >> LinuxFr.org
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.