En java - comme la plupart des langages - il est très important de bien maîtriser les différents résultats d’une méthode.
De primes abord rien ne parraît plus trivial puisque la méthode déclare le type du paramètre retourné comme dans ce cas de figure :
public int ajouter (int a, int b)
Cependant, ça se corse un peu dès lors qu’on retourne un objet :
public String getParticipantName (int participantId)
En effet ce cas de figure peut retourner le nom du participant sous forme d’un objet String mais il peut également retourner null si aucun participant ne correspond à l’id donné en param.
Dans ce cas, il faudra tester obligatoirement que le résultat est différent de null avant de faire une quelconque opération dessus. Pour le développeur, de la méthode, retourner null signifie “je n’ai pas trouvé” ce qu’on me demande et me parraît être une valeur plus adéquat qu’une chaîne vide.
Si l’objet retourné est un tableau :
public ArrayList getParticipants(int epreuveId)
Dans ce cas de figure, je conseillerais au développeur implémentant cette méthode de retourner dans tous les cas un tableau même si celui-ci est vide. Ce qui signifierait texto : voici la liste demandée, elle est vide, plutôt que je n’ai rien à retourner. (dans ce cas je me demande s’il ne faudrait pas retourner la liste vide si c’est le cas et null dans le cas où on se rend compte que l’epreuveId est incohérent ?).
En tout état de cause lorsqu’on parcourera ensuite la variable retournée, on n’aura pas la mauvaise surprise de déclencher un NullPointerException.
Cas des RuntimeException :
private int divise (int a, int b)
La division pose un problème bien connu : celui de la division par 0. Cependant on peut imaginer - vu que la méthode est privée - qu’avant d’utiliser cette méthode, on aura au préalable géré les pré-conditions à son appel. Dans ce cas le développeur ne veut pas avoir a gérer un try catch alors qu’il sait que les paramètres sont déjà vérifiés. Toutefois si notre méthode divise venait à être utilisée dans le cas interdit, il faudrait lever une exception de type RuntimeException. Cette Exception ne nécessite pas d’être déclarée mais pourra cependant signaler la mauvaise utilisation de la méthode.
Cas des Exceptions :
public int divise (int a, int b) throws Exception
Ici, notre méthode devra pouvoir lever une Exception dans le cas où il y aurait une division par 0. En effet cette méthode est visible par tout le monde et on ne sera pas certain que tout ses utilisateurs auront vérifié les pré-conditions à son utilisation. La seule issue possible est le déclenchement de l’exception adéquate que l’utilisateur de la méthode devra obligatoirement prendre en compte.
Cas des arguments modifiés par référence :
public void removeTokensFromString(String stringToParse, String tokenToBeRemoved)
Imaginons que cette fonction doive parser la chaine “stringToParse” afin d’enlever toutes les occurences de “tokenToBeRemoved”, dans cas cas là certains développeurs n’hésitent pas à utiliser la possibilité du passage par référence pour manipuler directement le contenu de stringToParse.
Je reste persuadé qu’il faudra toujours préférer écrire ce genre de fonction de la manière suivante :
public String removeTokensFromString(String stringToParse, String tokenToBeRemoved)
et l’utiliser de la façon suivante:
String chaineToParse = “les avions sont dans le ciel bleu”;
chaineToParse = removeTokensFromString(chaineToPars, “bleu”);
plutôt que la première méthode qui s’écrirait :
String chaineToParse = “les avions sont dans le ciel bleu”;
removeTokensFromString(chaineToPars, “bleu”);
Voyez-vous des cas où cette deuxième façon d’écrire pourrait ne pas être appliquée ?
Quoiqu’il en soit l’utilisation et l’implémentation d’une méthode en java peut avoir maintes et maintes interractions sur l’exécution logique de votre code, il est donc primordial d’avoir conscience de tous ces principes.
Pour les joueurs : voici un petit cas d’école VBScript.
En ces temps troubles où la 
Commentaires récents