Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2732 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  [Java 1.5] Types generiques

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Java 1.5] Types generiques

n°760777
Giz
Posté le 11-06-2004 à 19:35:09  profilanswer
 

Je travaille avec Java 1.5. Dans la doc java, pour la classe Hashtable, la méthode put a le prototype suivant :


public V put(K key, V value)


 
cette classe implemente l'interface Map<K,V>.
 
J'utilise cette classe. Ce qu'il y a de tres pratique c'est que les methode (et dont put () ) accepte comme key un type K. Je ne sais pas trop ce que signifie ce type generique mais cela permet de donner comme cles a hacher des strings, des int, des pointeurs, etc...
Dans mon programme, j'utilise une table de hashage. Seulement la cle que je dois hachée, c l'utilisateur qui me la donne. Or j'ai "fixé" le type de la cle (cle que me donne en argument l'utilisateur) a "Object" : j'ai aucune idee de ce que peut etre le type reel de la cle, c l'utilisateur qui me passera sa cle a hacher. Par consequent, je suis condamne qu'a hacher des adresses d'Object. J'aimerais bien faire comme la classe Hashtable, c'est a dire que la cle que  l'utilisateur me donne soit de ce fameux type "K" qui correspond a tout type. Seulement, comment l'utiliser ce type K ? (par exemple si je mets une instruction, "K key = null;", ca passe pas du tout)
 
Comment faire ? Merci.  :jap:


Message édité par Giz le 07-07-2004 à 12:06:48
mood
Publicité
Posté le 11-06-2004 à 19:35:09  profilanswer
 

n°760816
benou
Posté le 11-06-2004 à 20:27:56  profilanswer
 

ben là ce que tu veux faire c'est écrire une classe générique => http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf


---------------
ma vie, mon oeuvre - HomePlayer
n°788941
Giz
Posté le 07-07-2004 à 12:06:26  profilanswer
 

benou a écrit :

ben là ce que tu veux faire c'est écrire une classe générique => http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf


 
Merci, je viens de regarder et a ce que j'ai compris on declare la classe ainsi :
 


public class uneClasse<T> implements uneInterface


 
et maintenant, je pourrais utiliser le type T pour les variables a l'interieur de la classe uneClasse. C'est bien ca ? parce que ca compile pas ce truc (ca m'indique une erreur de syntaxe, il manque une '}') le '<T>' ca lui plait pas :/ , comment corrige cela ?

n°788987
raytaller
Posté le 07-07-2004 à 12:41:53  profilanswer
 

faut pas rajouter -source 1.5 à la commande de compilation ?

n°788997
Giz
Posté le 07-07-2004 à 12:46:51  profilanswer
 

raytaller a écrit :

faut pas rajouter -source 1.5 à la commande de compilation ?


 
Bon merci, entre temps j'a v reinstaller et j'ai oublie de remettre cette option de compilation.
Merci  :hello:

n°789075
Giz
Posté le 07-07-2004 à 13:34:31  profilanswer
 


Let s test our understanding of generics. Is the following code snippet legal?
 
List<String> ls = new ArrayList<String>(); //1
List<Object> lo = ls; //2
 
Line 1 is certainly legal. The trickier part of the question is line 2. This boils down to the question: is a List of String a List of Object. Most people s instinct is to answer:  sure! . Well, take a look at the next few lines:
 
lo.add(new Object()); // 3
String s = ls.get(0); // 4: attempts to assign an Object to a String!
 
