instanceof c'est mauvais?

Bonjour,
Je dois utiliser instanceof quelque part dans mes classes mais tout le monde me dit que instanceof est une mauvaise construction. Entre autres parce que dans un design qui utilise l'héritage, si on rajoute une classe, on doit changer des choses dans les autres classes qui héritent de la même classe. Mais sinon je ne comprends pas très bien pourquoi ne pas l'utiliser. De plus, connaissez-vous une alternative "propre"?
Merci d'avance

Citation:

---

Entre autres parce que dans un design qui utilise l'héritage, si on rajoute une classe, on doit changer des choses dans les autres classes qui héritent de la même classe

---

je n'ai rien compris la, mais ce que je peut te dire c'est le suivant:
si une classe B herite de A, et si tu as un objet 'a' alors les deux proposistions suivantes sont juste :

Code:

---

a instanceof A

---

Code:

---

a instanceof B

---

pour l'autre alternative tu as peut etre le

Code:

---

tonObjet.getClass().getName();

---

voici un exemple illustrant tout ce que j'ai dis:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

class A{ int a; public A(){ }   }   public class Test extends A{   public Test(){ if (this instanceof Test)System.out.println("test"); if (this instanceof A)System.out.println("A"); System.out.println(this.getClass().getName()); }   /**          * @param args          */     public static void main(String[] args) { // TODO Auto-generated method stub new Test(); }   }

---

hope this helps.
a+

Oui, je comprend comment on utilise l'instanceof. Mais on m'a toujours dit que ce n'est jamais bon d'utiliser instanceof et qu'il vaut mieux l'éviter. Mais des fois il me semble inévitable. C'est pour ça que je demande si il existe une autre alternative.

Salut,

Effectivement il en existe une . Le POLYMORPHISME. notamment le principe de résolution dynamique des liens . dans un model d'héritage comme celui proposé plus haut , un objet a construit à partir de la classe B sous classe de A , est aussi un objet de la classe A. cet objet bénéficie donc des méthodes de la classe A sans que tu n 'aie besoin de faire un "instanceof" .
S'il t arrive de redefinir dans B des méthodes qui sont dejà definies dans A , alors ce sont celles là qui seront executées , et non celles de A et cela sans besoin de test '' instanceof'.'

En esperant que cela repond à ta question.
A+

Perso je continue à l'utiliser, car je trouve que les alternatives pure objet sont souvent moins claires à la lecture, plus difficiles à comprendre et à maintenir, du moins en java. J'ai essayé 150 trucs, je n'en ai pas trouvé qui soyent vraiment confortables.

Je pense que le fond du problème est qu'il ne faut pas s'obliger à utiliser le polymorphisme, mais, comme le reste, de ne l'utiliser que lorsqu'il est adapté. Lorsque, au fur et à mesure des évolutions du code, on trouve le polymorphisme adapté, alors les instanceofs s'effacent d'eux mêmes, et le code reste clair.

Mais se dire Je mets pas de instanceof sinon tout le monde va voir que j'y connais rien au polymorphisme est une très mauvaise approche.

Le polymorphisme est un excellent outil, du moment qu'il est en phase avec le domaine qu'il exprime. Sinon les décalages entre formalisme du code et réalité obligent à multiplier les interfaces, les interfaces d'implémentation d'interfaces, les abstractions de builder de factories, et c'est la catastrophe. Le gros défaut du polymorphisme est qu'il n'est pas évident de trouver le bon réglage pour une application ou un domaine donné. Cela ne vient que petit à petit, avec de l'expérience et en discutant avec les utilisateurs ou spécialistes.

Donc, moralité selon moi : utilise le instanceof et le polymorphisme.

Citation:

---

Envoyé par pongping

Bonjour,
Je dois utiliser instanceof quelque part dans mes classes mais tout le monde me dit que instanceof est une mauvaise construction. Entre autres parce que dans un design qui utilise l'héritage, si on rajoute une classe, on doit changer des choses dans les autres classes qui héritent de la même classe. Mais sinon je ne comprends pas très bien pourquoi ne pas l'utiliser. De plus, connaissez-vous une alternative "propre"?
Merci d'avance

---

Un cas typique où il faut éviter le instanceof, c'est ceci:

Code:

---

1 2 3 4 5

if(o instanceof A) { ((A)o).method(); } else if(o instanceof B) { ((B)o).method(); } //...

---

Parfois instanceof se justifie.
Par exemple, en ce moment pour les cours on doit faire un compilateur Java (sans optimisations). Une approche pour différencier les variables des attributs était que Attribut extends Variable, et que Attribut ait, en plus des attributs de Variable, un attribut "visibility" (private, public...).
Lorsqu'on accède à un objet Variable (pour appeler une méthode dessus par exemple), il faut qu'on teste si "on a le droit de le faire", c'est-à-dire si la variable est accessible. Pour cela on peut faire

Code:

---

if(!(variable instanceof Attribut) || ((Attribut)variable).isPublic())

---

Ce n'est finalement pas l'approche que l'on a retenu, mais il me semble que celle-ci n'est pas mauvaise.

Si quelqu'un trouve qu'elle n'est pas bonne, merci de répondre et de dire pourquoi, ça m'intéresse :)

Pour finir, il y a des endroits où il FAUT toujours utiliser instanceof:

Code:

---

1 2 3 4 5 6 7

@Override public boolean equals(Object o) { if(!(o instance MaClass) { return false; } return name.equals(o.name); }

---

Citation:

---

Lorsqu'on accède à un objet Variable (pour appeler une méthode dessus par exemple), il faut qu'on teste si "on a le droit de le faire", c'est-à-dire si la variable est accessible. Pour cela on peut faire

Code:

---

if(!(variable instanceof Attribut) || ((Attribut)variable).isPublic())

---

Ce n'est finalement pas l'approche que l'on a retenu, mais il me semble que celle-ci n'est pas mauvaise.

Si quelqu'un trouve qu'elle n'est pas bonne, merci de répondre et de dire pourquoi, ça m'intéresse :)

---

Personnellement j'aurai fait ça comme ça :

Code:

---

if (variable.isVisible(Visibility.PUBLIC))

---

Avec isVisible qui renvoie toujours true pour une variable et qui est surchargée dans Attribut pour faire la verification.

Citation:

---

Envoyé par the-gtm

Personnellement j'aurai fait ça comme ça :

Code:

---

if (variable.isVisible(Visibility.PUBLIC))

---

Avec isVisible qui renvoie toujours true pour une variable et qui est surchargée dans Attribut pour faire la verification.

---

Je trouve ça plus simple, mais moins propre.
Car pour une variable, il n'y a pas la notion de visibilité...

(même si c'est en gros la solution que l'on a retenu)

Citation:

---

Envoyé par ®om

JCar pour une variable, il n'y a pas la notion de visibilité...

---

Quand on a quelque chose du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public void machin() { int i = 1; truc(); }   public void truc() {   }

---

La variable i qui se trouve dans la table des symboles devient en quelque sort "non visible". Mais maintenant, je ne sais pas comment tu as géré ta table des symboles... Parce que pour être efficace, ça la fout peut être mal de reparcourir toutes les variables pour les mettre en "non visible" :aie: Le compilateur que j'avais fait été dans un langage plus simple, et je n'avais pas eu ce problème en tout cas.

Merci pour toutes ces réponses. Dans mon projet j'utilise beaucoup le polymorphisme mais j'étais tombé sur un problème ou le polymorphisme n'était pas possible (sauf si il fallait implémenter des méthodes vides dans certaines classes mais ceci n'est pas très beau non plus)... Je vais donc quand même utiliser instanceof.

