Version imprimable
Bonjour,
J'ai une question par rapport aux boucles while.
Quand je dois faire une boucle sur une autre, comment je sais avec certitude que la boucle principale est bien à sa place, que ce n'est pas l'autre boucle (dans le corps de la 1ere) qui englobe ?
Car ce genre d'opérations m'embrouille rapidement l'esprit, à tel point que ma question peut paraitre mal exprimée.
Merci d'avance pour vos éclaircissements.
Salut,
Tu parles de boucles imbriquées, c'est ça ?
On peut utiliser les blocs avec de l'indentation pour éviter de s'embrouiller.
Par exemple :
Code:
2
3
4
5
6
7
8
9
10
11
12
merçi pour ta réponse joel,
oui c'est ça, je cherchais le mot exact, pour l'indentation ça je pense que je peux plus ou moins me debrouiller, mais, quand tu sais par exemple que dans un exo tu dois faire disons pour l'exemple 1 boucle imbrique, 2 while au total, quel raisonnement faut avoir pour ne pas mettre une instruction dans le mauvais??Code:while
et donc de denaturer le code??
Là, çà dépend vraiment de l'algo, mais je ne pense pas qu'il y ait de recette toute faite : juste savoir ce qu'on fait, de la rigueur, et un peu de jugeote.
Ensuite, si on a vraiment pleins de boucles imbriquées et qu'on a peur de se perdre dans toutes les boucles, un bon nommage de variables, des méthodes intermédiaires et des commentaires (par exemple sur l'accolade de fin de boucle) bien placés peuvent aider à s'y retrouver (sans parler des outils que proposent les IDE, comme le folding par exemple). Et puis, faire des classes aussi, qui isolent les traitements.
Tiens, je vais te citer un exemple qui m'est arrivé pas plus tard que ce matin : j'avais besoin d'implémenter un petit cache pour traiter des mises à jours d'une UI (TreeView) à partir d'évènements provenant d'un serveur (notification). Au début, j'ai mis en place une Map<K,V>, puis j'ai eu besoin d'une seconde Map<V, List<V>>, puis d'une troisième Map<K,List<V>> pour traiter des cas particuliers : quand j'avais qu'une map à traiter, je la traitais directement dans mes méthodes d'écouteurs (les implémentations de l'interface), puis quand j'ai introduis la seconde map, et que j'ai commencé à devoir faire des traitements sur les deux, avec des ifs et des boucles, j'ai fait des méthodes dans ma classes de listener, pour y voir plus clair, avec des noms qui avaient un sens plus précis (plus métier) qu'un nom technique d'interface de listener, puis quand j'ai introduis la troisième, j'ai fait une classe intermédiaire, me masquant la complexité de l'accès aux maps depuis le listener, mais ayant pleins de petites méthodes simples pour gérer chaque cas technique de traitement, que je pouvais combiner, pour faire des traitements plus complexes de ces map. Du coup, ce qui aurait pu être complexe à élaborer en une seule méthode, l'était moins, donc moins de risque d'erreur et moins de question à se poser pour savoir où mettre tel ou tel traitement.
Donc si je comprends bien et ça parait logique c'est que s'attaquer à un problème plus ou moins complexe, le fait de fractionner le tout en plus petits problèmes à l'avantage d'éclaircir et de simplifier ce que l'on fait ?
Et la POO aide énormément ?
Si si la modularité qu'elle apporte est très favorable pour les projets de grandes envergures