instanceof c'est mauvais?

:mrgreen: Je recadre un peu, puisque la discussion n'est pas sur le equals, mais sur le instanceof :mrgreen:

J'ai beau relire l'ensemble, je ne vois pas ce qui montre pourquoi il ne faut pas l'utiliser.

On affirme mordicus que le polymorphisme est mieux ; peut-on préciser en quoi cela répond à la question ??

Le seul cas présenté (avec ((A)o).method() ou ((B)o).method()) me parait tellement évident qu'il en devient non significatif ; quand au equals... c'est plutôt un problème de equals, il me semble.

Alors ?

(et merci d'éviter un énième cours sur le polymorphisme, je connais et l'utilise).

Le polymorphisme est sans doute mieux (à voir) quand il peut s'appliquer mais il y a quand même des cas où le polymorhpisme ne s'applique pas, quand on ne peut pas toucher à la classe de base par exemple.

Par exemple, ListCellRenderer est utilisé pour dessiner les éléments d'une liste. Elle reçoit en paramètre un Object, il n'y a donc pas vraiment d'autre solution que le instanceof et downcast pour avoir des affichages un peu évolué. Ici, pas vraiment possible / pratique d'utiliser le polymorphisme.

Citation:

---

Envoyé par NicoV

Par exemple, ListCellRenderer est utilisé pour dessiner les éléments d'une liste. Elle reçoit en paramètre un Object, il n'y a donc pas vraiment d'autre solution que le instanceof et downcast pour avoir des affichages un peu évolué. Ici, pas vraiment possible / pratique d'utiliser le polymorphisme.

---

Avec la généricité sur Swing, le problème serait réglé :)

Comment on fait çà simplement ? (pour utiliser un Swing générique)
A mon avis, çà serait bien compliqué pour faire des choses toutes simples.
En particulier, çà peut vouloir dire créer pleins d'interfaces supplémentaires et faire que de simples beans implémentent ces interfaces.

Par exemple, le DefaultListCellRenderer permet actuellement de gérer les Icon et les Object (en utilisant toString()). Comment on fait-çà avec des génériques ?

Voici un exemple ou je pense qu'il faut utiliser instanceof (ou une autre structure du même style). Disons qu'on a une classe A et deux classes B et C qui héritent de A. Donc

Code:

---

1 2 3 4

class A {...} class B extends A {...} class C extends A {...}

---

Disons que la classe C implémente une méthode X qui n'est pas implementée dans A ni B. Cette méthode est propre à la classe C.
Disons que dans la classe A on a une méthode Y:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class A { public Y() { ArrayList liste = (array list contenant des objets de B et de C) for (A objet : liste) { if (objet instanceof C) ((C)objet).X() ... } } }

---

C'est peut-être un peu compliqué... Mais disons que si objet est un objet de type C, alors il faut appeler la méthode X.

Je ne comprend pas pourquoi dans ton exemple, A a besoin de connaître l'existence de ses sous classes ?

Ton exemple semble artificiel en fait :? Je trouve que la hiérarchie de classe est mauvaise dans ton cas

Comment la faire alors? Car A est une généralisation de B et de C, c'est-à-dire elle contient toutes les méthodes que B et C ont en commun...

Déjà, A qui a une liste d'objet A, c'est pas super...

Ensuite, pourquoi ne pas utiliser l'héritage pour appeler des méthodes sur B et C (qui aurait pu être abstraites dans A) ?

Pour moi, A qui a besoin de connaître si une de ses sous classes est bien C pour pouvoir appliquer une méthode spécifique à C démontre une conception mauvaise.

Mais si tu mets la méthode X abstraite dans A. Alors tu dois l'implémenter dans B et C. Mais comme B n'a rien à faire avec la méthode X, la méthode sera vide dans B, et je ne pense pas que ça soit correct non plus...

Explique moi pourquoi A aurait besoin d'appeler une méthode spécifique à une de ses sous classes ? (dans une liste qui contient un peu n'importe quoi, du A, du B, du C)

Donnes moi un problème concret où ça arrive. A mon avis, ce cas n'arrive que lorsque la conception est mauvaise.

J'ai un système de donjons pour une sorte de RPG. J'ai une classe Dungeon qui est abstraite. En dessous, j'ai une classe CompositeDungeon qui hérite de Dungeon. Un CompositeDungeon est caractérisé par le fait qu'il sait contenir d'autres donjons. J'ai une autre classe BasicDungeon qui hérite aussi de Dungeon. Les BasicDungeon savent contenir des chambres (Squares). J'ai aussi les classes Shaft et Level qui héritent de BasicDungeon. Donc

Code:

---

1 2 3 4 5 6

abstract class Dungeon {...} class CompositeDungeon extends Dungeon {...} abstract class BasicDungeon extends Dungeon {...} class Shaft extends BasicDungeon {...} class Level extends BasicDungeon {...}

---

Dans la classe CompositeDungeon j'ai une méthode getShafts(). Celle-ci renvoie toutes Shafts que ce donjon contient. A noter qu'un CompositeDungeon sait aussi bien contenir des Shafts, des Levels et même des autres CompositeDungeon. Donc dans CompositeDungeon j'ai une collection de Dungeon et dans getShafts() il faut un moyen de savoir qu'un Dungeon est bien un Shaft pour le rajouter à la liste. Comprenez-vous?

Attention, il ne faut pas abuser des liens est-un quand on aurait dû utiliser un lien a-un

http://c.developpez.com/faq/cpp/?pag..._encapsulation

Par exemple, level, ce n'est pas un donjon. Ca a un donjon, ça pourrait contenir d'autres choses (une prairie ou je ne sais quoi)

Mais si, Level est un donjon et CompositeDungeon aussi.

Citation:

---

Envoyé par pongping

Comprenez-vous?

---

Ahem, non :king:

Quand c'est un pareil bordel mon conseil est de ne pas se fouler, d'être pragmatique, et d'utiliser instanceof de toutes façons cela ne peut pas être pire.

Chemin (de ronde) faisant essaie d'exprimer les relations entre les objets que tu manipules (par exemple, comme le dit millie, en regardant leur rôle) (tiens, dit millie c'est joli) (tiens dit millie c'est joli c'est joli) (bon, merci) ; peut être verras-tu mieux alors comment s'organisent leurs collections.