Citation:

---

Envoyé par pongping

(sauf si il fallait implémenter des méthodes vides dans certaines classes mais ceci n'est pas très beau non plus)...

---

Pourquoi ne pas faire des classes abstraites dans ce cas ? C'est justement fait quand des méthodes n'ont pas à être implémenté dans la classe mère.

@millie, a priori le cas que tu décris ne posera pas de problème, mais bon je te dirai quand on en sera là :)

@pongping, peux-tu nous décrire le cas où tu penses avoir besoin du instanceof?

Citation:

---

Envoyé par ®om

Pour finir, il y a des endroits où il FAUT toujours utiliser instanceof:

Code:

---

1 2 3 4 5 6 7

@Override public boolean equals(Object o) { if(!(o instance MaClass) { return false; } return name.equals(o.name); }

---

---

Pas tout à fait d'accord sur ce point ;)
Pour moi, une bonne méthode equals n'utilise pas instanceof. Il faut aussi vérifier que o est de la même classe que l'objet. Sinon, on risque d'obtenir des cas où :
- a.equals(b) est true
- b.equals(a) est false
si b est d'une classe dérivée de celle de a.

Code:

---

1 2 3 4 5 6 7

@Override public boolean equals(Object o) { if ((o == null) || (o.getClass() != getClass())) { return false; } return name.equals(o.name); }

---

Citation:

---

Pour moi, une bonne méthode equals n'utilise pas instanceof. Il faut aussi vérifier que o n'est pas une instance d'une classe dérivée de MaClass.

---

Je ne vois pas le problème si tu redéfinis equal pour chaque classe fille.

Par exemple, dans le code source de Java, pour la classe Rectangle qui hérite de Rectangle2D, il redéfinisse equals :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public boolean equals(Object obj) { if (obj instanceof Rectangle) { Rectangle r = (Rectangle)obj; return ((x == r.x) && (y == r.y) && (width == r.width) && (height == r.height)); } return super.equals(obj); }

---

Simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

class MaClass { String name;   @Override public boolean equals(Object o) { if(!(o instance MaClass) { return false; } return name.equals(o.name); }   class MaClass2 extends MaClass { String name2;   @Override public boolean equals(Object o) { if(!(o instance MaClass) { return false; } if (!name2.equals(o.name2)) { return false; } return super.equals(o); }

---

Avec ce code, si tu as :
a = new MaClass('x');
b = new MaClass2('x', 'y');

Alors
a.equals(b) est true
b.equals(a) est false

PS: Pour Rectangle, si tu ne la dérives pas, c'est bon (car Rectangle2D est abstract), mais c'est pas propre. Si tu fais des tests avec Rectangle et DefaultCaret, tu pourras voir des cas bizarres

Citation:

---

Envoyé par NicoV

Pas tout à fait d'accord sur ce point ;)
Pour moi, une bonne méthode equals n'utilise pas instanceof. Il faut aussi vérifier que o est de la même classe que l'objet. Sinon, on risque d'obtenir des cas où :
- a.equals(b) est true
- b.equals(a) est false
si b est d'une classe dérivée de celle de a.

---

Pourquoi je pense qu'il faut utiliser instanceof et non getClass():

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

class A { private String name; A(String name) { this.name = name; } @Override public boolean equals(Object o) { // if(!(o instanceof A)) { if(getClass() != o.getClass()) { return false; } return name.equals(((A)o).name); } }   class B extends A { B(String name) { super(name); } }   public class TestEquals {   public static void main(String... args) { A a1 = new B("abc"); A a2 = new A("abc"); System.out.println(a1.equals(a2)); }   }

---

Code:

---

false

---

alors qu'on a définit que 2 objets A étaient égaux ssi ils avaient le même nom.

Tu peux de toute façon obtenir des cas où equals n'est pas symétrique, le plus simple étant de rentre la relation anti-symétrique (et donc une relation d'ordre), et ceci que tu testes avec instanceof ou getClass().

Code:

---

1 2 3 4 5 6 7

class C { private int i; @Override public boolean equals(Object o) { return i > ((C)o).i; } }

---

Enfin, concernant ton dernier exemple, je ne sais pas ce que tu as essayé de montrer, mais de toute façon il te manque les cast, donc il ne peut pas compiler. Et pour pouvoir les faire (les cast) de façon sûre, il faut tester o instanceof MaClass2 et non o instance Maclass dans MaClass2. Donc on ne peut pas conclure grand chose de ce test...

La javadoc de Object.equals() :

Citation:

---

It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.

---

Donc, oui pour moi, il faut normalement que equals() soit symétrique et donc ne pas utiliser instanceof sauf dans des cas particuliers.

En règle général, j'ai l'impression qu'un objet d'une classe dérivée ne doit pas être considéré égal à une objet d'une classe de base.

PS: Pour mon exemple, je n'ai pas essayé de le compiler et donc oui il manque des cast mais c'était pour présenter une explication (d'ailleurs, il manque le même cast dans ton exemple initial ;) ), et j'ai fait un copier/coller dans le 2e equals d'ou le MaClass ou lieu de MaClass2.

Pour une explication détaillée sur l'intérêt d'utiliser getClass() au lieu de instanceof, un article pas mal: http://www.geocities.com/technofundo...equalhash.html

ou encore dans Effective Java chez Sun:
http://java.sun.com/developer/Books/...a/Chapter3.pdf

Code:

---

1 2 3 4 5 6 7 8 9

// Broken - violates symmetry! public boolean equals(Object o) { if (o instanceof CaseInsensitiveString) return s.equalsIgnoreCase( ((CaseInsensitiveString)o).s); if (o instanceof String) // One-way interoperability! return s.equalsIgnoreCase((String)o); return false; }

---

OK c'est vrai qu'il y a une faille avec le instanceof...

Merci :)

Citation:

---

At this point, p1.equals(p2) and p2.equals(p3) return true, while
p1.equals(p3) returns false, a clear violation of transitivity. The first two comparisons are “color-blind,” while the third takes color into account.

So what’s the solution? It turns out that this is a fundamental problem of
equivalence relations in object-oriented languages. There is simply no way to
extend an instantiable class and add an aspect while preserving the equals
contract.

---

:rire:

: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.