Discussion :

[Kaamui]

bonjour,

j'ai une classe de base B abstraite (non instanciable) et des classes filles C, ainsi qu'une classe supplémentaire A. Je peux représenter leur hiérarchie de ces deux manières :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
class B : public A { virtual void foo() =0; };
class C : public B {};
 
class A {};
class B { virtual void foo() =0; };
class C : public A, public B {};

Y'a t'il une manière à préférer ? Conceptuellement les deux se valent, la seule qui gêne un de mes collègues, c'est qu'on fasse hériter à une classe une classe abstraite qui hérite d'une classe concrète, mais moi ça ne me gêne pas, je vois plus la flemme de répéter dans toutes les classes filles l'héritage de A

[Iradrille]

Hello,

Si les deux se valent, l'héritage imbriqué est imo préférable : si un B EST UN A alors B doit hériter de A, classe abstraite ou non.

[koala01]

Salut,

En fait, la question a l'air simple, mais la réponse est particulièrement compliquée parce qu'il y a de nombreux aspects à prendre en compte

En gros, qu'il y ait deux, trois , cinq ou dix classes à prendre en compte, que certaines classes soient ou non des classes abstraites, les questions à se poser sont toujours les mêmes pour chaque relation d'héritage multiple -- multiple ou non -- que tu pourrais envisager:

1 - Peut-on, sémantiquement parlant (comprends : vis-à vis des définitions du dictionnaire) estimer que la classe dérivée est "une sorte d'objet" du type de la classe de base

Si la classe A est en réalité la classe Vehicule, que la classe B est en réalité la classe Poisson et que la classe C est en réalité la classe Maison, tu oublies directement toute tentative d'héritage public car ce sont des classes qui n'ont strictement aucun point commun, à par le fait de pouvoir être considérées comme des "Objets", mais je suis farouchement opposés au god objects. On n'est pas en java ou en C# ici

2- Est-ce que toutes les propriétés prouvables de la classe qui servira de base sont des propriétés prouvables de la classe qui doit hériter de la classe de base

Bien que ce soit un peu restrictif, tu peux déjà te demander si toutes les fonctions membres qui seront exposées par la classe de base ont du sens pour la classe dérivée.

Vu que tu as trois classes les solutions sont :

1. Toutes les fonctions publiques de A sont des fonctions publiques que l'on s'attend à retrouver dans B et toutes les fonctions publiques de B sont des fonctions que l'on s'attend à retrouver dans C.
2. Toutes les fonctions publiques de A se retrouvent dans B et dans C mais il y a ne serait-ce qu'une fonction publique de B que l'on ne retrouve pas dans C.
3. Toutes les fonctions publique de A se retrouvent dans C, toutes les fonctions publiques de B se retrouvent dans C mais il y a aucune fonction publique de A qui se retrouve dans B.
4. Il y a dans A des fonctions publique que l'on ne retrouve ni dans B, ni dans C et il y a dans B des fonctions publiques que l'on en retrouve pas dans C
5. J'ai l'impression d'en oublier

En (1), tu peux aller plus loin dans la réflexion pour l'héritage de B envers A et pour l'héritage de C envers B, car toutes les propriétés prouvable de A sont des propriétés prouvables pour B et que toutes les propriétés prouvable pour B (dont celles de A) sont des propriétés prouvables pour C. (*)

En (2), tu peux envisager de faire hériter C de A, de faire hériter B de A, mais tu ne peux pas envisager de faire hériter C de B : B et C seront peut-être des classes "soeurs" (car ayant la même classe mère), mais ne seront en tout cas pas mère et fille. (*)

En (3) tu peux envisager de faire hériter C de B ET de A, mais tu ne peux pas envisager de faire hériter B de A.(*)

En (4) tu ne peux envisager aucune relation d'héritage(*)

En fait, pour le (5), ce qui manque ne ferait qu'inverser la relation d'héritage possible (permettre à B d'hériter de C et / ou à A d'hériter de B et / ou de C)

(*) La réflexion se borne ici à une relation d'héritage limitée au paradigme OO... Certaines solutions pourraient passer par le paradigme générique, mais j'en parlerai plus tard (**)

3 - Y a-t-il, au niveau du langage ou des "normes de codage" de l'entreprise des restrictions qui empêcherait certaines relations d'héritage

