IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

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


Sujet :

C++

  1. #1
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    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
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    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
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    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
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    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
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    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
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    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
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    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 éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 : 5 275
    Points : 10 985
    Points
    10 985
    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. Et de toutes façons, ma BAL sur dvpz est pleine...

  9. #9
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    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 ).

Discussions similaires

  1. Guru of the Week 104
    Par gbdivers dans le forum C++
    Réponses: 15
    Dernier message: 25/04/2012, 16h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo