Dart : l'alternatif à JavaScript de Google sort en version 1.2

Le , par Hinault Romaric, Responsable .NET
À la suite de Microsoft qui a publié la Release Candidate de TypeScript 1.0, Google a dévoilé une nouvelle itération de son langage Dart.

TypeScript et Dart ont en commun de vouloir corriger les faiblesses de JavaScript. Alors que TypeScript est une sorte de « super JavaScript » entièrement compatible avec celui-ci, Dart est un langage alternatif proposé par Google, avec pour objectif inavoué la mise à la retraite du langage de Script.

La nouvelle version du langage de programmation structuré pour le Web rend plus facile le débogage des applications. Les points d’arrêt peuvent maintenant être fixés sur des affectations de variables locales. Le débogueur a été optimisé et élimine certains effets secondaires liés à son utilisation.

La bibliothèque de base de Dart continue à évoluer, avec un accent sur les performances. Le débit du module WebSocket a augmenté d’un facteur de quinze depuis la version 1.0. La vitesse des primitives asynchrones de base a également été améliorée de 10 %.


L’environnement de développement Dart Editor introduit un meilleur support d’Angular (navigation, recherche et ré-factorisation). Dart 1.2 apporte également des correctifs de bugs, des améliorations de performances et des améliorations pour la machine virtuelle Dart, le compilateur, les bibliothèques et les outils.

Dart a été adopté en décembre dernier par l’Ecma, qui a mis sur pied un comité pour superviser la création d’une norme pour le langage, afin de favoriser son adoption par l’industrie, notamment les éditeurs de navigateur.

Télécharger Dart v1.2

Source : Notes de version

Et vous ?

Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 27/02/2014 à 12:55
Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?
ni l'un ni l'autre

pour moi vouloir ajouter des cntrainetes fortes sur le typage n'est pas meilleur ou moins bon que le type dynamique de javascript.
je ne vois pas en quoi une classe est plus pertinant qu'un prototype.
Code javascript : Sélectionner tout
1
2
3
4
5
6
7
foreach(Object element in myCollection) { 
  if (element instanceOf MyClass) { 
     console.log(((MyClass)element).myMethod()); 
  } else { 
     console.log("methode non supportée : " + element.toString() ) 
  } 
}
Code javascript : Sélectionner tout
1
2
3
4
5
6
7
foreach(element in myCollection) { 
  if (element.myMethod && "function" == typeof element.myMethod) { 
     console.log(element.myMethod()); 
  } else { 
     console.log("methode non supportée : " + element); 
  } 
}


dans un cas je vérifie que mon objet supporte l'usage d'une méthode en vérifiant qu'il appartient à une classe, dans le l'autre que la méthode existe.
le boulot est le même. au détail près que je peux dynamiquement ajouter la dite méthode à un objet alors qu'il faut redéfinir la classe et réinstancier les objets pour faire la même chose.

C'est quoi la faiblaisse ?
A+JYT

Avatar de Lutarez Lutarez - Membre chevronné https://www.developpez.com
le 27/02/2014 à 14:03
Citation Envoyé par sekaijin Voir le message
le boulot est le même. au détail près que je peux dynamiquement ajouter la dite méthode à un objet alors qu'il faut redéfinir la classe et réinstancier les objets pour faire la même chose.
Justement, à titre personnel, c'est la raison majeure qui me fait détester le Javascript.

Quand je développe une application, je réfléchis en amont à l'architecture de mon code : les différentes entités, comment chaque composant va interagir, les fonctionnalités que je dois implémenter, etc. De là, et de là seulement, je serai en mesure d'écrire mon application. Ce n'est que très rarement que j'aurai besoin de modifier mon architecture. Avec du prototypage, toute cette réflexion en amont peut être réduite à néant car n'importe quoi peut s'amuser à redéfinir le comportement d'une méthode.

