class friend et héritage

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

struct C_Base { private: ... public: ... virtual void M()=0;//all overloaded M() should access private members of Autre };   struct C_Derive1: C_Base { private: ... public: ... virtual void M();//need to access private members of Autre };   struct Autre { friend struct C_Base; private: ... public: ... };

---

Je souhaiterais qu'une classe de base, et toutes ses dérivées, soient "friend" d'une Autre classe. Mais je voudrais éviter d'avoir à spécifier la liste des classes dérivées à Autre.
Une solution à cela ?
Merci.

Pas de solution simple à ma connaissance, c'est une limitation de friend.

Il y a peut-être un moyen de bricoler à base de friend template, en définissant tes classes dérivées comme spécialisation d'un type template. Je déconseille très fortement d'en arriver à une telle solution :).

Expose un peu plus en détail pourquoi tu aurais besoin de faire ça, et dans ce cas, on pourra t'orienter vers une solution plus propre (certains vont te dire que dès qu'il y a friend, ce n'est pas propre, personnellement, je ne partage pas du tout cet avis).

Ca me semble difficile vu que l'amitié n'est ni héritée, ni transitive ou réciproque.

Edit: +1 pour expliciter les besoins, ca sent la mauvaise conception.

Salut,

Ceci dit, toute fonction définie au sein de cette classe et non redéfinie dans les classes dérivées (donc a priori, les fonctions non virtuelles, et, pour qu'elles soient accessibles depuis les classes dérivées, déclarées publique ou protégées) sont réputé etre... de la classe de base...

Aussi, si tu déclare la classe de base amie de ta classe Autre, et que tu définis les fonctions qui vont "profiter" de l'amitié dans la classe de base de manière non virtuelle et publique ou protégées (mais pas privée), tu pourra invoquer ces fonctions depuis les autres fonctions des classes dérivées ;)

J'explique, en espérant me faire comprendre, sans rentrer dans de longs et fastidieux détails ;)

J'ai une db SQL avec plein de tables. Rien de bien excitant, sauf qu'une de ces tables est du genre fourre-tout. Elle contient 3 champs principaux: "type", "subtype" et "data". En fait, le propriétaire des données, chaque fois qu'il a besoin de créer un contenu "secondaire" dans sa db, au lieu de créer une table (tâche sous-traitée et donc fastidieuse et coûteuse) il remplit cette table en créant un nouveau type. En gros il crée lui-même dynamiquement des "tables", le nom de la (fausse) "table" se trouve dans "type", les champs dans "subtype", et l'info correspondante dans "data".
En fait il me semble que ce soit assez classique comme modèle fourre-tout.

Pour gérer le contenu de cette table j'ai écrit une classe C++ qui l'encapsule.
Mais comme les choses ne sont jamais simples, il y a de nombreux cas d'exception dans le traitement des données qui sortent du cas générique. J'ai donc créé une classe de base pour gérer le cas générique, classe amie de la classe d'encapsulation principale, puis au fur et à mesure de l'enrichissement du contenu, je crée une classe dérivée lorsque ce contenu sort du cadre générique. La classe de base et les classes dérivées doivent accéder à certaines infos privées de la classe d'encapsulation principale.

Je pourrais déplacer de private vers public les champs nécessaires, mais seule la liste des classes dérivées peuvent y accéder.
Donc pour l'instant chaque classe dérivée créée est aussi ajoutée dans la liste des classes friend. Bah, c'est pas bien grave, mais ça me fait bizarre.

Si vous avez d'autres idées, merci :D

Tu pourrais donner à ta classe d'encapsulation deux interfaces, une qui ne contient que les fonctions publiques, et que tu donnes à tes clients standards, et une autre contenant les fonctions de manipulation avancées (qui sont actuellement en privé dans ta classe), mais que tu ne passe qu'à ta hiérarchie de classe de manipulation.

Code:

---

class MonEncapsulation : public InterfacePublique, public InterfacePrivée {...}

---

Ou une variante, mais encapsule moins, mais demande une classe de moins, et évite l'héritage multiple (certains sont peu à l'aise avec) :

Code:

---

1 2 3 4

