J'ai une classe Arbre qui contient des Noeud chainés entre eux
J'aimerais pouvoir dériver cette classe Arbre pour en faire un arbre plus spécialisé qui ne pourrait contenir que des instances d'une sous classe donnée de Noeud
Comment faire cela proprement, sans avoir à caster dans tous les sens ? Merci

 
qui ne pourrai contenir que des instances d'une sous-classe de Noeud, plutot, non ?

Oui c'est ça, merci
J'ai édité

pour resume tu veux :
 
 

et une solution propre ...
et ben tu surcharges les méthodes d'ajout/acces aux noeuds de l'arbre, pour ne prendre en parametre que le type d'Objet que tu souhaite manipuler. Non ?
 
EDIT : non, en fait ca marche pas

une petite idée ? y a un pattern qui permettrait ce genre de choses ?

Pour un contrôle à la compilation, oui : ça s'appelle la généricité. Mais elle ne sera intégrée à Java qu'avec le JDK 1.5.
 
Sinon, tu peux toujours insérer des "assert(monNoeud instanceof NoeudMieux);" dans les méthodes de ArbreMieux qui attendent des arguments de type Noeud.

Ben, à mon avis, dans ce cas là, 'faut que t'utilise la délégation, pas l'héritage.
Je m'explique.
Dans ta classe Arbre, t'as forcément une méthode AddNoeud(Noeud leNoeud) qui prend une instance Noeud en paramètre. Si ta classe ArbreSpecial hérite d'arbre, elle comportera forcément cette meme  méthode prenant elle aussi un Noeud en paramètre (surchargée ou non). La solution donc, c'est de ne pas héruter d'Arbre, mais d'utiliser une instance d'Arbre, attribut privé (ou protégé) de ArbreSpecial.

vouii, je savais bien qu'il y avait une sol. (je l'avais deja utilise une fois).
kidimieux

ah ben oui, c'est le mieux en effet !
Merci bcp

L'héritage c'est fait puor étendre le champ d'action, pas pour le restreindre (d'ou le mot clé "extends" d'ailleurs j'pense !)

Oui, mais des classes héritées peuvent aussi être des spécialisations de la classe mère

 
Ouais, c'est vrai. Pas besoin de chercher bien loin d'ailleurs : la classe Object par exemple !

Mais justement, la classe Object défini le minimum qu'est capable de faire toute classe. Tu vois ce que je veux dire ?

 
Je la sent très mal ton affaire, ne serais-ce que parce que la plupart de mes arbre ne contienent pas de méthode pour ajouter un noeud.
on peut avoir un bout de code ?

 
Nan, mais j'donnais ça comme exemple. Ton arbre, il contient bien des noeuds, non !? (à moins que t'implémentes des arbres vides, mais là c'est autre chose ! ). Donc à un moment ou un autre, t'as bien une ou des méthodes qui prennent des instances de Noeud en paramètre, non ?
Et puis, le code c'est pas moi qui l'ai écrit, j'répond à la question de noldor, c'est tout !

 
Point vocabulaire : axe de spécialisation/axe de généralisation
 
Essaye de reformuler maintenant.

 
1 - ça avance à quoi au juste ton point vocabulaire ?
2 - tu pinailles alors que le sujet est clos, tout le monde à compris. (sauf toi !? )

C'est toujours intéressant d'utiliser le vocabulaire le plus précis possible, mon cher...

 
Ça m'étonnerai que le sujet soit clos dans ta tête vu comment tu définis l'affaire ; ou alors il va falloir faire une demande de réouverture de dossier.

débat "is a" vs "use a".
 
je vote pour le "use a" !

  heu le "is a" ca correspond a l'heritage, et le "use a" a une association du genre aggrégation/composition ... donc il y a pas de versus  
 

ben si : assez souvent, pour réutiliser les possibilités d'un objet, tu as le choix entre l'étendre ou l'agréger ...
 
exemple de débat : la classe java.util.Stack qui étend Vector, ce qui est une abération pour une pile ... ca a fait couler pas mal d'encre

C'est pas compliqué si la question ce pose c'est délégation ; le mec qui est pas jouasse fera un adaptateur.
Par contre, quand ta hiérarchie est polluée tu te touches pour corriger.

Ouais, c'est bien ce que j'dis : le sujet est clos, depuis une quinzaine de posts d'ailleurs. Donc, à part que Raynaud m'emmerde avec je sais trop quels détails à la con, le sujet est clos.

Ha ok, j'avais pas pigé !
 
Ben dans ce cas, je pense que quand on peut et que c'est justifié par une spécialisation, le "is a" est plus pratique