Hiérarchie de relations d'héritage

Bonjour

Dans Exceptionnal C++, Sutter affirme ceci:

Citation:

---

If a class relationship can be expressed in more than one way, use the weakest relationship that's pratical. Given that inheritence is nearly the strongest relationship you can express in C++, it's only really appropriate when there is no equivalent weaker alternative.

---

Voici une hiérarchie, certainement pas exhaustive des relations entre les héritages, du plus fort au plus faible.

J'aimerais bien avoir l'avis des experts, surtout pour la compléter.

frendship
public inheritence
private inheritence
layering (composition)

Pourquoi choisir toujours la relation la plus faible?

Merci

Attention les fonctions amies ne sont pas synonyme d'héritage elles sont un outils qui permet d'accéder aux données privé d'une autre classe!!:?

a class relationship ne signifie pas nécessairement qu'il y a un héritage mais que les classes sont en relation. L'amitié est bien une relation, donc c'est tout à fait pertinent de la faire rentrer dans ce sujet.

Pour répondre à la secondes question, la raison est contenue elle même dans la notion de relation plus forte. Plus la relation est forte plus les contraintes sémantiques sont élévés. Par exemple tu imposes bien plus de choses sur le sens de tes classes en disant qu'un B est un A qu'en disant qu'un A a un B, dans le premier cas ca impose en particulier que tu puisses voir un B comme un A (LSP), alors que dans le second cas non.

C'est la hiérarchie que donne Sutter ? Personnelement j'ai un peu du mal à clairement placer la relation d'amitié dans celle ci, et je trouve que private inheritence et composition font doublons, après tout l'héritage privé n'est qu'un moyen de réaliser une composition. Tu peux, je pense, rajouter agrégation comme relation plus faible que la composition, typiquement ca correspondrait à un pointeur ou une référence en donnée membre (la destruction du lien n'implique plus la destruction des deux éléments liés).

Je rejoins Flob90 en ce qui concerne l'amitié, elle ne rentre pas très bien dans cette échelle. De mon point de vue, elle s'exprime plus sur un axe portant sur l'ouverture des détails à l'extérieur (et se compare donc davantage avec la présence de membres public ou de getter/setter même si j'ai aussi du mal à trouver une relation d'ordre entre eux) que sur l'axe class relationship (même si en toute rigueur, il s'agit bien - ou plutôt il peut s'agir - d'une relation entre classe).

Néanmoins, si je dois vraiment placer l'amitié dans l'échelle que tu donnes, je ne la mettrais pas au même endroit que toi ne serait-ce que parce qu'elle ne se répercute pas directement , contrairement à l'héritage public, sur les utilisateurs des classes. Vu de l'extérieur des deux classes en relation, ça reste un détail d'implémentation.

Citation:

---

dans le premier cas ca impose en particulier que tu puisses voir un B comme un A (LSP),

---

Liskov substitution principle?
Je n'ai pas trop compris ce principe. Qu'est-ce au juste?

Citation:

---

Envoyé par deubelte

Liskov substitution principle?
Je n'ai pas trop compris ce principe. Qu'est-ce au juste?

---

http://fr.wikipedia.org/wiki/Princip...tion_de_Liskov

Citation:

---

Envoyé par deubelte

Liskov substitution principle?
Je n'ai pas trop compris ce principe. Qu'est-ce au juste?

---

En gros, le principe dit qu'une relation EST-UN (modélisé par un héritage public) signifie que, si B dérive de A, partout où un A (en fait dans le cadre du C++, un pointeur ou une référence sur un A) est attendu on peut fournir un B.

Ce qui impose entre autre qu'un B se comporte comme un A, que les préconditions de B sont plus souples ou identiques que celle sur A, qu'au contraire les postconditions de B sont identiques ou plus strictes que celles de A.

Salut,

Citation:

---

Envoyé par deubelte

Liskov substitution principle?
Je n'ai pas trop compris ce principe. Qu'est-ce au juste?

---

En gros, le principe de substitution de Liskov te dit que, pour pouvoir faire hériter une classe (B) d'une autre (la class A), il faut que tu puisse sémantiquement estimer qu'un B est effectivement un A, quitte à ce qu'il présente une adaptation de certains comportements (le polymorphisme) ou certains services supplémentaires.

