Salut

J'ai juste une question sur le sens de prendre l'héritage. Par exemple, si je veux implementer une classe de nombre. J'ai la classe des entiers naturelles, des entiers relatif etc...

Ma question c'est : entierNat hérite de entierRel ou c'est l'inverse.

On peut trouver des arguments pour et contre pour les deux, mais bon si il y a une méthode universelle pour décider cette question ça serai cool.

Merci ^^

La question à se poser dans ce cas là, pour savoir si A hérite de B, c'est est-ce que A est un B ?

Par exemple, Voiture hérite de Véhicule car une Voiture est un Véhicule. De même EntierNat hérite de EntierRel car un entier naturel est un entier relatif (et pas l'inverse).

Merci pour ta réponse

Il faut prendre ca avec un grain de sel et voir pourquoi tu fais de l'heritage. Certains argumentent que Rectangle devrait herite de Carre parceque Carre s'implemente avec une distance et Rectangle avec deux distances.

C'est la difference que les gens font entre l'heritage de type "est un" et l'heritage de type "est implemente comme". En C++ c'est la difference entre l'heritage public et l'heritage private.

Cependant de facon general Aldebran a raison, il faut voir l'heritage de facon "fonctionnelle" et le considere comme un "est un". Comprendre si A herite de B, alors ce qui est faisable sur B doit aussi etre faisable sur A.

J'aurais plus tendance à penser aux interfaces avant d'imaginer de l'héritage. Un entier naturel aura des points communs avec un entier relatif. Certaines méthodes seront les mêmes et d'autres se comporteront différements. Cependant, ce sont les deux des nombres, mais ce sont aussi les deux des entiers. Ainsi (mais ça mérite réflexion), au premier coup d'oeil, j'utiliserais juste une interface.

class Nombre {
attributs et méthodes
}

interface Entier {
déclaration de signatures de méthodes et methodes abstraites
}

class EntierRelatif extends Nombre implements Entier {
attributs et méthodes
}

class EntierNaturel extends Nombre implements Entier {
attributs et méthodes
}

Au temps pour moi :

interface Entier {
déclaration de signatures de méthodes
}

Tu peux aussi envisager une class abstraite Entier plutot qu'une interface :

abstract class Entier extends Nombre {
déclaration de signatures de méthodes et methodes abstraites
}

C'est dans cette dernière que tu pourras traiter des méthodes communes à un entier relatif et un entier réel.

Par contre, tu ne pourras jamais construire un Entier, il devra être soir relatif ou soit absolu.

Pas vraiment de méthode universelle(le EST UN est trop flou) mais il existe plusieurs cas reconnus où il ne faut PAS faire d'héritage:
1) Si la classe fille impose des restrictions sur la classe mère, exemple une classe Couleur qui a un int c représentant la couleur et une classe Vert qui hérite de Couleur et qui force c à 1.
2) Si la classe de base est une classe d'utilité générale, exemple dériver un IntVector depuis vector<int>, dans ce cas un typedef ou équivalent est plus approprié. De manière générale il faut éviter de dériver de classe non abstraites.
3) Si l'héritage est en fait une instanciation, exemple France n'hérite pas de Pays, ça a l'air con mais l'erreur arrive souvent.
4) Si, comme dit par deepblue c'est une implémentation d'interface

Si l'héritage passe ces quatre règles et en plus qu'il vérifie EST UN c'est bon signe.

hyrulink2, il faut faire attention, ca depend du langage.

Tu dis "il ne faut PAS faire d'héritage [...] Si, comme dit par deepblue c'est une implémentation d'interface".

En C++, c'est comme ca que l'on fait des interfaces (au sens java du terme).

Zephiel: ta question me fait terriblement penser à ça :
http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.6

cf aussi les questions qui suivent (jusqu'à 21.11 incluse).

Et la morale est : ça ne dépend pas directement des objets, mais bien de ce que tu veux en faire.

""Certains argumentent que Rectangle devrait herite de Carre parceque Carre s'implemente avec une distance et Rectangle avec deux distances.""

Et d'autres comme moi, estiment qu'il devrait pas y avoir de relations d'héritage entre ces 2 choses. Considérer carré comme une spécialisation de rectangle pose des problèmes (mutateurs de dimension non adaptés?) et considérer un rectangle comme un carré étendu, en plus de sonner faux oblige à réimplémenter presque la totalité de la classe.

Je suis partisan de l'héritage uniquement lorsque ça rentre sans frotter. Sitôt qu'un objet enfant et appelé à overrider significativement les méthodes du parent, il est possible qu'une interface, voire une classe abstraite soit plus indiquée.
Il est aussi parfois bien de se poser la question de ce qu'apporte réellement l'héritage, parfois ça peut complexifier et alourdir plus qu'autres choses.

Et la morale est : ça ne dépend pas directement des objets, mais bien de ce que tu veux en faire.

+1 Chris

D'ou souvent de nombreux problemes de refactorisation impromptue en plein projet.

Oui j'avoue que c'est beaucoup du cas par cas.

"Et d'autres comme moi, estiment qu'il devrait pas y avoir de relations d'héritage entre ces 2 choses. Considérer carré comme une spécialisation de rectangle pose des problèmes (mutateurs de dimension non adaptés?) et considérer un rectangle comme un carré étendu, en plus de sonner faux oblige à réimplémenter presque la totalité de la classe. "

Tout dépend aussi de l'implémentation et du problème qu'on a à résoudre. Par exemple si pour une raison X ou Y on définit les polygones par des listes de contraintes sur des ensembles de n points, alors ça semble évident que carré hérite de rectangle, car un carré c'est juste un rectangle avec une contrainte en plus.

Seulement si la contrainte en question n'oblige pas à redéfinir l'interface publique de rectangle pour lui ajouter des effets de bords en cas de violation.

hyrulink2, il faut faire attention, ca depend du langage.

Tu dis "il ne faut PAS faire d'héritage [...] Si, comme dit par deepblue c'est une implémentation d'interface".

En C++, c'est comme ca que l'on fait des interfaces (au sens java du terme).

En fait quand je dit interface c'est quel que soit le language, en C++ le mot-clé interface n'existe pas mais rien n'empêche d'en faire, ce sont des classes abstraites avec seulement des methodes virtuelles pures et publiques et hériter de c'est classe est plus considérer comme de de l'implémentation d'interface que de l'héritage.

Pour le problème du carré qui hérite de rectangle, carré ajoute des contraintes à rectangle donc c'est surement une mauvaise idée.