Il s'agirait de revenir à quelques fondamentaux en programmation pour saisir tes deux fautes....
Alors, puisque je suis de bonne humeur (oui ça arrive!), voilà les raisonnements à tenir.
1° C'est quoi une méthode
Schématiquement: une méthode est un bout de code qu'on appelle pour faire un ou plusieurs traitements de manière facile à rappeler sans dupliquer le code partout.
Concrètement:
- Une méthode peut ou non recevoir des paramètres
- Une méthode peut ou non retourner des réponses sous un format donné
Les appels
Appeler une méthode, c'est dire au programme "quand tu tombes sur moi tu dois aller exécuter le bout de code qui est derrière ce nom"
Créons une méthode "Manger".
C++:
void manger() {
// mon code ici
}
manger()
- La déclaration "void" veut dire qu'elle ne retourne rien
-
manger() est l'appel à la méthode
- manger ne prend aucun paramètre, et ne retourne rien
On peut avoir ce type de méthode pour un truc non-interactif. Par exemple, on peut imaginer une méthode sortir() qui quitte le programme. Elle aura comme look
C++:
void sortie() {
ExecuterQuitter
}
sortir()
Maintenant, on veut passer des paramètres à la méthode.
On veut par exemple dire
'Manger prend deux paramètres: le nom du menu et le montant du menu"
Cela va donner
C++:
void manger(char menu, double montant) {
// mon code ici
}
manger("nom Menu", 34.5)
Manger() reçoit donc
"Mon menu"
34.5
Etape finale: on veut que la méthode retourne quelque-chose d'utile.
Par exemple "manger" qui a fini retournera un texte "J'ai fini!"
C++:
string manger(char menu, double montant) {
// mon code ici
char s = "J'ai fini!";
return s;
}
char t = manger("nom Menu", 34.5)
t recevra "J'ai fini!" une fois tout le code exécuté.
Les mots-clés essentiels
string manger(... : je déclare que la méthode retourne de la chaine
return s : la réponse de la méthode à l'exécution.
2° Les méthodes: Savoir avoir un code "unique"
Une méthode est un élément "indépendant" qui est appelé par un autre bout de programme.
Les intérêts
- Avoir un bout de code unique qu'on ne répète pas partout
- S'il y a un bug on ne le corrige qu'une fois
- Cela évite de corriger partout le même bug.
Dans la colonne de gauche on a un code identique "Code 1" collé dans chaque procédure. Si ce bout de code est buggé... on peut oublier d'en corriger un bout quelque part!
Dans la colonne de droite là, la méthode Code1 contient un élément centralisé qui est appelé par chaque procédure. C'est tout l'intérêt: si code1 a une cochonnerie, la corriger sera central à tous les appels.
Les pièges courants:
- Vouloir être trop générique: à vouloir trop détailler cela peut rendre le code illisible.
La granularité peut devenir un piège... si un bout de code n'est utile qu'une fois, il n'est peut-être pas judicieux d'en faire une méthode.
- Une méthode externe avec trop de cas différents peut montrer un vrai souci de conception. Si le code en question prend 36 paramètres parce qu'il y a trop de conceptions, réfléchir... et revoir l'organisation! Peut-être vaudrait-il mieux avoir du code plus verbeux plutôt que de faire un truc soi-disant centralisé ... à tort.
Petit cas d'école: deux bouts de code traitent une donnée quelconque. Dans le premier cas, cela n'en traite qu'une part restreinte (admettons un prix), et l'autre qu'un bout (admettons le nom des menus). Créer une méthode centrale qui doit dire "si on bosse sur le montant alors, si l'on traite les prix alors..." est trop verbeux. Autant créer une méthode
traiterPrix() et une méthode
TraiterMenus() plus courtes et explicites.
- Toujours se poser des questions sur ce que retourne la méthode. On ne renvoie pas n'importe quoi sous prétexte de renvoyer un truc. Si tu appelles machin() et que machin retourne du texte mais que tu ne le lis jamais... alors pourquoi retourner du texte?!