Bonjour à tous,  
 
J'ai un petit problème de conversion de type. J'ai un formulaire en java dans lequel se trouve une liste de choix. Par exemple, dans cette liste, on trouve "tri1" ou "tri2",....
J'ai dans mon programme des objets tri1:TRI.
Or selon le choix de l'utilisateur, j'aimerai appeler une méthode de la façon suivante : tri1.trier() ou tri2.trier(), .....
Comment pourrai je faire ceci?
 
Merci d'avance.
 

C'est quoi le problème avec "tri1.trier()" et "tri2.tirer()" ?

j'ai pas compris le problême

Si j'ai compris :
 
 - tu as une classe TRI et 2 instances de cette classe (tri1 et tri2).
 - tu récupères le choix de l'utilisateur dans une String monChoix qui peux avoir 2 valeurs ("tri1" et "tri2" )
 - si c'est ça la solution est :

 
Si j'ai tout faux, reformule ton problème

 
ce le principe de polymorphisme et de liaison dynamique
il faut faire une classe abstraite qui s'appelerai TRI et comportera une methode abstraite qui s'appelerai trier()
 
 

 
 
ensuite tu fais deux classes TRI1 et TRI,...., TRIn qui heritent de TRI et implementent la methode trier().
 
exemple pour la classe TRI1
 

 
J'espere t'avoir eclairer
 
 

... Et tu auras certainement besoin d'une factory pour utiliser pleinement la solution de axk47, the Java Warrior taking a coffee.
 
Une classe SortFactory qui contient une méthode static acceptant en paramètre le type de tri et qui renvoie une instance du sous-type de TRI correspondant au paramètre !

je suis pas certain que joquetino en soit à appliquer des design pattern ...

C'est en effet assez compliqué pour mon problème.
Bidem a compris mon problème, enfin partiellement lié à un manque de communication de ma part.

 
Je voudrai adapter ce code pour un nombre de tris très importants.
Je vais avoir dans ma liste un grand nombre de tri. C'est assez fastidieux  de faire ceci pour chaque type de tri.
J'aimerai ainsi recuperer la valeur choisi, dans une variable monChoix.
Serait-il possible de "caster" le type String vers le type TRI pour appliquer à cet objet la méthode trier()?
Suis-je explicite? Je ne suis pas certain ...

Je suppose que ta question est de savoir si on peut invoquer un objet par son nom en String. Je ne crois pas que ça soit possible en Java (en C et C++ c'est impossible du fait qu'à l'execution les objets ne sont pas référencés par les noms que tu leur as donné dans ton code source).
 
A part ça une solution pourrait être de créer une Hashtable (ou un objet équivalent du point de vue fonctionnel) contenant des paires choix/objet_à_trier ce qui te permettrait d'invoquer ta méthode trier de cette façon :
 

plutot que de mettre une String dans ta liste, met plutot directement l'objet TRI avec une méthode toString qui retourne la chaine à afficher. Comme ca tu pourras caster l'objet sélectionné dans ta liste en TRI et lui appliquer trier().
 
bien sur, tu ne peux pas directement caster une String en une variable d'un autre type. Ca n'a pas de sens ...

ok merci beaucoup.

Je ne vois pas en quoi la factory method est plus compliquée que la solution finalement proposée, si ce n'est qu'on perd le bénéfice d'un pattern au profit d'une solution moins élégante (mais tout aussi compliquée).
 
joquetino, même si tu n'es pas encore costaud en java et/ou en design, je ne te conseille pas de t'arrêter à des solutions de facilité telles que if .. else .. pour chaque tri.
 
C'est confortable de se raccrocher à qq chose qu'on connait, mais tu vas finalement déployer autant d'efforts et recontrer autant de difficultés (genre est-il possible de "caster une String en un TRI) qu'avec une solution éprouvée pour un résultat bien plus maigre.
 
Benou, tu as raison de dire qu'une factory ne soit manifestement pas directement abordable, et mon explication narrative à la classe SortFactory qui contient une méthode static acceptant en paramètre le type de tri et qui renvoie une instance du sous-type de TRI correspondant au paramètre n'évoque sûrement rien pour lui.
 
Mais je suis sûr qu'en complétant le code de axk47 par un code pour la factory et qq mots d'accompagnement, tout deviendra limipe.
 

bha juste fais le
 
mais avec le dernier truc que je proposais, y a plus un seul if ...  
personellement, j'ai pas bien compris en quoi la factory allait arranger son problème de if. Mais j'ai peut être mal compris ...

Je suis entierement d'accord avec SirCam...
Moi je me demande à quoi sert la programmation Objet et sa puissance
(liaison dynamique, polymorphisme,...) si a chaque fois on se doit passer outre et faire de la programmation conditionnelle avec plein de IF ELSE partout.
 
Si tu peux avoir milles choix et Ben tu auras milles classes(ça commence a faire bcp mais le nombre de choix est aussi large) differentes avec chacune  
sa methode trier().
 
C modulaire, flexible et tu n'a pas besoin de retoucher a toutes tes classes a chaque fois que tu rajoute un nouveau choix.
 
et c'est un bon entrainement pour le jour ou tu auras un projet plus complexe a gerer

moi aussi dans l'absolu !
mais, je commencerai pas à parler de DP à un débutant en java ...  
 
mais dans son cas, c'est quoi l'intérêt de la factory ??
le polymorphisme je vois bien, mais je vois pas où ni pourquoi utiliser une factory ...

Euh son problème à la base c'était pas juste d'appeler la méthode "trier" sur un objet de type TRI suivant le choix de l'utilisateur ? Parce que dans ce cas je ne vois pas ce que vient faire le polymorphisme là-dedans.

bha on peut imaginer que ses objets sur lequel il va apeler "trier" sont de classe différente ...

exactement  benou ;Chaque classe implementant sa propre methode trier()!

 
ta raison benou pas besoin d'une factory pour ça, introduit un DP inutilement
 
je sens que je vais me faire des amis sur ce forum    

Qu'est-ce qu'on s'amuse ici
 
En fonction du "choix", comment obtenir une instance du sous-type approprié de TRI ?
 
TRI tri = (TRI)table.get("monChoix" );
 
=> cela suppose que l'instance est déjà dans le pool, ce qui n'est pas forcément le but !!!
 
 
Benou : a priori, se lancer dans DP est ardu. Je ne les ai découverts que sur le tard, à la fin des mes études. Et là, je me suis rendu compte (avec mes condisciples) que j'en utilisait une bonne panoplie sans le savoir, simplement parce que les profs nous avaient habitués à programmer et à faire un design correct dès le départ.