class MonEncapsulation : public InterfacePublique { // Et là, tu mets tout en public: }

---

Tu dois aussi pouvoir fonctionner par composition, la classe englobante étant fournier publiquement, et contenant un pimpl vers une classe dont le .h n'est pas fourni au client de la classe

Code:

---

1 2 3 4 5

class MonImplementationOuToutEstPublique; class InterfacePublique { scoped_ptr<MonImplementationOuToutEstPublique> monImplementation; }

---

Merci pour vos réponses.

Etant dans un contexte de maintenance, il est difficile de tout chambouler. L'idée de koala01 me semble la plus simple et la plus adaptée.
Et après réflexion, je pense que c'est une solution générale qui peut s'appliquer dans de nombreux contextes: confier à la classe de base l'essentiel des accès extérieurs.

Encore merci.

Citation:

---

Envoyé par camboui

Merci pour vos réponses.

Etant dans un contexte de maintenance, il est difficile de tout chambouler. L'idée de koala01 me semble la plus simple et la plus adaptée.
Et après réflexion, je pense que c'est une solution générale qui peut s'appliquer dans de nombreux contextes: confier à la classe de base l'essentiel des accès extérieurs.

Encore merci.

---

Il faut quand même avouer que, si ma solution est valide et "correcte" (dans le sens où elle permet de faire ce que tu recherche), elle n'est malgré tout qu'un "pis allez" te permettant de résoudre un problème de conception à la base, car les réflexions à avoir sont:

La (les) fonctions que tu t'apprête à rajouter à la classe de base sont, certes, utiles, mais sont-elles opportunes dans la classe de base :question:

D'une manière ou d'une autre, les fonctions rajoutées à la classe de base devront "communiquer" avec la classe dans laquelle tu déclare l'amitié.

Cela implique, au minimum de passer cette classe par argument à la (aux) fonction(s) membre(s) rajoutée(s), au maximum de prévoir une composition ou une agrégation de cette classe dans la classe de base... Mais est-ce opportun :question:

Il est difficile de prévoir les évolutions d'un projet dans le temps. Et dans ce cadre il est trop facile de remettre en cause une ancienne conception mais qui a pourtant permis de faire vivre de nombreuses personnes ;)

Pour en revenir à mon cas précis, les exceptions dont je parlais étaient gérées avec des if else if else if... Ça devenait un peu un plat de nouilles avec le temps. Je cherche simplement à donner plus de lisibilité à un code assez localisé sans tout revoir.

Mais tu me fais penser à des cas magnifiques du monde des télécoms. Un central téléphonique c'est fait pour gérer des communications. En temps réel bien sûr. On est d'accord, pas de problème conceptuel là-dedans ?
A l'époque, la solvabilité ou la fidélité d'un client n'était pas du ressort du central proprement dit. Puis un jour vinrent les équipes de marketing et leur imagination débordante avec pleins de choses à faire faire en temps réel... En bref, il y aura toujours un décalage "conceptuel" entre les équipes techniques et les vendeurs :aie:

Je suis bien conscient qu'il est parfois difficile de préjuger de l'évolution des besoins sur des délais finalement très long (20 ans, en IT, c'est une éternité)

Mais il faut aussi parfois prendre conscience que l'on ne peut adapter l'ancien que "dans une certaine mesure", et qu'à un moment donné, il va sans doute falloir reprendre une bonne partie de la conception (utiliser éventuellement une base de donnée existante, mais revoir la manière dont elle est utilisée au final ;))

Et je reste persuadé que la personne la mieux placée pour dire qu'il est peut être temps de passer "à une autre approche", c'est celle qui a en charge la maintenance de l'application...

Quelque part, si tu ne signale pas aux responsables non informatiques que tu as atteint les limites de ce que tu peux faire "avec l'ancien", il ne faut pas compter sur eux pour s'en rendre compte ;)

Évidemment, cela signifie de partir sur un projet important, nécessitant de reprendre l'analyse depuis le début, couteux en temps et en énergie personnelle...

C'est donc, quelque part, ton role de signaler aux autres "bon, j'applique une rustine pour nous permettre de continuer à travailler en suivant les évolutions actuelles, mais il est grand temps de se remettre autour de la table afin de réfléchir de manière globale et intégrée à ce que pourrait être la prochaine version de notre logiciel"

Salut,
Je vais être plus brutal que Koala : refactoring du code ne s'impose que si le coût du refactoring + risque + gain maintenance espéré < coût de maintenance actuel... Ce qui fait que souvent on préfère continuer à bricoler :(
C'est souvent frustrant mais c'est la réalité du marché...
Ca peut se 'vendre' en segmentant le refactoring en petite tranche au coût suffisamment réduit ou en intégrant dans le cadre d'une évolution un peu conséquente. Mais, en général, on ne peut pas tout changer d'un coup (ne serait-ce qu'à cause du risque).

Citation:

---

Envoyé par 3DArchi

Salut,
Je vais être plus brutal que Koala : refactoring du code ne s'impose que si le coût du refactoring + risque + gain maintenance espéré < coût de maintenance actuel... Ce qui fait que souvent on préfère continuer à bricoler :(
C'est souvent frustrant mais c'est la réalité du marché...
Ca peut se 'vendre' en segmentant le refactoring en petite tranche au coût suffisamment réduit ou en intégrant dans le cadre d'une évolution un peu conséquente. Mais, en général, on ne peut pas tout changer d'un coup (ne serait-ce qu'à cause du risque).

---

Tout à fait, mais, si tu (le tu ici est à prendre au sens du service informatique) ne signale pas que tu as atteint la limite des bricolages que le système peut supporter, les décideurs ne pourront jamais se pencher sérieusement sur le problème pour décider s'il faut envisager le refactoring ou s'il est préférable de continuer à bricoler...

Quelque part, et je les comprend: Tant qu'on peut apporter les modifications souhaitées, pourquoi passer à autre chose :question:

[EDIT]Ce que je veux dire, c'est qu'il ne faut pas avoir peur d'aller présenter son point de vue et de défendre ses arguments, autrement, si le décideur n'a pas conscience que "ca ne va plus", comment pourrait il prendre les bonnes décision :question:

Après, il y a tout le problème de trouver les arguments "qui feront mouche" ;)