Pour la petite histoire, dans le cadre d'un ancien travail, j'avais réussi à détourner une IHM Siebel pour mon usage (automatisation de la saisie d'informations) en redéfinissant une fonction Javascript, juste en utilisant IE7... Je pouvais même modifier des valeurs en lecture seule !
Avatar de anthyme anthyme - Membre expérimenté https://www.developpez.com
le 27/02/2014 à 14:44
Citation Envoyé par sekaijin  Voir le message
Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?
ni l'un ni l'autre

pour moi vouloir ajouter des cntrainetes fortes sur le typage n'est pas meilleur ou moins bon que le type dynamique de javascript.
je ne vois pas en quoi une classe est plus pertinant qu'un prototype.
Code javascript : Sélectionner tout
1
2
3
4
5
6
7
foreach(Object element in myCollection) { 
  if (element instanceOf MyClass) { 
     console.log(((MyClass)element).myMethod()); 
  } else { 
     console.log("methode non supportée : " + element.toString() ) 
  } 
}
Code javascript : Sélectionner tout
1
2
3
4
5
6
7
foreach(element in myCollection) { 
  if (element.myMethod && "function" == typeof element.myMethod) { 
     console.log(element.myMethod()); 
  } else { 
     console.log("methode non supportée : " + element); 
  } 
}

Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on nfait pas de test d'instanceOf.
On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.
Avatar de LSMetag LSMetag - Membre expert https://www.developpez.com
le 27/02/2014 à 15:07
Citation Envoyé par anthyme

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.
Je suis d'accord avec ce point de vue. On est en plein dans la norme EcmaScript et on reste 100% compatible avec du Javascript. On peut nuancer en soulignant que Dart a désormais également sa cellule de normalisation (en général les devs sont plus soucieux des normes que les entreprises). TypeScript a plus de chances de percer et tout plugin/framework Javascript est compatible alors qu'il faut en créer pour Dart (Polymer et AngularDart me suffisent en tout cas pour le moment). Le Javascript généré est probablement plus clair et performant que celui de Dart (je n'ai pas testé)

Pour ma part j'ai une préférence pour Dart. D'une part, les performances de Dart natif sont bien supérieures au Javascript natif. D'autre part, parce que c'est simplement un autre langage, une autre syntaxe, qui me permet d'esquiver tout ce qui peut ressembler de près ou de loin à Javascript, et que le Javascript que l'on génère pour un fallback, on s'en bat un peu le coquillage tant qu'il est performant et fiable. On peut penser que j'ai une dent contre le changement. Je ne sais pas. J'ai mes habitudes avec PHP/C#/Java,... et ne me sens pas du tout à l'aise quand je fais du Javascript.

Bref, TypeScript ajoute à Javascript ce qui lui manque et corrige des comportements aberrants, tout en conservant une grande compatibilité avec l'existant Ecmascript. Mais comme la syntaxe et les mécanismes de Javascript me rebutent, alors je préfère me concentrer sur Dart, même si professionnellement TypeScript aurait sans doute été un meilleur choix. De toute façon, si aucune boîte ne veut de moi avec mes choix de compétences, je créerai alors la mienne ^^.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 27/02/2014 à 15:19
Concernant typescipt, je le trouve intéressant car il ne cherche pas à révolutionner les choses et se contente d'ajouter un typage statique à javascript pour faciliter les gros projets. C'est aujourd'hui le moyen le plus naturel de faire de la programmation web avec un typage statique. C'est déjà prêt, c'est élégant, c'est efficace et ça ne nécessite aucune modification des navigateurs.

Quant à Dart, s'il semble "meilleur" que Javascript (disons qu'il a moins de défauts de jeunesse mais les différences au niveau du système de typage sont une affaire de goûts et de couleurs), sa valeur ajoutée me semble trop faible pour justifier cette couche de plus au sein des navigateurs. Pour moi l'avenir du web ce n'est pas de supporter 22 langages similaires au sein du navigateur et soixante couches d'API, avec une effroyable plomberie derrière pour obtenir des performances dignes de ce nom. Surtout que si on ajoute Dart ensuite on va nous bassiner que ça commence à bien faire et qu'on ne va pas en plus rajouter un pNaCl/asm.js.

La priorité à l'heure actuelle selon moi c'est de rendre la navigateur plus simple et plus neutre : un byte code simple pour autoriser tous les langages, un javascript à peu près figé (compatibilité), un jeu d'API de plus en plus gros, et un html moderne de plus en plus simple et dépouillé, qui sera de moins en moins utilisé au fur et à mesure que des moteurs de rendu tierce-parties écrits en javascript/bytecode avec accélération GPU (à la famo.us) le supplanteront. Grosso modo l'innovation ne viendra plus de ces standards mais de biblios tierce-parties tandis que le navigateur aura vocation à devenir un OS stable et concis à mesure qu'il abandonnera ses racines des 80's, quand html se voulait un langage de pagination et javascript un petit truc pour bricoler.
Avatar de LSMetag LSMetag - Membre expert https://www.developpez.com
le 27/02/2014 à 15:44
Citation Envoyé par DonQuiche

Quant à Dart, s'il semble "meilleur" que Javascript (disons qu'il a moins de défauts de jeunesse mais les différences au niveau du système de typage sont une affaire de goûts et de couleurs), sa valeur ajoutée me semble trop faible pour justifier cette couche de plus au sein des navigateurs. Pour moi l'avenir du web ce n'est pas de supporter 22 langages similaires au sein du navigateur et soixante couches d'API, avec une effroyable plomberie derrière pour obtenir des performances dignes de ce nom. Surtout que si on ajoute Dart ensuite on va nous bassiner que ça commence à bien faire et qu'on ne va pas en plus rajouter un pNaCl/asm.js.
Tout dépend de l'utilisation qu'on veut faire de Dart. Si on veut s'en servir pour du Web, alors il vaut mieux s'en servir comme du Java : c'est à dire un code en Dart, puis un fichier compilé derrière en JS utilisant les standards du Web. Ne considérer alors la VM Dart que comme un bonus optionnel de performances.

