Bonjour,
Je dois réaliser un exercice de cours, un programme en Java, qui parcourt un fichier texte, qui compte le nombre de mots au total du fichier puis enfin un affichage du type :
 
Mots         Nombre
maison ..... 3x
porte........ 2x
etc...
 
Ce que j 'arrive a faire : Je parcours mon fichier texte, j'extrais les mots de plus de 2 caracteres, et je les affiche pour verifier.
Maintenant, il faudrai que je stocke mes mots dans un containeur (lequel ?) et que je verifie si le mot ajouter n'existe pas deja.
 
Il faut aussi que je compte combien de fois j'ai rencontré le mot.
 
Quelle methode serait la plus appropriée ?
Merci
 
ps : sujet de l'exo
http://users.rockweb.org/java/iris [...] rJava1.pdf
(question 3-4)
 
edit : voila mon code pour le moment (il suit l'ordre des questions, donc oui il peut etre simplifier facilement, en commencant pas l expression reguliere par exemple )

stocker tes mots dans un Vector, ca devrait le faire. après avec un boolean contains(object) tu testes facilement si le mot y est déjà

j'ai trouvé un moyen plus simpa
les Maps
 
Je créais ma map et ensuite je verifie par la fonction  
maMap.containsKey(Word);
 
ca me retourne un boolean.
Tres tres pratique.
Ca permet par rapport au vertor d avoir le mot + un chiffre, comme il me faut

J'utiliserais plutôt une hashmap perso, à chaque mot un test si la hashmap contient déjà le mot en clé (containsKey), si non on ajoute le mot en clé et "1" en valeur, si oui on incrémente la valeur de 1
 
Comme ça à la fin on a un compte bien propre pour chaque mot
 
edit: fuck, grillé

oui, si tu comptes stocker en + le nb d'occurrence, alors la hashmap est parfaite
disons que c'est juste un Vector en mieux

Heuuu non, le seul lien entre les deux, c'est que tous deux sont des conteneurs
 
Les maps ne sont pas "mieux" que les listes de manière absolue, les utilisations ne sont pas les mêmes

ok ouais,  

rahh faites pas comme si vous aviez pas compris quand même

et même qu'en face du mot dans la hashMap, tu peux mettre un petit OcurencesCounter mutable ça te simplifie le code et est plus efficace.
 

 
voiloù (code non vérifé)

ah ! oui !  
 
On a pas le même style

• Pourquoi ya des toString partout? (accessoirement avec Java1.5 les hashmaps sont des generics, donc tu te débarasse de tous les casts et autres)
• Pourquoi dégages tu les lettres accentuées?
• Pourquoi ne pas créer tes nombres au moment du put? (map.put(word, new Integer(1)); map.put(word, new Integer(occurences))); de même en 1.5 l'autoboxing doit gérer ce genre de conneries tout seul non? (--, nraynaud, je me plante encore ou pas?)
• les variables locales en minuscules
• le map.remove() ne sert strictement à rien: si une clé existe déjà, un "put" avec cette clé remplace simplement la valeur associée.
• Quel est l'intérêt de "temp = Mot.intValue()+MotStoke.intValue()" par rapport à "temp = MotStoke.intValue() + 1"
• Accessoirement, faut en vouloir pour comprendre que MotStoke est le nombre d'occurences précédentes du mot dans le texte
• Tes boucles/conditions de boucles sont franchement bizarres (pourquoi ne pas utiliser un simple for )

Mask> ouais, je pense que c'est une des conditions de l'autoboxing, mais je reste sur mon holder mutable, qui ne provoque aucun ré-hachage et aucune création d'objets.

le truc qui est bien vu, c'est \b.

Chuis bien d'accord, mais bon

je tiens compte de tes remarques, je te remercie
C'est un exercice de decouverte de Java (notre 1er exercice en java). Donc c'est sur que le style doit pas etre tres tres jolie je m'en excuse.
Je vais  rendre tout ca, tout beau tout joli

Si tu fais ça sérieusement, je te file ma version complète (mais non testée, 'faut pas abuser) des choses.

Perso, après avoir lu les remarques de certains intervenants, j'ai envie de rammener ma fraise.
 
Alors...
 
En gros, y'a quelques années, un langage a été inventé, et son cahier des charge faisait a peut près 3 fois plus de pages que la norme ISO toute entière, soit le plus gros cahiers des charges jamais réalisé à ce jour. Il avait pour objectif premier d'être infaillible, et permettre, à tout instant dans le source, de savoir exactement ce qu'on faisait.
 
Une des solutions apportées pour répondre à cette condition fut le choix d'un langage "très fortement typé". C'est à dire que même si on crééait un type à dérivé partir d'un type standard, il était absolument impossible de faire des oppérations combinant ces deux types, sans au préalable faire un cast ou une surcharge des oppérateurs.
Grace à ça, plus d'autres points importants, à partir du moment où un programme compile, on est sûr à 100% qu'il est implantable.
 
Ce langage, c'est ADA. (pas la version 95, la version première du nom, la 95 a apporté un fort lot d'instabilité, et du coup un programme qui compile peut planter). C'est ce langage qui fait voler Ariane, qui a permis de mettre au point les modèles physique du TGV, ou simplement qui guide un missile nucléaire, l'armé américaine étant le rédacteur du cahier des charges.
 
J'ai appris à développer sur ce langage, et je reste persuadé que ses parties les plus chiantes sont les parties les plus importantes d'un programme. Ainsi, je dénonce les transtypages implicites, et je vote pour les transtypages explicites.
 
Ainsi, quelque soit le type d'objet qu'on utilise, et quelque soit s méthode par défaut, si on veut le mélanger avec une variable de type String, il est pour moins impératif de mettre un ".toString()", ou appel à toute autre méthode qui retourne une chaîne, quand bien même ce serait la méthode par défaut.
 
Comme dit Masklinn, depuis Java1.5, les hashmaps sont des "generics".
Pour moi, c'est porteur de plusieurs sens :
-> Si on compile et fait tourner avec une VM < 1.5, on n'aura pas le même comportement "par défaut" du code.
-> Rien ne nous assure que la prochaine version de Java utilisera toujours des Hashmaps "generics"
-> Si "generic" correspond à ce qu'on appel "object" dans les langages Microsoft (.NET, VB, etc.), alors j'en déduit qu'on peut faire cohabiter dans un même hashmaps deux valeurs de type différents. Ainsi, si une valeur numérique se glisse dedans et qu'on attends un String sans faire de vérification ni cast, alors on ne peut en aucun cas garantir le comportement du programme.
 
En bref, user et abuser des cast (ou appel à des méthodes de cast), ça ne nuit pas plus que ça à la lisibilité, et au contraire, ça facilite le débug puisqu'on est sûr et certains des types utilisés. Deplus, un compilo correct fera abstraction de tous les casts inutiles à la compilation, donc ça ne nuit en rien aux performances.
 
Voilà voilà

Sauf que si tu lisais le code, il utilise .toString sur des objets qui sont déjà des strings  

Ca c'est sûr, je pense qu'on aura un code qui compile pas

Hum... lol...
 
C'est vrai qu'ils vont sûrement retirer une fitioure dont la non-utilisation produit actuellement des warnings et qu'ils viennent d'ajouter dans le langage  

Justement non
 
Fais moi plaisir:

• Va te renseigner sur ce que sont les generics en Java (2e lien quand tu google "Java generics" pour une explication simple, ça devrait être faisable non?)
• Ou vas au moins comparer la déclaration d'une HashMap entre Java 1.4 et Java 1.5

merci Arjuna pour cette très belle sortie de piste, on dirait du Senna, et c'est pas peu dire.

Arjuna > je te propose de revenir quand tu sauras exactement à quoi correspond T extends Pouet dans les generics en java.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ça devrait nous laisser peinard pour un moment

je lis ou pas ?

t'as qu'à pas lire

Oui, pour une fois que c'est pas moi que tu vas insulter sur du java je suis intéressé

ok, donc, 18 lignes pour dire que c'est bien de mettre toString(), alors que tout le monde serait d'accord là dessus, c'est juste qu'on a rien dit parce que Masklinn, on laisse pisser.
 
et 10 lignes de vent pour nous montrer qu'il ne sait pas ce qu'on entend par "generics", en java.
 
 
Ben finalement, il était vachement interessant, ton machin pour afficher les infos d'un serveur sur le bureau.

Hmmmm, ok pour le coup du Generic...
 
Seulement, j'ai beau relire les bouts de code ci-dessus, je ne vois pas un appel à cette fonctionnalité de Java...
Et là, les collections utilisées sont bel et bien multi-types, d'où l'incapacité d'être sûr à tout moment qu'elles ne contiennent que des String...
 
Chuis pas si ç l'ouest que ça finalement...

Masklinn suggérait à notre ami d'utiliser les generics pour justement mieux typer ses collections et éviter de caster à tout va
il pourrait faire
Map<String, Integer> maMap = new HashMap<String, Integer>() quoi.

Faut savoir qu'il lui suggère d'utiliser les generics... Moi j'interprète pas ça comme ça.
 
M'enfin bon, je retourne dans la cat SGBD, au moins les gens allument pas le premier qui dit une connerie, et si y'a un expert incompris, c'est moi, donc j'ai pas de mal à le comprendre

merci.

je reviens au sujet.
J'ai refait l'exercice, et ca me donne le code suivant (j'ai edité mes autres messages en effacant les autres codes, de plus je precise que c'est pour analyser un texte en anglais, donc pas d accent).
Par contre je suis bloqué a la derniere question du sujet.
 
4. On désire trier l'index précédent en fonction des occurrences (les plus fréquentes en tête).
a. Donner les stratégies possibles pour constituer une liste triée sur les occurrences.
b. Appliquer cette strategie au code precedent.
c. Ajouter au programme la sortie des mots triés sur leur occurrence inverse.
 
Si vous pouviez m'aider merci
 

 
edit : la partie pour gerer la Map a eté corrigée par mon prof d'info ce matin.

Mais pourquoi tu stockes tes comptages sous la forme de strings nom de dieu
 
Quel intérêt ça a, à part rajouter des opérations inutiles
 
Et je t'ais déjà dit que tes dico.remove ne servent à rien, un put sur une clé déjà existante met la valeur de celle ci à jour
 
Et accessoirement, utilise donc l'objet mutable de nraynaud, ça diminue encore le nombre d'opérations nécessaires, donc ça clarifie le code.

une chose à la fois.

bah c'est le code de mon prof grand gourou, donc je le prends comme un code bon, bien fait.
Mais je lui ferais la remarque juste histoire de voir ca reaction

Une autre question, aussi:
 
Pourquoi ne pas faire ton toLowerCase() et ton filtrage de caractère directement sur la ligne complète (avant de la splitter)?
 
Ca génèrerait beaucoup moins d'objets.