Si restriction il y a, ce sera sans doute sous les formes d'héritage multiple . Comme on est en C++ et non en java ou en C#, ce n'est pas le langage qui placera ces restrictions, et comme tu poses la question, on peut décemment estimer que les normes de codage de ton entreprise n'ont rien contre l'héritage multiple (même si elles peuvent insister sur la vigilance qu'il faut lorsqu'on réfléchi à l'éventualité de l'utiliser ).

Pour les relations qui ont été retenues, il reste trois vérifications qui concerne la programmation par contrat pour prendre la décision finale à faire :

1. Les préconditions de la classe de base ne peuvent pas être adoucies dans la classe dérivée.
2. Les postconditions de la classe dérivées ne peuvent pas être plus fortes que celles de la classe de base
3. Les invariants doivent être respectés.

Tu ne peux donc pas envisager de faire hériter Carre (dont on apprend à l'école que c'est un rectangle) de Rectangle, car la postcondition à toute modification du carré est beaucoup plus forte que la postcondition appliquée à une modification similaire sur un rectangle : les quatre cotés doivent être égaux.

Et comme la postcondition testée doit être vraie en permanence, on se rend compte qu'il s'agit en réalité d'un invariant. Cet invariant prendra en réalité la forme d'impliquer le fait qu'il faut forcément deux valeurs pour représenter les quatre cotés d'un rectangle alors qu'une seule suffirait à représenter les quatre cotés d'un carré