Si par contre on s'en sert côté serveur, alors utiliser la VM Dart que l'on peut faire tourner en mode console.

C'est pour ça que je trouve que la valeur ajoutée de ce langage n'est pas si faible, grâce à la compilation en Javascript qui s'avère meilleure que beaucoup d'autres "alternatives". Il permet simplement d'oublier Javascript, tout en continuant de l'utiliser.
Avatar de anthyme anthyme - Membre expérimenté https://www.developpez.com
le 27/02/2014 à 18:15
Qu'est ce qui te rebutes dans la syntaxe ?

Si c'est le pattern module pour les namespaces ( (function () { ... })() ), l’écriture de pseudo modèles objets closure et prototype, ou les lambda trop verbeuses (c'est tout ce qui me rebute le plus perso).
Et bien tout ceci n'est plus applicable en typescript, en fait on a l'impression d’écrire sur c#/java

Sinon la génération de code est très très light et propre, et ça c'est plutôt cool ça si on veut se débarrasser de la techno, on peut et retourner sur du javascript
C'est un point important à prendre en compte pour la pérennité d'un projet.
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 27/02/2014 à 18:57
Citation Envoyé par anthyme Voir le message
Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on nfait pas de test d'instanceOf.
On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.
je ne suis pas d'accord les languages supprotant l'héritage multiples sont pas légions. et lorsque tu a des objets qui sont issue de lib ou framwork tu ne peux pas les mettre dans une même collection typé c'est ainsi qu'on voit des List<Object> et autre truc car la seul classe commune est alors Object.
et tu n'a pas le choix si tu vérifie pas tu part dans les choux.

je ne comptes pas le nombre de CastException que je vois passé sur le SI dans des produit à plusiers centaine de milliers d'euros lorsque ce n'est pas des nombres à plus de 6 chiffre.
Tu peux fermer les yeux mais si tu vérifie pas un jour ça te tombe dessus.

jutilise plusieurs normes qui définissent dans leur dommaine une représentation d'un ensemble d'objets. je fait appel à plusieurs fournisseurs qui propose chacun une implémentation d'une des normes. mais moi je manipule des objets dans l'ensemble de ces normes
une réalié au quotidient pas le choix la seule classe qui est capable de servir de base commune c'est Object.
certaines des lib fournissent la méthode dont j'ai bessoin d'autre pas. les classe sont final impossible de les dérivers. impossible même si on pouvait des dériver de faire en sorte que la lib produise des objets dérivés elle n'est pas là pour ça. impossible donc d'avoir un moyen d'être sur d'avoir la même méthode partout.
impossible de faire un traitement simple en parcourant les objet et en appliquant sur chacun une methode. du coup on caste on fait de s méthode utilitaire etc.
on pisse du code.

avec un typage dynamique on transmute son objet. on lui attache la méthode de son chox à la volée.

Pourquoi tant de language lève les contrainte de classes ? pourquoi tant de language joue avec des mécanisme d'introspection ? pourquoi voit-on fleurir les injection de byteCode ?

Parfoit les classes bien rigides sont des contraintes trop fortes.
Je n'ai pas dit toujours, j'ai dit parfois.

et lors on est confromté quotidiennement à ce genre de difficultés où on fini par pondre des centaines de lignes pour 1 appel de méthode ont change de méthode de travail et on prends des outils qui ont d'autres avantages pour d'autres usages avec des façons de travailler différents.

non le typage dynamique n'est pas une faiblaisse c'est une force. tu en as besoin ou pas mais tout comme les classe sont une force pour certains usage le typage dynamique en est une pour d'autres.

Et donc aucun de ces deux language est le mieux placer pour paliser les faiblaisses (force) de JS.
Il ont des caractéristiques différentes qui offre des outils bien adapté à certains usages et moins à d'autres. exactement comme javascript et n'importe quel autre langage.

