Eviter un cast

Bonjour,

Tout d'abord, je n'aime pas les casts. : )

Une solution peut-être pas très propre me vient à l'esprit pour des petits trucs isolés.

Code:

---

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

class A { B asB(){ throw new IllegalStateException("Bad Type"); } C asC(){ throw new IllegalStateException("Bad Type"); } }   class B extends A { final B asB(){ return this; } }   class C extends A { final C asC(){ return this; } }

---

En gros ça remplace le check pour le cast par un appel de méthode. Et surtout il n'y a pas de cast dans mon code.

Est-ce que quelqu'un sait si c'est fort différent au runtime finalement?

Merci : )

Mon petit doigt me dit que le cast doit être un peu plus lent au runtime, à cause de la vérification de type, qui me semble plus couteuse qu'une invocation virtuelle. Mais cela n'engage que mon petit doigt, pas moi. Et puis, la différence doit être très faible.

En revanche, la technique n'est applicable que si la classe mère appartient à un même lot de développement que toutes ses classes filles, ce qui n'est pas la règle générale. Un développeur étends souvent des classes dont il n'a pas la maitrise. A commencer par Object : si on a une variable Object, pas de "as".

Avec les interfaces, ça me semble inapplicable car cela multiplie le nombre de méthodes "as" à prévoir sur les interface à succès.

Bref ... mieux vaut bien utiliser les types génériques et accepter quelques cast ici et là.

Citation:

---

Envoyé par ayjdev

En gros ça remplace le check pour le cast par un appel de méthode. Et surtout il n'y a pas de cast dans mon code.

Est-ce que quelqu'un sait si c'est fort différent au runtime finalement?

---

C'est complètement différent.

• C'est contre intuitif, les autres dev de l'équipe n'utiliseront jamais cette méthode et feront un simple cast quand c'est nécessiare.
• C'est une belle erreur de design: A doit connaitre ses fille, ce qui est contraire aux concepts orienté objet.
• Avec cast vous pouvez tester avant le cast si c'est possible, via instanceof
• Avec votre code, on est en droit d'attendre que X.asA() mette tout en oeuvre pour convertir un X en un A, quitte à créer une nouvelle instance. Une fille pourrait même le faire. alors qu'avec un cast on a la garantie de rester sur la même instance.
• Le compilateur peux vous dire qu'un cast est impossible, il ne pourra pas vous dire qu'un appel à asX ne l'est pas. Exemple:
  Code:

  ---

  1 2 3

  B b= .....; C c1 = b.asC(); // compile C c2 = (C)b; // erreur de compilation: B ne pourra jamais être typecasté en C

  ---

• Si vous voulez limiter le nombre de cast et avoir des garanties sur le type, c'est pour cette raison qu'on a créé les Generics
• Votre code n'apporte rien puisque, vous transformez une Exception en une autre, le problème reste complet à l'exécution
• C'est impraticable sur des grosses hiérarchies d'objets
• Le cast, c'est vérifié par la JVM rapidement. Un appel à une méthode virtuelle nécessite la consultation de la table des méthodes virtuelles, ce qui implique déjà une vérification sur le type de l'instance. C'est donc au moins plus long

Ton dernier point m'a convaincu.

Pour les autres, je pars du principe que si la documentation est lue, ce n'est pas vraiment un problème, tant que les responsabilités sont bien définies.

Mais je me disais que si la visibilité est bien réduite, avec ces méthodes finalisées, il y avait des chances que le compilateur 'inline' l'appel et que donc au final c'est plus rapide qu'un cast.

Mon seul objectif est la rapidité.

merci

edit: c'est une situation où il n'est pas possible d'utiliser les generics.

vous faites ce que vous voulez, je ne suis pas là pour prendre les décisions à votre place. C'est du code de cochon ça, et je vous ai expliqué pourquoi.

Salut,

Citation:

---

Envoyé par ayjdev

Mon seul objectif est la rapidité.

---

Un bon conseil : changes d'objectif !

:arrow: Ton objectif devrait être de bien penser ta modélisation objet et d'utiliser des algorithme propre et clair !

Ici tu es en train de faire des trucs sales pour tenter de gagner une demi-nanosecondes par-ci par là (et encore ce n'est même pas sûr).


a++