Tu ne peux pas envisager de faire hériter ListeTriee de liste pour la même raison (si ce n'est que la condition devient "les éléments doivent être dans un ordre particulier" ).

(**) Après, nous avons le plaisir de développer en C++ qui est un langage qui intègre le paradigme générique et le paradigme OO de manière particulièrement souple comparé aux generics que l'on retrouve dans d'autres langages.

Il existe donc -- peut être -- une solution alternative qui passerait par le fait de ne pas se limiter au seul paradigme OO mais de profiter du meilleur des différents mondes en envisageant d'utiliser le paradigme générique.

Tu pourrais, par exemple, parfaitement envisager de créer une (ou plusieurs) classes template qui prendrai(en)t en charge un aspect bien particulier qui serait commun à A, B et C et pour lequel tu pourrais sans doute même fournir l'implémentation des comportements exposés.

Par exemple, si A, B et C présentent toutes les trois la caractéristique d'être identifiables par un identifiant unique, mais que l'une des questions que tu t'es posée t'a amené à la conclusion que l'héritage public "classique" (comprends : basé sur le seul paradigme OO) n'était pas possible, il n'y a strictement rien qui t'interdise d'envisager la création d'une classe template proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
template <typename T>
class Identifiable{
    public:
        Identifiable(/*...*/ ): id_(/*...*/){}
        size_t id() const{return id_;}
    private:
        size_t id_;
};
template <typename T>
bool lessById(Identifiable<T> const & first, Identifiable<T> const & second){
    return first.id() < second.id();
}

Tu pourrais donc utiliser cette "interface" sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class A : public IDentifiable<A>{
    public: 
        A(/*...*/) : Identifiable<A>(/* ... */){}
};
class B : public IDentifiable<B>{
    public: 
        B(/*...*/) : Identifiable<B>(/* ... */){}
};
class C : public IDentifiable<C>{
    public: 
        C(/*...*/) : Identifiable<C>(/* ... */){}
};

sans créer pour autant une relation forte entre A, B et C.

Elles ont le point commun d'être identifiables par un identifiant unique (dont le type est identique) , tu peux utiliser lessById indifféremment entre deux A, entre deux B ou entre deux C, mais tu ne pourras jamais faire cohabiter un A avec autre chose qu'un A dans une collection d'objet, et tu ne pourras jamais faire passer un B ou un C pour autre chose qu'un B ou un C

[Kaamui]

1 - Oui, je penses. Cf. definitions précises plus bas, mais la classe de base B représente une espèce de contrat que doivent remplir toutes les classes spécialisées C. Cela fait de B un A avec un invariant supplémentaire à respecter pour C.

2 -

• A est une palette flottante d'actions (style la fenetre "outil" flottante dans Paint)
• C est un A qui doit obligatoirement fournir un service "déclencheMoi" et une "action principale", une action par défaut en quelque sorte
• B est donc la base commune, décrite juste à l'instant, à toutes les palettes spécialisées de cette manière
• D est un A, composé de plusieurs C, et chaque action de A est l'action principale d'un C (cette action principale peut changer à l'éxecution)

Tout ceci pour obtenir une palette d'outils style paint, qui ont des "onglets" dédiés aux fonctionnalités qu'ils représentent.

Toutes les fonctions publiques de A sont des fonctions publiques que l'on s'attend à retrouver dans C, et les deux fonctions virtuelles pures de B (B ne contient que cela, en plus de deux constructeurs) doivent absolument être implémentées par C, même si un comportement par défaut est défini dans B, au cas où.

Du coup je ne suis pas trop sur de voir à quel cas cela se rapproche le plus, mais on dirais (5) (ou (3) mais vu que la fin de ta phrase est ill-formed , pas sur que ça corresponde et puis la conclusion ne semble pas concorder)

Me trompé-je ?

[koala01]

Toutes les fonctions publiques de A sont des fonctions publiques que l'on s'attend à retrouver dans C, et les deux fonctions virtuelles pures de B (B ne contient que cela, en plus de deux constructeurs) doivent absolument être implémentées par C, même si un comportement par défaut est défini dans B, au cas où.

Alors, la question qui tue : Y a-t-il du sens (et surtout une obligation) à faire hériter B de A

On a bien compris que tu veux pouvoir substituer un C à un A et que tu veux aussi pouvoir substituer un C à un B.

Mais veux-tu / dois tu pouvoir substituer un B à un A

On pourrait poser la question différemment : Mettons que dans trois mois, tu aies besoin d'une classe E qui hérite de B. Y a-t-il le moindre sens de permettre à E d'être un B sans lui permettre d'être un A

Si oui, l'héritage multiple sera la solution la mieux adaptée (parce que, au pire, E hérite de A et de B, si tu veux disposer des possibilités des deux).

Si tu estimes que, quoi qu'il advienne, E doit être un A dés le moment où elle hérite de B, alors la solution la plus adaptée sera sans doute de faire hériter directement B de A

Notes que, dans un cas comme dans l'autre, la décision peut parfaitement être réévaluée par la suite (du moins, tant qu'il n'y a pas *trop* de classes qui héritent de B )

Du coup je ne suis pas trop sur de voir à quel cas cela se rapproche le plus, mais on dirais (5) (ou (3) mais vu que la fin de ta phrase est ill-formed , pas sur que ça corresponde et puis la conclusion ne semble pas concorder)

J'ai corrigé, ca te semble plus clair

[Jean-Marc.Bourguet]

Alors, la question qui tue : Y a-t-il du sens (et surtout une obligation) à faire hériter B de A?

Si les justifications sont des raisons d'implementation, il y a la possibilite d'introduire une classe heritant de A et de B dont les C heritent sans qu'il y ait de liens entre A et B.

[koala01]

Si les justifications sont des raisons d'implementation, il y a la possibilite d'introduire une classe heritant de A et de B dont les C heritent sans qu'il y ait de liens entre A et B.

Là, tu penses sans doute à l'héritage privé, et tu n'as pas tord.

Mais il deviendrait alors difficile de (re) créer un lien qui permette à un objet de type C héritant de B de passer pour un objet de type A. Or, ce point semble dores et déjà acquis . Car,si j'ai bien compris, la très grosse question de Kaamui est de savoir où placer B par rapport à A et à C : au même niveau que A ou réellement comme une classe intermédiaire entre A et C.

La solution consistant à faire un héritage privé entre B et A ne me semble donc absolument pas opportune. A moins bien sûr que tu ne penses à une solution tout autre qui m'aurait échappé

[Jean-Marc.Bourguet]

Là, tu penses sans doute à l'héritage privé

Non.

Mon impression est qu'il n'y a pas de bonnes raisons pour que B soit un A mais que dans le futur previsible toutes les classes C qui vont deriver de B deriveront aussi de A et donc l'hesitation et mon evocation de la possibilite d'introduire une classe I (comme intermediaire) heritant publiquement de A et de B qui servira de base pour les classes C plannifiees.

[koala01]

Ah, ben, oui... Évidemment!!!

En gros, tu as juste suivi le raisonnement que j'avais esquissé dans mon intervention précédente jusqu'à sa conclusion logique . Je m'étais juste arrêté "un cran trop tôt" et la fatigue aidant (sans doute), je n'avais absolument pas percuté sur le fait que c'était à ce cran supplémentaire que tu faisais allusion

[Kaamui]

Ta question qui tue était la bonne

En effet j'aurais du me poser la question dans ce sens, car je me rend compte que B sans A n'est plus rien, en tout cas on ne peut pas être un B sans être un A aussi


Oui après ta correction c'est mieux et donc on n'est pas dans ce cas là non plus.

Et donc la solution d'un intermédiaire vaudrait mieux ?

B est une palette flottante qui implémente obligatoirement les deux fonctions virtuelles pures. C n'est que sa dérivée instanciable avec les mêmes invariants, B me garantissant juste que ces deux méthods seront implémentées.

[koala01]

Ta question qui tue était la bonne

En effet j'aurais du me poser la question dans ce sens, car je me rend compte que B sans A n'est plus rien, en tout cas on ne peut pas être un B sans être un A aussi


Oui après ta correction c'est mieux et donc on n'est pas dans ce cas là non plus.

Et donc la solution d'un intermédiaire vaudrait mieux ?

Je crois en effet.

Cela ne "mange pas de pain", mais ca te permettra d'obtenir plus de flexibilité (si un jour tu décide que B + "une autre classe de base que A" vaut la peine )

[Kaamui]

En fait je dis C mais je devrais dire Cx avec x allant de 1 à 5, car j'ai plusieurs classes du type de C (qui vont avoir cet héritage). Mais ça change pas grand chose je penses, si ce n'est que ça confirme qu'il faudrait peut-être effectivement que C existe en tant base intermédiaire, pour ses filles Cx.

Merci pour vos réponses,

Edit : Reflexion faite, je n'aime pas l'idée que l'on puisse hériter de B sans être obligé d'hériter de A, c'est pour le coup laisser la possibilité de faire des conneries..

[koala01]

Là, tu regardes par le mauvais coté de la lorgnette, car tu devrais voir cela comme la possibilité de permettre à l'utilisateur de fournir des fonctionnalités similaires à celles qui sont apportée par B à des classes qui dérivent d'autre chose que de A.

Pour l'instant, le besoin porte sur une palette d'outil, mais pourquoi ne pourrait il pas porter sur "autre chose"

Tout ce à quoi tu dois veiller, c'est:

1. à choisir un nom qui exprime clairement la fonctionnalité que B ajoute
2. indiquer clairement dans la documentation que B est destiné à intervenir dans un héritage multiple.

En plus, tu ne ferais rien de plus que ce que C++ a toujours fait en privilégiant la fonctionnalité à la sécurité

[Kaamui]

Non mais tu as raison, mais en fait je n'ai pas le choix.

C'est moi qui vous donne pas assez de bonnes informations, je m'en excuse.

La fameuse "action principale" que je définis comme tel, renvoie une action faisant partie d'une liste dans A.

A : ActionPalette
B : AbstractActionSubPalette
C : ActionSubPalette (EllipseSubPalette, RectangleSubPalette, etc)
D : DrawingPalette

[koala01]

Oui, mais la possibilité que tu ajoutes, c'est d'avoir une action par défaut, si je ne m'abuse... (ou est-ce moi qui ai rêvé )

Dés lors, pourquoi ne pas avoir un DefaultActionSender (ou tout autre nom similaire) qui fournirait une fonction void defaultAction() qui sera redéfinie par l'utilisateur en fonction de ses besoins

Qu'il appelle l'une de ces quatre actions pour les classes que tu prévois de créer ou une action particulière à une autre classe de base dans un autre contexte ne changera rien

[Kaamui]

Oops confusion : A B C et D sont les noms des classes (comme tu disais qu'ils devaient être clairs, je te les montrais), pas 4 actions.

DefaultActionSender : oui effectivement, je pourrais abstraire encore plus cette fonctionnalité, pour que les classes héritant de B soient obligées de les redéfinir, et ça me permettrait de les réutiliser ailleurs, si un jour le besoin se présente. Je vais voir si ça ne me prends pas beaucoup de temps, une fois que je me remettrai sur cette évol' là, et je te tiendrais au courant de la décision finale