vu que tout le monde se moque de ma montagne de ifs ;D (ce que je vais dire n'a aucun rapport d'ailleur... :P) peut-on utiliser un switch pour des variables < ou > ? Je m'explique : le switch marche pour une valeur par ex : case(78) donne les actions souhaitées si l'age vaut 78 mais comment doit-on écrire le switch si l'on souhaite que l'action se fasse pour un age <= à 78 ?
Meme question avec && et || ; peut -on les utiliser dans un switch ?
Je ne pense pas qu'il y'ai ce genre d'instruction, mais tu peux gérer un case else et si besoin mettre un if dedans. lol Je tiens a te remercier car je crois que c'est la première fois que je fais rire le grand Ali.
Je ne pense pas qu'il y'ai ce genre d'instruction, mais tu peux gérer un case else et si besoin mettre un if dedans. lol Je tiens a te remercier car je crois que c'est la première fois que je fais rire le grand Ali.
c'est une première alors ;D
je prefere continuer avec mon enchainement de if pour le moment alors ,quand je maitraiserai mieux le language jreviendrai dessus pour l'améliorer parque 300 lignes de codes pour faire ce que j'ai fait ça n'est pas des plus rentable :P
meme si passer de 300 a 250 n'a pas vraiment d'importance mais je preferai aprrendre a bien structurer un code source avant de m'attaquer a du plus lourd...
(desole pour les accents mais l'ordinateur sur lequel je suis a un clavier mi-qwerty mi-azerty )
Peut-être qu'en nous joignant le code quelqu'un pourra te dire si la structure respecte le MVC et t'indiquer une approche plus propre ou plus simple etc. ?
C'est pas de ta montagne de ifs dont je me moquais, c'est le jeu de mots "ça sent le sapin les ifs" qui me faisait rire (d'autant que tout le monde ne sait pas ce qu'est un If au sens botanique du terme, encore moins les programmeurs pour qui ça veut plutôt dire autre chose :P)
Sinon pour le switch il n'y a pas de possibilité de faire des comparaison type < ou > : ça ne marche qu'en testant l'égalité "==". Par contre tu peux mettre plusieurs "case" qui vont exécuter le même bloc, ça fait une sorte de "OU" du coup. Voire même (mais en général on évite car c'est plutôt tordu à comprendre) ne pas mettre de "break" dans certains case, pour que le code continue. Exemple tordu :
switch(age){<br /> case0:<br /> case1:<br /> NSLog(@"0 ou 1 an");// (A)<br /> break;<br /> case 2:<br /> case 3:<br /> case 4:<br /> case 5:<br /> case 6:<br /> NSLog(@"Je n'ai pas encore l'age de raison."); // (B)<br /> default:<br /> NSLog(@"J'ai %d ans",age); // (C)<br />}<br />NSLog(@"Fin"); // (D)
Dans cet exemple : - si age vaut 0 ou 1, alors le NSLog noté (A) sera exécuté, et ensuite le break fera sortir du switch, donc c'est la ligne (D) qui sera exécutée après. - si l'age vaut 2,3,4,5 ou 6, le NSLog noté (B) sera exécuté... mais comme il n'y a pas de "break" après, le NSLog noté (C) sera aussi exécuté ensuite (et enfin le (D) bien sûr). - si l'age vaut autre chose que 0,1,2,3,4,5,6, ça va directement aller au tag "default" et donc n'afficher que le NSLog (C) (puis le (D) bien sûr).
En fait quand tu rentres dans un switch, ça va tout de suite au "case" qui correspond à la valeur testée par le switch, et ensuite ça exécute toutes les lignes de code qui suivent... jusqu'à la fin du switch... ou jusqu'à rencontrer un "break" (et dans ces cas là ça saute à la fin du switch pour continuer le reste du code). C'est rien de plus que ça un switch. Pas de break = le code qui suit continue à s'exécuter. De là découle que plusieurs "case" à la suite correspondent à l'exécution d'un même code, ce n'est qu'une conséquence.
Mais ce genre de construction où l'on oublie volontairement les break ou autre est vite difficile à comprendre, à réserver pour des cas isolés.
Si tu veux faire des comparaisons < ou >, il faut faire des "if". Et si tu en as beaucoup, il faut peut-être réfléchir à une construction automatique (genre un tableau qui liste tous tes intervalles, et les objets ou fonctions à exécuter en fonction de ces intervalles, et ensuite une boucle "for" qui parcoure ce tableau d'intervalles, enfin un mécanisme généralisant du genre. Mais bon, quand y'a vraiment pas le choix et que les codes sont vraiment tous bien différents et distincts et pas mutualisables selon les valeurs à tester, et qu'il faut faire des tests < ou >, une grosse suite de "if... else if .... else if.... else..." se voit aussi. Juste que 300 lignes pour ça me parait beaucoup :P Faudrait voir pourquoi tu as besoin de faire ça et à quoi ressemble ton code pour comprendre pourquoi et si tu as besoin d'autant de ligne pour ça
C'est pas de ta montagne de ifs dont je me moquais, c'est le jeu de mots "ça sent le sapin pour les ifs" qui me faisait rire (d'autant que tout le monde ne sait pas ce qu'est un If au sens botanique du terme, encore moins les programmeurs pour qui ça veut plutôt dire autre chose :P)
C'est bien pour ça que je le remercie, il m'a tendu une jolie perche et que ça te fasse rire me fait d'autant plus plaisir. a sa santé.
Sinon pour le switch il n'y a pas de possibilité de faire des comparaison type < ou > : ça ne marche qu'en testant l'égalité "==". Par contre tu peux mettre plusieurs "case" qui vont exécuter le même bloc, ça fait une sorte de "OU" du coup. Voire même (mais en général on évite car c'est plutôt tordu à comprendre) ne pas mettre de "break" dans certains case, pour que le code continue.
je confirme c'est particulierement tordu , mieux vaut mettre une condition < ou > parsque ça rallonge le code plus qu'autre chose.
dans 1269264112:
En fait quand tu rentres dans un switch, ça va tout de suite au "case" qui correspond à la valeur testée par le switch, et ensuite ça exécute toutes les lignes de code qui suivent... jusqu'à la fin du switch... ou jusqu'à rencontrer un "break" (et dans ces cas là ça saute à la fin du switch pour continuer le reste du code). C'est rien de plus que ça un switch.
c'est grave quand même de comprendre que maintenant en détail un switch , parsque je suivais bètement un ex de code et même si ça paraissait logique je me trompé sur ou mettre le break etc...maintenant c'est trés clair :P et par la même occasion je vais en profiter pour apprendre la démarche d'un délégate , histoire de ne pas retomber sur une forêt de ifs
Peut-être qu'en nous joignant le code quelqu'un pourra te dire si la structure respecte le MVC et t'indiquer une approche plus propre ou plus simple etc. ?
en effet je peut vous le passer mais c'est assez le "foutoir" vu qu'il y a les ifs
il ya 3 choix d'opération (addition , soustraction et multiplication) dans chaque cas 4 sous cas (facile , normal , difficile et hardcore)
ce qui fait 12 ifs (je pense que le s est approprié )
et ce scénario est répété 3 fois...(oui je sais c'est de la flagellation a ce stade là ... ) une fois lorsque l'on clique sur le choix de l'opération , une fois lorsque l'on choisi le niveau de difficulté et une troisième fois lorsque l'on clique sur le button "correction".
je sais que je pouvais tout mettre dans la méthode en cliquant sur le bouton mais je voulais que les chiffres soient regénérés à chaque action...
bref ça fait un beau .m....
je le met en fichier joint parsque si je le colle ici on ne s'y retrouve plus
Je viens de jeter un petit coup d'oeil au .m et je dirais que tu as l'habitude de la programmation séquentiel mais pas de la programmation objet. Si ce code est pour toi une base d'apprentissage, je t'encourage a créer un clone et a imaginer une solution + objet de ce projet. Moi j'ai la Deuxième édition d'Hillegaas, je crois que tu as ce livre aussi (peut-être la 3ème édition ?) Il y'a un passage ou il parle du compte bancaire, c'est pour moi une source pour remettre en question l'approche...
Je viens de jeter un petit coup d'oeil au .m et je dirais que tu as l'habitude de la programmation séquentiel mais pas de la programmation objet.
je confirme la prog objet est totalement inconnue pour moi,concernant la programmation séquentielle j'ai commencé le C il y a environ deux mois donc je confirme j'ai essayer de me baser sur ce que je pense maà®triser.
dans 1269280533:
Si ce code est pour toi une base d'apprentissage, je t'encourage a créer un clone et a imaginer une solution + objet de ce projet. Moi j'ai la Deuxième édition d'Hillegaas, je crois que tu as ce livre aussi (peut-être la 3ème édition ?) Il y'a un passage ou il parle du compte bancaire, c'est pour moi une source pour remettre en question l'approche...
en effet j'ai la 3eme édition et pendant pas mal de chapitres il se concentre sur une application "raiseman" qui correspond à la gestion des augmentations d'une entreprise.petit à petit il incorpore des notions (rajout d'un tableau , panneaux d'alerte etc...) je l'ai feuilleté en diagonale car je ne comprenais pas les methodes utilisés lors des 1ers chapitres.Mais je pense y jeter un coup d'oeil(voire suivre pas a pas la création du programme :P) car je peux comprendre maintenant les chapitres d'introduction.
Je vois qu'à chaque fois tu as toujours des random()%xx+yy, pourquoi ne pas déterminer xx et yy en fonction de l'opération et de la difficulté, et une fois ça fait, alors faire le random()%xx+yy ? Quitte à utiliser un tableau C pour ça.
NSString* ops[]={@"...",@"",@"+",@"-",@"x"};<br /><br />if(choixopp == OP_PLUS){<br /> staticconstint modulosPlus[]={20,10,20,10,20,20,30,200};<br /> staticconstint deltaPlus[]={1,1,31,11,81,31,101,41};<br /><br /> [addop setStringValue:(ops[choixopp])];// par exemple ops[2] vaut @"+"<br /><br /> int moduloA = modulosPlus[choixdifficulte*2]; // indexs 0, 2, 4, ...<br /> int moduloB = modulosPlus[choixdifficulte*2+1]; // indexs 1, 3, 5, ...<br /> int deltaA = deltaPlus[choixdifficulte*2];<br /> int deltaB = deltaPlus[choixdifficulte*2+1];<br /><br /> a = random() % moduloA + deltaA;<br /> b = random() % moduloB + deltaB;<br /><br /> c = a+b;<br /><br /> difficultea = MIN( (a-1)/20 + 1 , 5 ); // division entière par 20 "> résultat entier "> revient au même que tous tes ifs !<br /> difficulteb = MIN( (a-1)/10 + 1 , 5 ); // par exemple pour a=10, (10-1)/10 = 9/10 = 0 en division entière !<br /> // encore plein de ifs d'éliminés !<br /><br /> ...<br />}<br />...
Déjà rien que comme ça j'ai réduit ton code drastiquement en généralisant pour toutes les difficultés le calcul de a, de b, de difficultea et difficulteb, ainsi de ce que le texte que tu affiches dans addop...
Et là , miracle, non seulement y'a plus un seul "if" dans le code, mais tu vois en plus que c'est déjà presque généralisé aux autres opérations de soustraction et multiplication, puisque le code sera pareil pour les autres cas... il n'y a que le tableau des modulos et des deltas à adapter !
Donc tu n'as plus qu'à étendre le système que j'ai montré là pour le généraliser pour toutes les opérations. Par exemple tu peux faire un tableau géant modulos[] = { ... } où les 8 premières valeurs sont les valeurs pour le plus (en alternant celles pour a et celles pour b, avec difficulté croissante de 0 à 3, comme j'ai fait plus haut), et les 8 valeurs suivantes sont les valeurs pour le moins, etc...
Et t'as plus qu'à calculer le delta pour savoir quelle valeur prendre : au lieu de te contenter de (difficulte*2) et (difficulte*2+1), tu peux partir sur un truc genre (difficulte*2+debut) et (difficulte*2+debut+1), où debut vaut 0 pour "+", 8 pour "-", ... autrement dit choixopp*8 ou presque (bon en fait ton OP_PLUS démarrant à 2 dans ton cas, c'est plutôt debut=(choixopp-2)*8 pour coller... ou alors tu changes les valeurs associées à tes enums pour que OP_PLUS corresponde à 0, OP_MOINS à 1, etc... et tu utilises autre chose pour ta valeur spéciale 0 que tu as associée à "démarrer" mais j'ai pas trop capté pour quoi tu te sers de ça dans ton app donc bon à toi d'adapter)
Comme quoi, finalement dans ce code je n'ai plus un seul "if" ni un seul switch ! Bon, ok, c'est pas aussi rose, il t'en faudra bien un pour faire, selon l'opération choisie, soit un "c=a+b", soit "c=a-b", soit "c=a*b"... (et encore que là si on voulais, on pourrait aussi s'en passer via un tableau de pointeurs de fonctions, mais bon, on va p'tet pas pousser le bouchon jusque-là )
Note que tout ça est du C pur. Aucune ligne d'Objective-C dans tout ça (à part pour le setStringValue mais bon). J'ai tout fait avec des tableaux C, parce que c'est plus simple dans ce cas : - les tableaux sont statiques et constants - pour un tableau de nombres, c'est plus simple que de créer des NSArray car il faudrait encapsuler chaque nombre dans un objet NSNumber, un peu lourd alors que pas utile dans notre cas.
Ici, tu déclares des variables globales, bon c'est pas très grave, elles ne sont pas connues en dehors de la classe, mais il y a aucune raisons de ne pas les mettre avec les autres dans le .h. Et puis elles seront toutes initialisées à 0 par défaut
Pour ton problème de if/case multiple, je pense qu'il faut que tu définisses des constantes sous forme de tableaux en C: Par ex pour:
if(a <=20)<br />{difficultea =1;}<br /><br />if(a <=40&& a >=21)<br />{difficultea =2;}<br /><br />if(a <=60&& a >=41)<br />{difficultea =3;}<br /><br />if(a <=80&& a >=61)<br />{difficultea =4;}<br /><br />if(a >=81)<br />{difficultea =5;}
ici, tu peux faire: difficultea=a%20+1;
pour:
<br/> if(choixdifficulte == 0)<br/> {<br/> a = random()%10+11;<br/> b = random()%10+1;<br/> }<br/><br/> if(choixdifficulte == 1)<br/> {<br/> a = random()%20+31;<br/> b = random()%10+11;<br/> }<br/><br/> if (choixdifficulte == 2)<br/> {<br/> a = random()%20+81;<br/> b = random()%20+31;<br/><br/> }<br/> if(choixdifficulte == 3)<br/> {<br/> a = random()%30+101;<br/> b = random()%20+41;<br/> }<br/>
déclarer un tableau static au début du fichier .m:
static int Difficulte[][4]={{10,11,10,1},{20,31,10,11},...};
et faire: a=random()%Difficulte[[choixdifficulte][0]+Difficulte[[choixdifficulte][1]; b=random()%Difficulte[[choixdifficulte][2]+Difficulte[[choixdifficulte][3];
Bon j'ai édité mon code pour mettre d'autres détails, et mpergand a publié entre temps finalement. Mais bon tu vois qu'on a les mêmes idées au final ! Tu t'es en effet bien compliqué la vie avec tes "ifs" là où tu as clairement moyen de factoriser un maximum.
Tu pourrais sinon effectivement revoir l'approche d'un point de vue Objet et non pas pur C. Bon pour le cas qui nous intéresse, je suis pas persuadé que ça t'apporterai énormément, mais ça peut être un exercice éventuel (même si je suis pas sûr que ce soit l'exemple le plus pertinent ^^)
Pour info je m'estime débutant aussi et quand je vois la réponse d'Ali, je me dis y'a du boulot ! Merci Ali, ce genre de démonstration est inestimable pour qui souhaite progresser. Quand je vois certains reflexe que tu sembles avoir par exemple:
<br/> NSString* ops[] = {@"...",@"",@"+",@"-",@"x"};<br/> [addop setStringValue: (ops[choixopp]) ]; // par exemple ops[2] vaut @"+"
Une fois qu'on les découvrent cela semble évident pourtant...
Tu pourrais sinon effectivement revoir l'approche d'un point de vue Objet et non pas pur C. Bon pour le cas qui nous intéresse, je suis pas persuadé que ça t'apporterai énormément, mais ça peut être un exercice éventuel (même si je suis pas sûr que ce soit l'exemple le plus pertinent ^^)
en effet c'est pas forcement plus pertinent mais au moins ça me fera un exercice et je pourrai m'attaquer a un prog un peu plus "hardu"
@ mpergand & @ AliGator :
merci pour vos simplifications,je m'y mettrai en fin de semaine lorsque j'aurai un peu moins de travail scolaire parsque même si je code entre midi et 2 et le soir des que je rentre j'essaye de me donner bonne conscience
je vais tout reprendre et faire un tableau en C,factoriser etc etc... histoire de faire plus clair et moins "mon premier programme"
je vous tiens au courant en fin de semaine ou avant si je peux
Pour info je m'estime débutant aussi et quand je vois la réponse d'Ali, je me dis y'a du boulot ! Merci Ali, ce genre de démonstration est inestimable pour qui souhaite progresser.
en effet je suis tout à fait d'accord et je t'en remercie Ali , on dirai pas mais en un peu plus d'une semaine j'ai réussi à faire un bon ptit programme qui je trouve est fonctionel et assez marrant :P et c'est en grande partie grâce à la patience des menbres de ce forums qui répondent clairement à mes questions de débutants.
concernant la pratique et le codage en lui-même ya tout à revoir mas ça ne me fait pas peur , j'ai tout mon week-end
En VB6, j'avais trouvé un document genre tips & tricks qui m'avait bien dégrossit, je crois bien que je vais finir par regrouper les infos que je trouve ici et ailleurs de la même façon parce que y'a de quoi faire ! Objc-C et cocoa, c'est passionnant mais ça demande une bonne vue d'ensemble, parcontre beaucoup d'appels de méthode sont finalement simple.
En VB6, j'avais trouvé un document genre tips & tricks qui m'avait bien dégrossit, je crois bien que je vais finir par regrouper les infos que je trouve ici et ailleurs de la même façon parce que y'a de quoi faire ! Objc-C et cocoa, c'est passionnant mais ça demande une bonne vue d'ensemble, parcontre beaucoup d'appels de méthode sont finalement simple.
VB6 ??
c'est vrai que ce n'est as bien compliqué pour les choses de bases mais il faut les avoir vu une fois déja,je trouve que gerer les buttons, textField et levelIndicator sont un jeu d'enfant maintenant mais j'ai quand même eu besoin de vous et la doc apple est bien gentille mais pour l'utilisation d'un NSTimer (par exemple...) elle fait appel a plein de notion que je ne connais pas donc au final ce n'est pas trés enrichissant...Et je suis sur qu'une fois que j'aurai trouvé comment il faut faire je me demanderai comment j'ai fait pour ne pas avoir compris :P
<br/>// Dans le .h tu déclares ton timer:<br/> NSTimer *timer;<br/>// et les méthodes ...<br/><br/>// Dans le .m<br/><br/>- (void)stopGo // méthode pour créer démarrer et arrêter le timer<br/>{<br/> if (timer == nil) {<br/> NSLog(@"Pas de timer, on le crée et on le démarre.");<br/><br/> timer = [[NSTimer scheduledTimerWithTimeInterval:0.007<br/> target:self<br/> selector:@selector(timerAction:) //la méthode appeler a chaque intervalle<br/> userInfo:nil<br/> repeats:YES] retain];<br/> } else {<br/> NSLog(@"Mon timer existe déja je l'arrête et je le release");<br/><br/> [timer invalidate];<br/> [timer release];<br/> timer = nil;<br/> }<br/>}<br/><br/>// La méthode appeler par le timer<br/>- (void)timerAction:(NSTimer *)aTimer<br/>{<br/>//ici le code appelé, tu mets ici ce que tu veux exécuter a chaque intervale<br/> [self setAlphaValue:(count/100)];<br/><br/> /*if (count == MAX_COUNT) {<br/> [self resetCount];<br/> [self stopGo];<br/> [self close];<br/> } else {*/<br/> [self incrementCount];<br/> <br/>}
"if (!timer)" est équivalent à "if (timer == nil)"...
Et de toute façon, ce test est inutile, car il est tout à fait valide d'envoyer un message à un objet "nil". Le runtime Objective-C s'en rendra compte et ignorera les appels, sans faire planter l'application.
Réponses
en gros noob que je suis j'ai des enchainements de if couplé à des && et || ! et je suis agréablement surpris que le prog soit opérationel
jme disais bien qu'il y avais une méthode pour parer ces if mais je m'étais pas encore penché dessus. :P
:P et oui mon prog ressemble un peu à ça ;D
sinOn ce paysage correspond a quoi en fait??c'est une foret artificielle?
Vu comment certains ifs sont taillés, je doute que ce soit la nature qui s'en soit chargée.
vu que tout le monde se moque de ma montagne de ifs ;D (ce que je vais dire n'a aucun rapport d'ailleur... :P) peut-on utiliser un switch pour des variables < ou > ? Je m'explique : le switch marche pour une valeur par ex : case(78) donne les actions souhaitées si l'age vaut 78 mais comment doit-on écrire le switch si l'on souhaite que l'action se fasse pour un age <= à 78 ?
Meme question avec && et || ; peut -on les utiliser dans un switch ?
Je tiens a te remercier car je crois que c'est la première fois que je fais rire le grand Ali.
c'est une première alors ;D
je prefere continuer avec mon enchainement de if pour le moment alors ,quand je maitraiserai mieux le language jreviendrai dessus pour l'améliorer parque 300 lignes de codes pour faire ce que j'ai fait ça n'est pas des plus rentable :P
meme si passer de 300 a 250 n'a pas vraiment d'importance mais je preferai aprrendre a bien structurer un code source avant de m'attaquer a du plus lourd...
(desole pour les accents mais l'ordinateur sur lequel je suis a un clavier mi-qwerty mi-azerty )
Sinon pour le switch il n'y a pas de possibilité de faire des comparaison type < ou > : ça ne marche qu'en testant l'égalité "==".
Par contre tu peux mettre plusieurs "case" qui vont exécuter le même bloc, ça fait une sorte de "OU" du coup. Voire même (mais en général on évite car c'est plutôt tordu à comprendre) ne pas mettre de "break" dans certains case, pour que le code continue. Exemple tordu : Dans cet exemple :
- si age vaut 0 ou 1, alors le NSLog noté (A) sera exécuté, et ensuite le break fera sortir du switch, donc c'est la ligne (D) qui sera exécutée après.
- si l'age vaut 2,3,4,5 ou 6, le NSLog noté (B) sera exécuté... mais comme il n'y a pas de "break" après, le NSLog noté (C) sera aussi exécuté ensuite (et enfin le (D) bien sûr).
- si l'age vaut autre chose que 0,1,2,3,4,5,6, ça va directement aller au tag "default" et donc n'afficher que le NSLog (C) (puis le (D) bien sûr).
En fait quand tu rentres dans un switch, ça va tout de suite au "case" qui correspond à la valeur testée par le switch, et ensuite ça exécute toutes les lignes de code qui suivent... jusqu'à la fin du switch... ou jusqu'à rencontrer un "break" (et dans ces cas là ça saute à la fin du switch pour continuer le reste du code). C'est rien de plus que ça un switch.
Pas de break = le code qui suit continue à s'exécuter. De là découle que plusieurs "case" à la suite correspondent à l'exécution d'un même code, ce n'est qu'une conséquence.
Mais ce genre de construction où l'on oublie volontairement les break ou autre est vite difficile à comprendre, à réserver pour des cas isolés.
Si tu veux faire des comparaisons < ou >, il faut faire des "if". Et si tu en as beaucoup, il faut peut-être réfléchir à une construction automatique (genre un tableau qui liste tous tes intervalles, et les objets ou fonctions à exécuter en fonction de ces intervalles, et ensuite une boucle "for" qui parcoure ce tableau d'intervalles, enfin un mécanisme généralisant du genre. Mais bon, quand y'a vraiment pas le choix et que les codes sont vraiment tous bien différents et distincts et pas mutualisables selon les valeurs à tester, et qu'il faut faire des tests < ou >, une grosse suite de "if... else if .... else if.... else..." se voit aussi.
Juste que 300 lignes pour ça me parait beaucoup :P Faudrait voir pourquoi tu as besoin de faire ça et à quoi ressemble ton code pour comprendre pourquoi et si tu as besoin d'autant de ligne pour ça
C'est bien pour ça que je le remercie, il m'a tendu une jolie perche et que ça te fasse rire me fait d'autant plus plaisir.
je confirme c'est particulierement tordu , mieux vaut mettre une condition < ou > parsque ça rallonge le code plus qu'autre chose.
c'est grave quand même de comprendre que maintenant en détail un switch , parsque je suivais bètement un ex de code et même si ça paraissait logique je me trompé sur ou mettre le break etc...maintenant c'est trés clair :P et par la même occasion je vais en profiter pour apprendre la démarche d'un délégate , histoire de ne pas retomber sur une forêt de ifs
tournée générale de Mdr alors
en effet je peut vous le passer mais c'est assez le "foutoir" vu qu'il y a les ifs
il ya 3 choix d'opération (addition , soustraction et multiplication) dans chaque cas 4 sous cas (facile , normal , difficile et hardcore)
ce qui fait 12 ifs (je pense que le s est approprié
et ce scénario est répété 3 fois...(oui je sais c'est de la flagellation a ce stade là ...
je sais que je pouvais tout mettre dans la méthode en cliquant sur le bouton mais je voulais que les chiffres soient regénérés à chaque action...
bref ça fait un beau .m....
je le met en fichier joint parsque si je le colle ici on ne s'y retrouve plus
Moi j'ai la Deuxième édition d'Hillegaas, je crois que tu as ce livre aussi (peut-être la 3ème édition ?) Il y'a un passage ou il parle du compte bancaire, c'est pour moi une source pour remettre en question l'approche...
je confirme la prog objet est totalement inconnue pour moi,concernant la programmation séquentielle j'ai commencé le C il y a environ deux mois donc je confirme j'ai essayer de me baser sur ce que je pense maà®triser.
en effet j'ai la 3eme édition et pendant pas mal de chapitres il se concentre sur une application "raiseman" qui correspond à la gestion des augmentations d'une entreprise.petit à petit il incorpore des notions (rajout d'un tableau , panneaux d'alerte etc...) je l'ai feuilleté en diagonale car je ne comprenais pas les methodes utilisés lors des 1ers chapitres.Mais je pense y jeter un coup d'oeil(voire suivre pas a pas la création du programme :P) car je peux comprendre maintenant les chapitres d'introduction.
Factorise plus que ça le code, et utilise des variables !
Utilise aussi des enums pour rendre ton code plus clair !
Je vois qu'à chaque fois tu as toujours des random()%xx+yy, pourquoi ne pas déterminer xx et yy en fonction de l'opération et de la difficulté, et une fois ça fait, alors faire le random()%xx+yy ?
Quitte à utiliser un tableau C pour ça.
Déjà rien que comme ça j'ai réduit ton code drastiquement en généralisant pour toutes les difficultés le calcul de a, de b, de difficultea et difficulteb, ainsi de ce que le texte que tu affiches dans addop...
Et là , miracle, non seulement y'a plus un seul "if" dans le code, mais tu vois en plus que c'est déjà presque généralisé aux autres opérations de soustraction et multiplication, puisque le code sera pareil pour les autres cas... il n'y a que le tableau des modulos et des deltas à adapter !
Donc tu n'as plus qu'à étendre le système que j'ai montré là pour le généraliser pour toutes les opérations.
Par exemple tu peux faire un tableau géant modulos[] = { ... } où les 8 premières valeurs sont les valeurs pour le plus (en alternant celles pour a et celles pour b, avec difficulté croissante de 0 à 3, comme j'ai fait plus haut), et les 8 valeurs suivantes sont les valeurs pour le moins, etc...
Et t'as plus qu'à calculer le delta pour savoir quelle valeur prendre : au lieu de te contenter de (difficulte*2) et (difficulte*2+1), tu peux partir sur un truc genre (difficulte*2+debut) et (difficulte*2+debut+1), où debut vaut 0 pour "+", 8 pour "-", ... autrement dit choixopp*8 ou presque (bon en fait ton OP_PLUS démarrant à 2 dans ton cas, c'est plutôt debut=(choixopp-2)*8 pour coller... ou alors tu changes les valeurs associées à tes enums pour que OP_PLUS corresponde à 0, OP_MOINS à 1, etc... et tu utilises autre chose pour ta valeur spéciale 0 que tu as associée à "démarrer" mais j'ai pas trop capté pour quoi tu te sers de ça dans ton app donc bon à toi d'adapter)
Comme quoi, finalement dans ce code je n'ai plus un seul "if" ni un seul switch !
Bon, ok, c'est pas aussi rose, il t'en faudra bien un pour faire, selon l'opération choisie, soit un "c=a+b", soit "c=a-b", soit "c=a*b"...
(et encore que là si on voulais, on pourrait aussi s'en passer via un tableau de pointeurs de fonctions, mais bon, on va p'tet pas pousser le bouchon jusque-là )
Note que tout ça est du C pur. Aucune ligne d'Objective-C dans tout ça (à part pour le setStringValue mais bon). J'ai tout fait avec des tableaux C, parce que c'est plus simple dans ce cas :
- les tableaux sont statiques et constants
- pour un tableau de nombres, c'est plus simple que de créer des NSArray car il faudrait encapsuler chaque nombre dans un objet NSNumber, un peu lourd alors que pas utile dans notre cas.
Ici, tu déclares des variables globales, bon c'est pas très grave, elles ne sont pas connues en dehors de la classe, mais il y a aucune raisons de ne pas les mettre avec les autres dans le .h.
Et puis elles seront toutes initialisées à 0 par défaut
Pour ton problème de if/case multiple, je pense qu'il faut que tu définisses des constantes sous forme de tableaux en C:
Par ex pour:
ici, tu peux faire:
difficultea=a%20+1;
pour:
déclarer un tableau static au début du fichier .m:
#import "addition.h"
static int Difficulte[][4]={{10,11,10,1},{20,31,10,11},...};
et faire:
a=random()%Difficulte[[choixdifficulte][0]+Difficulte[[choixdifficulte][1];
b=random()%Difficulte[[choixdifficulte][2]+Difficulte[[choixdifficulte][3];
Y a moyen de faire plus lisible (voir au dessus
Mais bon tu vois qu'on a les mêmes idées au final !
Tu t'es en effet bien compliqué la vie avec tes "ifs" là où tu as clairement moyen de factoriser un maximum.
Tu pourrais sinon effectivement revoir l'approche d'un point de vue Objet et non pas pur C.
Bon pour le cas qui nous intéresse, je suis pas persuadé que ça t'apporterai énormément, mais ça peut être un exercice éventuel (même si je suis pas sûr que ce soit l'exemple le plus pertinent ^^)
Merci Ali, ce genre de démonstration est inestimable pour qui souhaite progresser.
Quand je vois certains reflexe que tu sembles avoir par exemple:
Une fois qu'on les découvrent cela semble évident pourtant...
en effet c'est pas forcement plus pertinent mais au moins ça me fera un exercice et je pourrai m'attaquer a un prog un peu plus "hardu"
@ mpergand & @ AliGator :
merci pour vos simplifications,je m'y mettrai en fin de semaine lorsque j'aurai un peu moins de travail scolaire
parsque même si je code entre midi et 2 et le soir des que je rentre j'essaye de me donner bonne conscience
je vais tout reprendre et faire un tableau en C,factoriser etc etc... histoire de faire plus clair et moins "mon premier programme"
je vous tiens au courant en fin de semaine ou avant si je peux
en effet je suis tout à fait d'accord et je t'en remercie Ali , on dirai pas mais en un peu plus d'une semaine j'ai réussi à faire un bon ptit programme qui je trouve est fonctionel et assez marrant :P et c'est en grande partie grâce à la patience des menbres de ce forums qui répondent clairement à mes questions de débutants.
concernant la pratique et le codage en lui-même ya tout à revoir
VB6 ??
c'est vrai que ce n'est as bien compliqué pour les choses de bases mais il faut les avoir vu une fois déja,je trouve que gerer les buttons, textField et levelIndicator sont un jeu d'enfant maintenant mais j'ai quand même eu besoin de vous et la doc apple est bien gentille mais pour l'utilisation d'un NSTimer (par exemple...) elle fait appel a plein de notion que je ne connais pas donc au final ce n'est pas trés enrichissant...Et je suis sur qu'une fois que j'aurai trouvé comment il faut faire je me demanderai comment j'ai fait pour ne pas avoir compris :P
Voilà , bonne continuation
juste une question : la condition dans le if (!timer) me perture
"if (!timer)" est équivalent à "if (timer == nil)"...
Et de toute façon, ce test est inutile, car il est tout à fait valide d'envoyer un message à un objet "nil". Le runtime Objective-C s'en rendra compte et ignorera les appels, sans faire planter l'application.