Version imprimable
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.
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 ;)
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)
Ce doit être une facétie du proxy alors.Citation:
Envoyé par gbdivers
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.
D'autres ne seraient pas d'accord avec toi : Les amis brisent-ils l'encapsulation ?Citation:
Envoyé par Freem
C'est un point qui est régulièrement abordé sur le forum
Salut,En fait, c'est l'amitié déraisonnée qui brise l'encapsulation.Citation:
Envoyé par Freem
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 ;)
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>")
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.
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 :cry: mais je travaille à améliorer ça :P).