Concrètement, tu peux ainsi estimer que voiture, avion, bateau et moto sont, effectivement, des véhicules, car ils proposent tous des services tels que "démarrer", "accélérer", "ralentir" ou "s'arrêter", bien que chacun de ces types dérivés puisse envisager ces différents services de manières différentes et que certains puissent même proposer des services supplémentaires (l'avion, par exemple, fournira aussi les services "décoller", "atterrir", "monter" et "descendre" ;) ).

Mais, pour peu que tu considère moto, voiture, avion et bateaux comme des "véhicule" (et donc que tu te limite aux services fournis par un véhicule, sans autre précision), rien ne t'empêche de créer une collection dans laquelle tu trouverais trois voitures, une moto, deux avions et cinq bateaux.

Il va cependant de soi que, si tu veux pouvoir considérer tes bateaux en tant que tel, il faudra soit passer par des pattern tels que le visiteur (qui permettent, grace à la surcharge de fonctions, d'adapter le comportement à l'objet réellement visité), soit trouver un moyen de maintenir "quelque part" une collection ne regroupant que les bâteaux ;)

Comme les autres, je ne mettrais pas forcément l'amitié dans la hiérarchie ci-dessus, ne serait-ce parce qu'elle peut s'appliquer à autre chose qu'une "relation entre classes" (elle peut également représenter une relation entre une classe et une fonction ;)) et que, bien qu'elle implique, pour celui qui devra implémenter la classe / fonction déclarée amie, la possibilité d'avoir à connaitre les détails d'implémentation de celle-ci, la dépendance peut s'avérer malgré tout moins importante que l'héritage, car on peut parfaitement envisager de ne recourir qu'à des comportements internes (fonctions protégées ou privées) au lieu d'accéder directement au membres qui permettent ces comportements ;)

Citation:

---

Envoyé par koala01

Comme les autres, je ne mettrais pas forcément l'amitié dans la hiérarchie ci-dessus, ne serait-ce parce qu'elle peut s'appliquer à autre chose qu'une "relation entre classes" (elle peut également représenter une relation entre une classe et une fonction ;)) et que, bien qu'elle implique, pour celui qui devra implémenter la classe / fonction déclarée amie, la possibilité d'avoir à connaitre les détails d'implémentation de celle-ci, la dépendance peut s'avérer malgré tout moins importante que l'héritage

---

Si on suit ce raisonnement, la composition ne devrait pas rentrer dans la liste non plus, vous ne pensez pas ?

Bonjour,
A mon avis,
Les relations ne sont pas symétriques. Lorsqu'on regarde une classe A, l'amitié considérée devrait être celle donnée à A qui suppose que A va être intiment couplé à cette autre classe. L'amitié donnée par A à une autre fonction/classe n'a en réalité pas d'impact sur A.
C'est pour ça que la composition est regardée par rapport à A qui contient un B et pas par rapport à B qui est contenu par A.

Citation:

---

Envoyé par 3DArchi

Les relations ne sont pas symétriques.

---

Tout à fait et ta remarque est d'ailleurs vrai pour les différents types de relation.

Citation:

---

Envoyé par 3DArchi

L'amitié donnée par A à une autre fonction/classe n'a en réalité pas d'impact sur A.

---

Là par contre je ne suis pas tout à fait d'accord. Cela à au moins un impact sur le cycle de développement des évolutions de la classe A puisque ça impose de se synchroniser avec le développement des classes amies (ce qui, d'expérience, n'est pas toujours simple).
C'est d'ailleurs la raison pour laquelle j'apprécierais d'avoir une amitié plus sélective (i.e. pas seulement de pouvoir choisir qui sont mes amis comme actuellement mais aussi de pouvoir choisir ce à quoi ils peuvent accéder).

Salut,

Citation:

---

Envoyé par gl

Là par contre je ne suis pas tout à fait d'accord. Cela à au moins un impact sur le cycle de développement des évolutions de la classe A puisque ça impose de se synchroniser avec le développement des classes amies (ce qui, d'expérience, n'est pas toujours simple).

---

Ce que je veux dire, c'est que quand A donne l'amitié à B, toute modification de B n'a aucun impact sur A. En revanche, il est évident que l'inverse n'est pas vrai car c'est bien B qui est très dépendante de A. De la même façon si B hérite de A, toute modification de B n'a pas à avoir d'impact sur A alors que le contraire est beaucoup moins vrai.