Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 9 sur 9
  1. #1
    Inactif


    Homme Profil pro Guillaume Belz
    Biochimiste
    Inscrit en
    novembre 2008
    Messages
    5 318
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume Belz
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Biochimiste
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 318
    Points : 17 319
    Points
    17 319

    Par défaut Guru Of the Week n° 40 : polymorphisme contrôlé

    Le polymorphisme EST-UN est un outil très utile en conception orienté objet, mais parfois vous pouvez vouloir restreindre les codes qui peuvent utiliser certaines classes de façon polymorphe. Cet article aborde la problématique et montre comment obtenir l'effet désiré.

    Guru Of the Week n° 40 : Polymorphisme contrôlé

    Retrouver l'ensemble des Guru of the Week sur la page d'index.

  2. #2
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    804
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 804
    Points : 2 518
    Points
    2 518

    Par défaut

    Pas encore lu, mais une remarque:
    l'URL "principale" de DVP est "http://www.developpez.com/index/redirect/14769/Guru-Of-the-Week-n-40-Polymorphisme-controle-un-article-de-Herb-Sutter-traduit-par-la-redaction-C/" et ne fonctionne pas. En tout cas, pas ici, avec opera et winXP.

    Avis quand j'aurai fini de lire

  3. #3
    Inactif


    Homme Profil pro Guillaume Belz
    Biochimiste
    Inscrit en
    novembre 2008
    Messages
    5 318
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume Belz
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Biochimiste
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 318
    Points : 17 319
    Points
    17 319

    Par défaut

    Pourtant, l'url est bonne, même en la copiant collant. Et sur les portails, ça fonctionne aussi chez moi

    Sinon, les url pour les gotw sont toutes identiques : http://cpp.developpez.com/gotw/ suivie du numéro (donc http://cpp.developpez.com/gotw/40 ici)

  4. #4
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    804
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 804
    Points : 2 518
    Points
    2 518

    Par défaut

    Citation Envoyé par gbdivers Voir le message
    Pourtant, l'url est bonne, même en la copiant collant. Et sur les portails, ça fonctionne aussi chez moi
    Ce doit être une facétie du proxy alors.

    Pour le contenu... Je vois mal dans quelle situation on pourrait avoir envie de laisser une fonction avoir le droit d'accès à la dérivée et pas une autre.
    Dans ce cas, ne serait-il pas plus simple d'utiliser une fonction membre statique?
    Ca reviens strictement au même que le friend, sauf que vu qu'elle est membre, la personne qui aura à maintenir le code saura naturellement que la fonction à un accès total aux données.
    Il faut tout de même se souvenir que friend brise l'encapsulation (je pense que je n'ai eu à l'utiliser que dans le cas de l'utilisation d'un template de singleton, puisque dans une telle situation il faut empêcher la création intempestive d'objets fils, et donc rendre le constructeur privé) ainsi que pas mal de concepts du GRASP (à moins que je ne me trompe).

    Bien sûr le souci c'est qu'on ne peut pas être membre de plusieurs de classes (bon, sauf si on fait un foncteur qui hérite de façon privée, mais gaffe aux diamants...)... mais dans le cas strictement limité à l'exercice proposé, ce n'est pas un problème.

  5. #5
    Inactif


    Homme Profil pro Guillaume Belz
    Biochimiste
    Inscrit en
    novembre 2008
    Messages
    5 318
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume Belz
    Âge : 38
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Biochimiste
    Secteur : Santé

    Informations forums :
    Inscription : novembre 2008
    Messages : 5 318
    Points : 17 319
    Points
    17 319

    Par défaut

    Citation Envoyé par Freem Voir le message
    Il faut tout de même se souvenir que friend brise l'encapsulation (je pense que je n'ai eu à l'utiliser que dans le cas de l'utilisation d'un template de singleton, puisque dans une telle situation il faut empêcher la création intempestive d'objets fils, et donc rendre le constructeur privé) ainsi que pas mal de concepts du GRASP (à moins que je ne me trompe).
    D'autres ne seraient pas d'accord avec toi : Les amis brisent-ils l'encapsulation ?
    C'est un point qui est régulièrement abordé sur le forum

  6. #6
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 691
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 691
    Points : 15 768
    Points
    15 768

    Par défaut

    Salut,
    Citation Envoyé par Freem Voir le message
    Ca reviens strictement au même que le friend, sauf que vu qu'elle est membre, la personne qui aura à maintenir le code saura naturellement que la fonction à un accès total aux données.
    Il faut tout de même se souvenir que friend brise l'encapsulation (je pense que je n'ai eu à l'utiliser que dans le cas de l'utilisation d'un template de singleton, puisque dans une telle situation il faut empêcher la création intempestive d'objets fils, et donc rendre le constructeur privé) ainsi que pas mal de concepts du GRASP (à moins que je ne me trompe).
    En fait, c'est l'amitié déraisonnée qui brise l'encapsulation.

    Je m'explique :

    Si tu déclares une classe ou une fonction amie d'une (autre) classe, tu favorise l'encapsulation en permettant à la classe (ou à la fonction ) amie et à elle seule d'accéder à "quelque chose" que tu ne souhaites pas exposer "à tous vents".

    En effet, l'alternative à l'amitié est... de rajouter, dans le meilleur des cas, un accesseur, dans le pire des cas un accesseur et un mutateur (ou quelque chose de très similaire).

    Le problème, si tu rajoutes un mutateur et / ou un accesseur, c'est que "n'importe quel clampin" peut décider d'y avoir recours, donnant une responsabilité à sa fonction qu'il n'aurait sans doute pas du avoir (vu que tu aurais aimé cacher l'information sous jascente.

    Dans un tel cas, l'amitié favorise bel et bien l'encapsulation en t'évitant d'avoir à exposer à tous quelque chose qui n'est utilsé que de manière strictement contrôlée.

    Par contre, si tu commences à multiplier "outre mesure" le nombre de classes ou de fonctions amies (car un nombre "raisonnable" de fonction ou de classes amies peut toujours être envisagé ), il est clair que tu arrives rapidement à briser l'encapsulation, en exposant de facto l'ensemble de la classe à toutes les classes / fonctions amies.

    On peut cependant exprimer le fait que la définition d'un nombre "trop important" d'amitiés sera sans doute le symptome d'un problème de conception beaucoup plus profond, soit parce que tu essayes absolument de "cacher" une information qu'il apparait inutile de vouloir cacher, soit parce que la granularité de la responsabilité de ta classe n'est pas bien étudiée, soit parce que ta classe présente définitivement trop de responsabilité, soit enfin parce que tu essaye décidément d'accéder à une information donnée (pas forcément toujours la meme, d'ailleurs ) depuis un trop grand nombre d'endroits et que tu aurais sans doute intérêt à rationnaliser un peu les choses.

    Au final, je dirais que l'utilisation de l'amitié est une technique qui doit, comme de nombreuses autres, être utilisée à bon escient. C'est l'abus de l'amitié qui risque de nuire, tout comme le fait de faire de la récursivité pour le plaisir d'en faire peut nuire énorément
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #7
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    804
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 804
    Points : 2 518
    Points
    2 518

    Par défaut

    Navré, je ne suis pas spécialement très présent sur le forum, je dois bien le reconnaître.

    OK pour l'encapsulation, bien que je ne voie pas de situation où il est "nécessaire de séparer une classe en deux, par exemple quand les deux moitiés ne peuvent pas avoir le même nombre d'instances ou quand elles n'ont pas la même durée de vie".
    Je veux bien un exemple d'ailleurs pour le coup (d'autant que la FaQ dis que c'est "souvent"... ) si quelqu'un peut éclairer ma lanterne...

    Mais pour ce qui est du couplage?
    Pour le coup, friend couple explicitement une classe à une autre, alors qu'il est possible qu'elle n'aurait sinon aucun couplage, non?
    Je n'arrive vraiment pas à voir l'intérêt de friend dans le cas énoncé en fait (comme je l'ai dis, il m'est néanmoins déjà arrivé de l'utiliser, bien que le cas le plus notable, si ce n'est l'unique, soit le "singleton<T>")

  8. #8
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Homme Profil pro Luc Hermitte
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    4 700
    Détails du profil
    Informations personnelles :
    Nom : Homme Luc Hermitte
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 4 700
    Points : 6 992
    Points
    6 992

    Par défaut

    Dans le cas d'une fonction, il n'y a pas plus de couplage entre la classe et la fonction externe libre, et amie, qu'entre la classe et une fonction membre de cette même classe.
    La liste finie de toutes les fonctions membres est connue dès la définition de la classe, et il en est de même de la liste des fonctions externes et amies. C'est exactement pareil, sauf que la fonction n'est pas membre de la classe, mais libre ou dans une autre classe.


    Dans le cas d'amitié inter-classes, au final ce n'est guère différent, si ce n'est que l'on dit que les deux classes sont fortement couplées. L'une ne peut vivre sans l'autre.
    Quelle est l'alternative ? N'avoir qu'une seule classe ? Je doute que les rôles à répartir permettent toujours cela.
    Des accesseurs/mutateurs ? C'est ce qu'il y a de pire en terme de rupture d'encapsulation (dans le sens getter/setter).

    Est-ce que l'on s'en sert souvent ? Assez peu à vrai dire. Les quelques cas qui me viennent en tête sont des cas de classes proxy (qui par définition sont déjà très couplées aux classes auxquelles ils servent à accéder -- proxy == intermédiaire). Et là, une alternative sans amitié consiste à donner au proxy une référence vers les attributs de la classe "finale" que le proxy serait à même de modifier. S'il devenait intéressant de permettre au proxy de taper dans les fonctions privées de la classe, alors l'amitié n'est pas déconnante.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média.

  9. #9
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    804
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 804
    Points : 2 518
    Points
    2 518

    Par défaut

    C'est vrai que pour une fonction ça ne change rien, j'avais plus en tête l'amitié de classe. J'admets ne jamais penser à l'amitié des fonctions, en fait.

    Quand au proxy, il fait partie des design pattern dont je n'ai pas encore eu de cas d'utilisation (je suis encore un grand débutant avec ces outils, j'ai du trouver des cas d'utilisation concrets pour a peine 5 d'entre eux mais je travaille à améliorer ça ).

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •