Vaut-il la peine de créer une méthode si elle est appelée uniquement depuis un seul emplacement?

Question

Une discussion que j'ai eue aujourd'hui au travail avec un collègue.

Vaut-il la peine de créer une méthode séparée, si elle va être appelée uniquement depuis un seul endroit?. Certes, peut-être qu'à l'avenir vous devrez l'appeler depuis davantage d'endroits, mais pour les besoins de l'argument, supposons qu'il est connu qu'elle ne sera jamais appelée depuis un autre endroit.

Si oui : pourquoi ? ou quand (dans quelles conditions)?

Si non : pourquoi pas ? Et quel serait le nombre minimum d'appels qu'une méthode doit avoir?

---

Résultats : "Oui" a gagné 12 à 0

Answer 1

Oui. Les méthodes longues sont difficiles à lire et à maintenir.

Les opérations logiquement liées doivent être déplacées vers une méthode unique. Par exemple:

public void construireMaison() {
   poserFondations();
   construireMurs();
   plâtrer();
   construireToit();
}

Ainsi, au moins trois caractéristiques importantes:

• lisibilité - qui est bien plus lisible que si tout le code requis pour construire la maison était dans le corps de cette méthode.

• maintenabilité - imaginez si vous aviez 500 lignes de code mélangées pour construire la maison, et que vous deviez déboguer un problème sur le toit.

• testabilité - les tests unitaires sont également quelque chose à considérer. Vous voudrez peut-être tester chaque opération séparément.

Mise à jour: récemment on m'a posé cette question lors d'un entretien, et ils m'ont présenté un inconvénient qui m'a surpris - les performances. Dans le cas où vous allez avoir des milliers d'appels successifs à votre méthode, alors avoir des appels de méthode supplémentaires à l'intérieur nuit aux performances, même si mettre un appel de méthode sur la pile n'est pas si cher en soi. Bien sûr, c'est un cas très rare et vous devez être certain que les performances souffriront vraiment (en le vérifiant)

Answer 2

Oui, si cela améliore la lisibilité et/ou la testabilité. Considérez une méthode qui fait "beaucoup de travail" (par exemple, "obtenir la page web spécifiée") où le travail peut être subdivisé en étapes individuelles, dont chacune a seulement besoin de quelques informations des étapes précédentes. Diviser ce travail rend chaque étape plus testable et lisible : vous pouvez avoir une vue d'ensemble de ce que fait la méthode en lisant les étapes tour à tour, et vous pouvez facilement vous concentrer sur une étape particulière en lisant le code de cette seule étape.

Answer 3

Si la réutilisation du code n'est pas un problème, alors la lisibilité l'est. Créer une méthode séparée pour chaque bloc de code fonctionnellement complet le rend plus compréhensible, si vous lui donnez un nom approprié.

Answer 4

Coder, c'est communiquer votre intention. Si une méthode aide à clarifier votre intention, alors cela en vaut absolument la peine.

Une méthode peut donner un nom à une opération qui pourrait autrement être peu claire. Par exemple, disons que vous vouliez vérifier si un nombre est pair :

if(n % 2 == 0)

Toute personne qui lit cette ligne doit comprendre l'opérateur modulo, puis rétro-ingénierie le truc, pour enfin réaliser ce qui est vérifié. C'est beaucoup plus révélateur de l'intention :

if(IsEven(n))

Cela dit également au lecteur exactement pourquoi l'opérateur modulo est utilisé :

private static bool IsEven(int n)
{
    return n % 2 == 0;
}

Answer 5

Oui. Si la méthode ne fait qu'une seule chose, alors elle peut facilement être testée. Bien sûr, vous pouvez tester n'importe quelle méthode, mais dès que la complexité augmente, il est plus difficile de garantir la couverture de tous les chemins de décision.

Son état interne devient encapsulé, donc plus prévisible. Avez-vous déjà débogué une longue méthode et constaté qu'une autre partie du même code utilisait également "i" comme un compteur ?

De même, la maintenance du code/ les corrections de bogues sont également plus faciles car vous pouvez plus facilement trouver la source d'une erreur. Imaginez une tâche qui fait trois choses et qui prend environ 25 lignes de code. Demandez-vous si vous préférez déboguer 25 lignes de code, ou déboguer "première chose", "deuxième chose", "troisième chose" ?

Donnez des noms descriptifs aux méthodes et documentez leur comportement possible en entrée/sortie. Par exemple : Cette méthode renvoie l'élément ou retourne null quand l'élément n'est pas trouvé. Essayez de ne pas laisser les méthodes avoir des effets secondaires inattendus, c'est-à-dire en changeant des variables globales.