pas plus tard qu'aujourd"hui une trantaine de classe ou le seul boulot à faire est
Code : Sélectionner tout
transValue = translate[origValue]
un truc très con. finalement mais voilà les classes d'origines ne permettent pas de récupréer la listes des valeurs des membres et les classe destinatrices ne permettent pas de fournir une liste de valleur de membre. pout trente classes il faut faire pour des centaines de membres
Code : Sélectionner tout
out.setChamp1(translate.get(in.getFild1()))
biensur les nom des champs ne sont pas homogènes c'est donc des centaines de lignes à écrire. alors qu'avec un langage plus souple comme js une boucle sur tous les membres de l'objet une map qui traduit le nom du champ une autre les valeur et
Code : Sélectionner tout
out[translateNom[membre] = translate[origValue]
en 3 ligne et une table de paramètre c'est fini pour toute les classes. les lib évolue de nouvelle classes arrive pas de pb on ajoutes des valeurs dans la table de traduction.

efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.
au final en java avec un 10aine de lignes de code et en jouant avec l'introspection on passe outre les protect private et autre artifice des classes java et on fait le vrai boulot soit le smême trois lignes qu'en JS. mais pour y arriver il faut casser le principe même des classe.

J'ai vu des truc monstrueux dans ma carrière. des gars qui pour évider des jours de travail ce sont apperçu que des classe d'un fournissuer officiel estait sérialisable en java. ils ont écrit un jeux de classe ayant les mêmes noms. dans un prepier système il utilisaient les classes officielle du fournissuer qu'ils sérialisaient. le deuxième les lisait en utilisant leur propre classes. la sygnature dans la serialisation correspondant. il faut méchamant voir l'esprit tordu pour en arriver là. la raisont était l'impossibilité de faire ce qu'ils avaient besoin de faire avec les classes dorigine et la trop grande quantiter de code à produire pour passer d'une représentation à l'autre.

et il y a des absurdité partout en javascript dans 90% des développements. voici que l'ontrouve.
on a un élément du dom qui possède les méthode onclick onchange etc. et on va créer une fonction globale pour chaqune de ces méthodes puis on va créer autant de fonction annonyme quon va attacher au onclick et autre handler. ces fonction ne feront rien d'autre que d'appeler une fonction globale.
pourtant tout cela est objet ce revient à la chos esuivante.

c'est comme si en java on a la classe Element qui a les méthode onClick onChange chaqu'une de ces méthone ne faire rien d'autre que d'appel Main.uneMethode() et donc on ajoute les méthode qui font le boulot dans la classe Main. ce n'est pas 90 c'est même dans bien plus que ça.
Pourtant javascript permet de faire les choses simples il suffit d'attacher directement les méthode qui font le bouot à l'élément.
Si on réfléchi comme en java i faudrait dériver la classe Element pour cet élément là. pour avoir un élément qui porte CES methode là et pas d'autres.
C'est sur que si on fasait ça en java on aurait plus de 60% des classe qui n'auraient qu'une seul objet.
Il suffit de ne pas penser classe mais prototype et ojet dynamique pour comprendre que l'objet de la classe Element peut recevoir toutes les méthodes tous les attributs dont il a besoin.

A+JYT
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 27/02/2014 à 19:54
Citation Envoyé par sekaijin Voir le message
je ne suis pas d'accord les languages supprotant l'héritage multiples sont pas légions. et lorsque tu a des objets qui sont issue de lib ou framwork tu ne peux pas les mettre dans une même collection typé c'est ainsi qu'on voit des List<Object> et autre truc car la seul classe commune est alors Object.
Je trouve en général tes avis sur les technos web très intéressants mais concernant les langages typés il est clair que tu es à côté de la plaque. Des List<Object> je n'en rencontre jamais parce qu'on n'a pas besoin de listes d'objets hétérogènes, ou alors très rarement. Et si vraiment tu as besoin de faire ça (une fois tous les cinq ans), alors le motif "adaptateur" est là pour ça.

Les seules fois où le typage statique me met inutilement des bâtons dans les roues, c'est relatif aux types paramétrés. Et encore c'est parce que je fais beaucoup de C# et que les types paramétrés y sont rudimentaires.

je ne comptes pas le nombre de CastException que je vois passé sur le SI dans des produit à plusiers centaine de milliers d'euros lorsque ce n'est pas des nombres à plus de 6 chiffre.
Là aussi je n'en rencontre jamais alors peut-être l'application a t-elle justement été conçue par quelqu'un qui, comme toi, est davantage familier des typages dynamiques et en adopte les façons de faire.
Par ailleurs s'il y a erreur sur le type de donnes attendu, mieux vaut que ça te bondisse tout de suite à la tronche avec une exception que de voir le truc accepté en douce pour créer un bug tris kilomètres plus loin.

une réalié au quotidient pas le choix la seule classe qui est capable de servir de base commune c'est Object.
certaines des lib fournissent la méthode dont j'ai bessoin d'autre pas. les classe sont final impossible de les dérivers. impossible même si on pouvait des dériver de faire en sorte que la lib produise des objets dérivés elle n'est pas là pour ça. impossible donc d'avoir un moyen d'être sur d'avoir la même méthode partout.
impossible de faire un traitement simple en parcourant les objet et en appliquant sur chacun une methode. du coup on caste on fait de s méthode utilitaire etc.
on pisse du code.
Apparemment tu parles d'un cas particulier et je te garantis qu'il est très particulier. Encore une fois peut-être auriez-vous mieux fait de faire un simple adaptateur au début.

Pourquoi tant de language lève les contrainte de classes ? pourquoi tant de language joue avec des mécanisme d'introspection ? pourquoi voit-on fleurir les injection de byteCode ?
Quoi, les besoins de métaprogrammation n'existent pas avec les langages dynamiques ? Si tu souhaites logger tous les appels pour les besoins du débogage, tu y penses très fort et ça se produit, ou alors tu mets en place une plomberie qui va modifier tes instances à la volée ?

Parfoit les classes bien rigides sont des contraintes trop fortes.
Je n'ai pas dit toujours, j'ai dit parfois.
Tout à fait. Et l'absence de contraintes n'est pas toujours une bonne chose non plus.

Par contre plus le projet est gros, plus le typage statique est utile. C'est à ce besoin que répond TypeScript.

et lors on est confromté quotidiennement à ce genre de difficultés où on fini par pondre des centaines de lignes pour 1 appel de méthode ont change de méthode de travail et on prends des outils qui ont d'autres avantages pour d'autres usages avec des façons de travailler différents.
Je pense vraiment que vous avec un très gros problème d'architecture.

biensur les nom des champs ne sont pas homogènes c'est donc des centaines de lignes à écrire. alors qu'avec un langage plus souple comme js une boucle sur tous les membres de l'objet une map qui traduit le nom du champ une autre les valeur et
Code : Sélectionner tout
out[translateNom[membre] = translate[origValue]
en 3 ligne et une table de paramètre c'est fini pour toute les classes.
efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.
Autrement dit en JS vous implémentez un pseudo-adaptateur, alors qu'en Java vous gérez tous les cas manuellement à chaque fois. A nouveau pourquoi ne pas avoir mis en oeuvre ce motif ?
Avatar de la.lune la.lune - Membre chevronné https://www.developpez.com
le 27/02/2014 à 22:16
Citation Envoyé par anthyme Voir le message
Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on fait pas de test d'instanceOf.
On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire
Bon je ne partage pas le même avis sur istanceof, car même dans les lagunages fortement typés, le moment d’héritage on ne peut pas se permettre de faire un cast sur un objet de type de la classe mère, dans le moment où on est pas sûr que l'objet qui sera passé sera bien sûr l'objet contenant la méthode de la classe fille voulue. A part le fait d'appeler la méthode qui est défini dans la classe mère redéfini en calasse fille, dans le cadre de polymorphisme. Dans tous les langages objets le compilateur est incapable de connaitre le type de objet fille qu'on va appeler, d'où un test avant de faire le casting.

Citation Envoyé par DonQuiche Voir le message
Je trouve en général tes avis sur les technos web très intéressants mais concernant les langages typés il est clair que tu es à côté de la plaque. Des List<Object> je n'en rencontre jamais parce qu'on n'a pas besoin de listes d'objets hétérogènes, ou alors très rarement. Et si vraiment tu as besoin de faire ça (une fois tous les cinq ans), alors le motif "adaptateur" est là pour ça.
Et il n'est pas toujours question de List<Object> mais d'un concept bien connu qui ne s'applique pas forcement sur la classe Object, mais dès que les contraintes de travailler avec des objets filles, en manipulant des objet typés de la classe mère, le problème se pose et l'oublie de ce test fait déjà l'objet un bug même si ça ne se manifeste pas à notre vu. Je me demande comment réaliser des architectures et des conception de qualité utilisant des design pattern et s'assurer qu'il n y a pas de bugs de casting quelque part, si on jette l'option du test sur instanceof.

A moins de développer une application qui n'exploite pas fortement les conceptions objets.
Contacter le responsable de la rubrique Accueil