Here we ve aliased ls and lo. Accessing ls, a list of String, through the alias lo, we can insert arbitrary objects into it. As a result ls does not hold just Strings anymore, and when we try and get something out of it, we get a rude surprise. The Java compiler will prevent this from happening of course. Line 2 will cause a compile time error. In general, if Foo is a subtype (subclass or subinterface) of Bar, and G is some generic type declaration, [g] it is not the case that G<Foo> is a subtype of G<Bar>[/g]. This is probably the hardest thing you need to learn about generics, because it goes against our deeply held intuitions. The problem with that intuition is that it assumes that collections don t change. Our instinct takes these things to be immutable. For example, if the department of motor vehicles supplies a list of drivers to the census bureau, this seems reasonable. We think that a List<Driver> is a List<Person>, assuming that Driver is a subtype of Person. In fact, what is being passed is a copy of the registry of drivers. Otherwise, the census bureau could add new people who are not drivers into the list, corrupting the DMV s records.


 
Je n'ai pas compris ce qui est en gras. kk1 peut m'expliquer  :(
 
EDIT : apparemment ils font une distinction entre le type generique T d'une collection qui lui N'EST PAS considere comme un Object et le type reel d'un element de la collection qui lui est toujours comme un Object.
 
Pkoi cette difference ?  :??:


Message édité par Giz le 07-07-2004 à 13:53:37
n°789261
pascal34
one point !
Posté le 07-07-2004 à 15:54:44  profilanswer
 

Giz a écrit :


 
Je n'ai pas compris ce qui est en gras. kk1 peut m'expliquer  :(
 
EDIT : apparemment ils font une distinction entre le type generique T d'une collection qui lui N'EST PAS considere comme un Object et le type reel d'un element de la collection qui lui est toujours comme un Object.
 
Pkoi cette difference ?  :??:


 
Parce que dans ce cas, Foo et Bar sont des CLASSES et que le Générique G est une META-CLASSE.
Foo et Bar interviennent comme des paramètres au niveau de G et non comme des objets.
Même si on peut faire un parallèle entre classe->instance de classe et meta-classe->classe, y'a des choses qui ne se passent pas pareil dans le 2eme cas.
 
La relation naturelle d'héritage au niveau des générique est (en admettant que Foo dérive de Bar):
H<Foo> dérive de G<Foo> et pas G<Foo> dérive de G<Bar>


Message édité par pascal34 le 07-07-2004 à 15:57:00
n°789455
Giz
Posté le 07-07-2004 à 18:09:42  profilanswer
 

Merci Pascal34 pour ta reponse  :jap:  
 
Je viens de lire la doc, et je tente d'utiliser ces fameux types generiques. Mais bon je me confronte aux problemes de syntaxe maintenant  :(  
 
Voila mon cas :
 
soit la classe abstraite suivante (contenant entre autres une fonction):
 


public abstract class Problem<T>
{
...
abstract public T[] makeSuccessors (T state);
...
}


 
soit la classe suivante (heritant de la classe ci-dessus) :


public class TSP extends Problem<T>
{
...
 //definition de la methode
 public T[] makeSuccessors (T state)
 {
 ...
 }
...
}
 


 
He bien la syntaxe de la classe ci-dessus merde completement :/ (celle de la 1ere est OK!)
Ce sont ces fameux types T qui font tous merde et qui me provoquent les erreurs de compilation. KK1 connait la syntaxe ? :/


Message édité par Giz le 07-07-2004 à 18:10:37
n°789539
Giz
Posté le 07-07-2004 à 19:37:53  profilanswer
 

Bon je viens de trouver l'erreur :). En fait il faut remplacer T par le type que l'on desire (normal). Ce qui est bete c'est que je ne peux utilisez les type basique (int, char, ...), il veut une reference.
C'est normal ca ?
Si oui, alors comment je resouds mon probleme du 1er message ?  :ange:
Pour etre direct : comment hash-t-on un type basique (int, char...) en Java ?


Message édité par Giz le 07-07-2004 à 19:56:25
n°789576
Giz
Posté le 07-07-2004 à 20:14:54  profilanswer
 

Bon je viens d'avoir la reponse parfaite a ma question  [:thraell]  
 
si ca vous interesse... :
 


The hash code of an object is an integer value that's computed using the value of the object. For example, for a String object, the characters of the string are used to compute the hash code. For an Integer object, the integer value is used to compute the hash code.  
 
Hash codes are typically used as an efficient way of comparing the values of two objects. For example, if the hash code of the string "hello" is 33, another String object with the same contents would also a hash code of 33.  
 
 
If the hash codes of two object values are different, the object values are guaranteed to be different. However, if the hash codes of two object values are the same, the object values are not guaranteed to be the same. An additional call to Object.equals() must be made to confirm that the object values are the same. A good hash code algorithm will minimize the chance of two different values having the same hash code.  
 
 
The `==' operator is the most efficient way to determine if two objects (rather than object values) are the same. However, in very limited applications, it may be necessary to get the hash code of an object (called the identity hash code) rather than of the object value.


 
url : http://javaalmanac.com/egs/java.lang/GetHash.html :)

mood
Publicité
Posté le 07-07-2004 à 20:14:54  profilanswer
 

n°790451
Giz
Posté le 08-07-2004 à 15:43:51  profilanswer
 

Bien maintenant les types generiques me confrontent a la structure de mon programme :/
Voila comment ce dernier se presente :
 
Un probleme est defini par une classe abstraite qui fourni un modele de ce que doit contenir au minimum la classe TSP (= le probleme a proprement dit) :
 


public abstract class Problem<T>
{
...
 abstract public T randomState ();
...
}
 
public class TSP extends Problem<Integer>
{
...
 public Integer randomState ()
 {
  ...
 }
...
}


 
De facon completement independante, je dispose d'une classe de strategie (ici AntSystem) pour resoudre un probleme quelconque donne en argument.
 


public interface AntSystemGeneric
{
...
 public boolean isEnd (LinkedList path, Object userData);
...
}
 
public class AntSystem
{
...
 public AntSystem (final AntSystemGeneric asg, final Problem     problem, ...);
 {
  ...
 }
...
}


 
Et enfin, je dispose d'une classe SearchProblem qui permet la "fusion" en faisant coordonner le probleme et la strategie.
 


public class SearchProblem implements TSPGeneric, AntSystemGeneric
{
...
 public SearchProblem ()
 {
  ...
  TSP tsp = new TSP (...);
  AntSystem as = new AntSystem (this, tsp,...);
  ...
 }
 
 public boolean isEnd (LinkedList path, Object userData)
 {
  ...
 }
...
}


 
Le probleme est dans la fonction isEnd defini dans la classe SearchProblem. Cette fonction, implementee par SearchProblem, est appelee dans le code de la classe AntSystem. Or la LinkedList path contient des etats du probleme TSP, etats qui eux sont de type Integer. Seulement seule la classe TSP sait que ce sont des etats de type Integer. Par consequent, la fonction isEnd implementee dans la classe SearchProblem ne peut identifier le type d'un element dans la LinkedList path recu en argument de la part de l'appel a cette fonction dans la classe AntSystem.
Ce que je voudrais donc c'est que les classes AntSystem et SearchProblem soient capables d'identifier le type T du probleme (ici pour le probleme TSP, le type est Integer). Comment puis-je faire ?
 
J'espere avoir ete clair ! (Sinon demandez moi !)
Merci  :jap:

n°813594
pascal34
one point !
Posté le 03-08-2004 à 13:51:13  profilanswer
 

Giz a écrit :


Code :
  1. public class TSP<T> extends Problem<T>
  2. {
  3. ...
  4. //definition de la methode
  5. public T[] makeSuccessors (T state)
  6. {
  7. ...
  8. }
  9. ...
  10. }




t'as essayé de paramétrer ta classe TSP par le type T ?.
Car ta classe TSP doit être un générique et elle n'était paramétrée par rien du tout !


Message édité par pascal34 le 03-08-2004 à 13:52:18

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  [Java 1.5] Types generiques

 

Sujets relatifs
[java pour les nuls] question gratuite sur la lecture d'un fichier[java] Les Set se basent sur quoi pour comparer ?
fusionnement des fichiers excel en java[C] problème de types de données
[Java][Débutant] java.lang.NoClassDefFoundError : ??[Java] Problème de design : repercution de modifications
[java jboss] j2EE[Java-SQLServer] Appeler une procédure stockée contenant des espaces
[Java] Isoler proprement un motif dans une String[Java 1.5] Probleme avec les types generiques
Plus de sujets relatifs à : [Java 1.5] Types generiques


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR