Merci pour ce retour pertinent et constructif (non).
Ok, je vais détailler ça sera peut-être utile et moins frustrant.
Mais bon, Tu fais un billet d'humeur (non constructif) sur la POO, son usage et son enseignement pourris selon toi, je fais un post d'humeur sur ton billet d'humeur pourri selon moi => où est le problème ?
Les deux phrases m'ayant déclenché cette réaction :
voici un billet sur la programmation orientée objet et pourquoi elle est mal utilisée et enseignée.
et
Si le principe d’encapsulation est correctement respecté (ce qui devrait toujours être le cas en théorie mais ne l’est pas en pratique), l’état interne d’un objet est inaccessible de l’extérieur, et ne peut pas être manipulé directement.
plus le rapide survol des titres :
Un enseignement complètement à la rue (...) l’immense majorité des cours de POO n’expliquent pas ce qu’est la POO : ils expliquent une vision défectueuse de la POO (...) Des langages qui font n’importe quoi.
Donc ça balance sévère et paf, d'entrée une confusion entre deux concepts, l'un fondamental en POO (l'encapsulation), l'autre accessoire (le masquage), je trouve que ça part assez bien pour qu'il ne soit pas nécessaire de continuer et faire savoir que ça vaut pas plus qu'une discussion de comptoir avec Raymond au PMU.
Ça c'est pour expliquer la forme succincte de ma critique dont le fond a semble t'il parfaitement été compris : j'ai pas été mauvais sur le coup en termes de com.
Sur le fond :
Dans les faits, quand on parle d’encapsulation dans le cadre de la POO, c’est pratiquement toujours avec masquage,
Le masquage est un autre concept comme la notion de classe ou de propriété.
Et quand on parle de POO on parle pratiquement toujours dans un contexte de langage à classe (C++, Java, C#.... ) : ça rend la classe implicite ou obligatoire quand on parle POO ? Fuck les prototypes ?
Donc ok, c'est proche et ça va souvent ensemble mais ce n'est ni implicite, ni obligatoire il me semble.
parce qu’une information non masquée a toujours un risque d’être utilisée (au moins lue) hors de son contexte d’encapsulation.
Et alors ? En pratique c'est presque impossible de l'empêcher donc bon...
Le masquage c'est comme la notion de classe ou d'encapsulation (bundling, que j'utiliserai comme terme ensuite, pour éviter la confusion) : un concept.
Après tu l'implémentes (outils) comme tu veux :
- mot clef et mécanisme du langage (ex : private)
- convention de nommage et savoir vivre des codeurs
- menace de mort de l'ordinateur (comme certains registres du TI99 ;) )
Tout pareil pour le bundling :
- mot clefs et mécanismes du langage (ex : class)
- convention de nommage / structures particulières
- il y a surement d'autres méthodes que je ne connais pas
Donc soit tu parles du concept (on peut cacher des choses) soit tu parles des outils (on le rend private), soit tu parles des pratiques (c'est bien/c'est mal).
Là tu nous parles de POO et d'encapsulation au sens concept car c'est dans une définition.
Je ne vois pas du tout ce que la morale ou les outils viendraient faire la dedans.
Surtout, la POO n'interdit pas d'aller utiliser les propriétés et autres comportements : elle se base justement la dessus (via les messages).
Ta définition en deux phrases est d'ailleurs incomplète : il manque les messages, mais pour ça il fallait mieux lire entre les lignes WP que tu as résumées, car il y a une proposition clef : "ils savent interagir entre eux".
Et il fallait la comprendre : ce n'est pas leur comportement qui fait qu'ils savent interagir entre eux, c'est le mécanisme de messages qu'ils utilisent, généralement via l'appel de méthode (une implémentation possible).
Donc non ce n'est pas tout, merci Captain pas si Obvious que ça.
C'est peut-être aussi un détail mais c'est souvent là où se cache le diable : le fait que les objets utilisent un mécanisme de communication pour interagir entre eux me semble légèrement plus nécessaire que le masquage dans une approche POO...
une différence forte entre « encapsulation » et « masquage » n’est pas un consensus du tout
Il se peut, ma mémoire étant ce qu'elle est et ma littérature de référence sur le sujet étant perdue dans les limbes, tu as peut-être raison. En tous cas, même WP FR semble te donner raison.
Et je me demande bien alors comment on appelle le bundling en français.... Pas des structures : il n'y a pas de comportement dedans.
Des paquetages ?
J'instancie des paquetages en python et en perl ? Vraiment ?
Pour moi intégrer le masquage dans l'encapsulation n'est ni plus ni moins qu'un abus de langage par anglicisme (eux ont les 3 mots : encapsulation, bundling, information hiding). Dommage qu'il se répande dans la littérature.
n’est pas un consensus du tout
Quitte à jouer sur les mots et les consensus, est-ce qu'on est toujours dans de la POO quand l'instance d'une classe n'a ni toutes les méthodes ni tous les attributs de sa classe ? On encapsule, on a bien un objet issu d'une 'classe' et pourtant y a comme un truc qui pue....
Je relève les copies dans 3 mois, bon courage pour aller chercher un consensus dans la littérature.
tout est bon pour la poubelle parce qu’un détail ne t’a pas plu
Un concept central n'est pas un détail dans un papier dont c'est le sujet. J'aurais lu ça dans Marie Claire, je n'aurais probablement relevé.
Vois le bon côté des choses, j'ai lu un peu le reste pour te répondre et d'ailleurs j'ai deux questions :
- le coup des List qui intègrent des méthodes de modification => implémenter List pour faire un truc immuable ça me semble complètement con (sauf contexte étrange, genre hack moisi pour se sortir d'un mauvais pas en loucedé), tu as un exemple de classe dans la StdLib java qui fait ça ? Avec 15 ans d'XP tu as surement ça sous le coude.
- tu parles de Kotlin comme 'Langage a JVM' : j'ai cru comprendre que Kotlin se compilait / transpilait pour différentes archi (JVM, natif, JS notamment). Tes mesures ne concernent donc que quand on le fait tourner l'exe sous JVM, mais quid pour les autres supports ? Ou j'ai pas bien capté ce qu’était Kotlin ?
Pour le reste, de mon point de vue ton billet d'humeur me fait penser que
- tu n'a pas bien compris certains concepts de base (encapsulation/bundling, masquage, message)
- tu mélanges concepts (POO), bonnes pratiques (LSP, SOLID, traits) et outils de la POO intégrés au langage (la notion de private, les Enums qui sont des classes de Java)
- tu aurais pu parler des friends ou d'héritage en diamant : la aussi y a du lourd dans la série bonnes pratiques :D
- j'ai l'impression que tu galères parce que tu n'as pas bien compris, gênant après 15 ans de Java... Mais bon JBoss-like, Spring, Hibernate et autres machineries du type ne sont pas Java .... Si ça fait 15 ans que tu fais du légo avec ça, ça peut se comprendre et je compatis pour la frustration...
- tu repompes joyeux les phrases vides de sens de WP (ou sa source), exemple : le laïus sur la conception qui est primordiale en POO => parce que la conception c'est secondaire dans les autres paradigmes ?
- tu balances des dogmes (LSP, SOLID) qui ont les mêmes problèmes que ceux que tu critiques dans l'enseignement de la POO => ils sont aussi potentiellement des freins à la qualité et à la robustesse (notions bien subjectives) de ton code.
- après 15 ans de métier, je trouve étonnant que tu parles de code sans parler de contexte, pourtant le contexte, quand il change, c'est ce qui fait que tu vas tout péter, bonnes pratiques ou non, POO ou spaghetti style. C'est surtout ce qui fait qu'un choix est pourri sur papier, mais qu'en fait c'est pas si con IRL. Qu'il est malin aujourd'hui et complètement débile demain.
Donc, après avoir lu vaguement, ça confirme ma première évaluation : un truc où en quelques lignes je détecte déjà des problèmes sur le cœur du sujet alors que je ne suis pas un cador du domaine => /dev/null. Le reste ne vaudra très probablement pas mieux. C'est pour ça que d'habitude je ne lis pas les billets d'humeurs : les avis de Raymond sur les ZFE et le changement climatique ne valent pas mieux que les miens. J'ai déjà une analyse moisie du monde : la mienne. Pourquoi aller en chercher ailleurs ? Là je me suis fait avoir dans un moment de faiblesse :D
Mais bon, ça m'a permis de réviser mes classiques en m'amusant, en cela, ça n'a pas été totalement inutile donc merci.
Allez pour décrisper, j'avais lu un truc qui m'avait fait marrer (sans doute ici) : le code c'est comme le pet, on ne supporte que le sien :D
[^] # Re: À propos de la programmation orientée objet
Posté par Toufou (site web personnel) . En réponse à la dépêche À la découverte du langage V. Évalué à -5.
Ok, je vais détailler ça sera peut-être utile et moins frustrant.
Mais bon, Tu fais un billet d'humeur (non constructif) sur la POO, son usage et son enseignement pourris selon toi, je fais un post d'humeur sur ton billet d'humeur pourri selon moi => où est le problème ?
Les deux phrases m'ayant déclenché cette réaction :
et
plus le rapide survol des titres :
Donc ça balance sévère et paf, d'entrée une confusion entre deux concepts, l'un fondamental en POO (l'encapsulation), l'autre accessoire (le masquage), je trouve que ça part assez bien pour qu'il ne soit pas nécessaire de continuer et faire savoir que ça vaut pas plus qu'une discussion de comptoir avec Raymond au PMU.
Ça c'est pour expliquer la forme succincte de ma critique dont le fond a semble t'il parfaitement été compris : j'ai pas été mauvais sur le coup en termes de com.
Sur le fond :
Le masquage est un autre concept comme la notion de classe ou de propriété.
Et quand on parle de POO on parle pratiquement toujours dans un contexte de langage à classe (C++, Java, C#.... ) : ça rend la classe implicite ou obligatoire quand on parle POO ? Fuck les prototypes ?
Donc ok, c'est proche et ça va souvent ensemble mais ce n'est ni implicite, ni obligatoire il me semble.
Et alors ? En pratique c'est presque impossible de l'empêcher donc bon...
Le masquage c'est comme la notion de classe ou d'encapsulation (bundling, que j'utiliserai comme terme ensuite, pour éviter la confusion) : un concept.
Après tu l'implémentes (outils) comme tu veux :
- mot clef et mécanisme du langage (ex : private)
- convention de nommage et savoir vivre des codeurs
- menace de mort de l'ordinateur (comme certains registres du TI99 ;) )
Tout pareil pour le bundling :
- mot clefs et mécanismes du langage (ex : class)
- convention de nommage / structures particulières
- il y a surement d'autres méthodes que je ne connais pas
Donc soit tu parles du concept (on peut cacher des choses) soit tu parles des outils (on le rend private), soit tu parles des pratiques (c'est bien/c'est mal).
Là tu nous parles de POO et d'encapsulation au sens concept car c'est dans une définition.
Je ne vois pas du tout ce que la morale ou les outils viendraient faire la dedans.
Surtout, la POO n'interdit pas d'aller utiliser les propriétés et autres comportements : elle se base justement la dessus (via les messages).
Ta définition en deux phrases est d'ailleurs incomplète : il manque les messages, mais pour ça il fallait mieux lire entre les lignes WP que tu as résumées, car il y a une proposition clef : "ils savent interagir entre eux".
Et il fallait la comprendre : ce n'est pas leur comportement qui fait qu'ils savent interagir entre eux, c'est le mécanisme de messages qu'ils utilisent, généralement via l'appel de méthode (une implémentation possible).
Donc non ce n'est pas tout, merci Captain pas si Obvious que ça.
C'est peut-être aussi un détail mais c'est souvent là où se cache le diable : le fait que les objets utilisent un mécanisme de communication pour interagir entre eux me semble légèrement plus nécessaire que le masquage dans une approche POO...
Il se peut, ma mémoire étant ce qu'elle est et ma littérature de référence sur le sujet étant perdue dans les limbes, tu as peut-être raison. En tous cas, même WP FR semble te donner raison.
Et je me demande bien alors comment on appelle le bundling en français.... Pas des structures : il n'y a pas de comportement dedans.
Des paquetages ?
J'instancie des paquetages en python et en perl ? Vraiment ?
Pour moi intégrer le masquage dans l'encapsulation n'est ni plus ni moins qu'un abus de langage par anglicisme (eux ont les 3 mots : encapsulation, bundling, information hiding). Dommage qu'il se répande dans la littérature.
Quitte à jouer sur les mots et les consensus, est-ce qu'on est toujours dans de la POO quand l'instance d'une classe n'a ni toutes les méthodes ni tous les attributs de sa classe ? On encapsule, on a bien un objet issu d'une 'classe' et pourtant y a comme un truc qui pue....
Je relève les copies dans 3 mois, bon courage pour aller chercher un consensus dans la littérature.
Un concept central n'est pas un détail dans un papier dont c'est le sujet. J'aurais lu ça dans Marie Claire, je n'aurais probablement relevé.
Vois le bon côté des choses, j'ai lu un peu le reste pour te répondre et d'ailleurs j'ai deux questions :
- le coup des List qui intègrent des méthodes de modification => implémenter List pour faire un truc immuable ça me semble complètement con (sauf contexte étrange, genre hack moisi pour se sortir d'un mauvais pas en loucedé), tu as un exemple de classe dans la StdLib java qui fait ça ? Avec 15 ans d'XP tu as surement ça sous le coude.
- tu parles de Kotlin comme 'Langage a JVM' : j'ai cru comprendre que Kotlin se compilait / transpilait pour différentes archi (JVM, natif, JS notamment). Tes mesures ne concernent donc que quand on le fait tourner l'exe sous JVM, mais quid pour les autres supports ? Ou j'ai pas bien capté ce qu’était Kotlin ?
Pour le reste, de mon point de vue ton billet d'humeur me fait penser que
- tu n'a pas bien compris certains concepts de base (encapsulation/bundling, masquage, message)
- tu mélanges concepts (POO), bonnes pratiques (LSP, SOLID, traits) et outils de la POO intégrés au langage (la notion de private, les Enums qui sont des classes de Java)
- tu aurais pu parler des friends ou d'héritage en diamant : la aussi y a du lourd dans la série bonnes pratiques :D
- j'ai l'impression que tu galères parce que tu n'as pas bien compris, gênant après 15 ans de Java... Mais bon JBoss-like, Spring, Hibernate et autres machineries du type ne sont pas Java .... Si ça fait 15 ans que tu fais du légo avec ça, ça peut se comprendre et je compatis pour la frustration...
- tu repompes joyeux les phrases vides de sens de WP (ou sa source), exemple : le laïus sur la conception qui est primordiale en POO => parce que la conception c'est secondaire dans les autres paradigmes ?
- tu balances des dogmes (LSP, SOLID) qui ont les mêmes problèmes que ceux que tu critiques dans l'enseignement de la POO => ils sont aussi potentiellement des freins à la qualité et à la robustesse (notions bien subjectives) de ton code.
- après 15 ans de métier, je trouve étonnant que tu parles de code sans parler de contexte, pourtant le contexte, quand il change, c'est ce qui fait que tu vas tout péter, bonnes pratiques ou non, POO ou spaghetti style. C'est surtout ce qui fait qu'un choix est pourri sur papier, mais qu'en fait c'est pas si con IRL. Qu'il est malin aujourd'hui et complètement débile demain.
Donc, après avoir lu vaguement, ça confirme ma première évaluation : un truc où en quelques lignes je détecte déjà des problèmes sur le cœur du sujet alors que je ne suis pas un cador du domaine => /dev/null. Le reste ne vaudra très probablement pas mieux. C'est pour ça que d'habitude je ne lis pas les billets d'humeurs : les avis de Raymond sur les ZFE et le changement climatique ne valent pas mieux que les miens. J'ai déjà une analyse moisie du monde : la mienne. Pourquoi aller en chercher ailleurs ? Là je me suis fait avoir dans un moment de faiblesse :D
Mais bon, ça m'a permis de réviser mes classiques en m'amusant, en cela, ça n'a pas été totalement inutile donc merci.
Allez pour décrisper, j'avais lu un truc qui m'avait fait marrer (sans doute ici) : le code c'est comme le pet, on ne supporte que le sien :D