Qu'est-ce qu'un argument de sortie, tel que mentionné dans Martin's Clean Code?

À la page 45 du code propre de Robert C. Martin: un manuel de fabrication de logiciels agiles, Martin écrit que les arguments de sortie doivent être évités. J'ai du mal à comprendre la signification de "l'argument de sortie" et pourquoi il faut les éviter.

L'exemple de Martin pour un argument de sortie appendFooter(s);appelle la fonction public void appendFooter(StringBuffer report). Son amélioration du code estreport.appendFooter();

C'est peut-être dû au manque de contexte de code, mais je ne vois pas comment l'utilisation d'arguments de sortie est considérée comme un mauvais codage. Quelqu'un pourrait-il expliquer le concept ou donner un exemple supplémentaire de code pour comprendre cela?

La fonction suivante serait-elle également considérée comme un exemple de code impur selon le principe ci-dessus?

int[] numberArray = {3, 5, 7, 1};
sortArray(numberArray);

Si ce qui précède est une violation du principe de Martin de ne pas utiliser d'arguments de sortie, serait-il préférable d'avoir un objet qui a un tableau comme champ et une fonction qui peut être appelée pour trier le tableau?

ObjectWithArrayField numberArray = new ObjectWithArrayField(3, 5, 7, 1);
numberArray.sort();

Bob Martin parle simplement de lisibilité .

Le problème avec l' appendFooterexemple est que si vous trouvez la ligne de code appendFooter(s)quelque part dans un programme, il n'est pas immédiatement évident si cet appel prend sen entrée et l'ajoute quelque part, ou s'il sest simplement passé pour prendre la sortie de cette fonction. Pour être sûr, vous devez vérifier la documentation de la fonction. Un appel comme report.appendFooter(), cependant, évite ce problème: il est beaucoup plus évident maintenant ce qui se passe.

Notez cependant que Bob Martin ne dit pas "n'utilisez jamais d'arguments de sortie", il dit "en général, vous devriez l'éviter, car cela vous aidera à garder votre code un peu plus propre". Il ne s'agit donc pas d'une règle de bravoure culte qui devrait être suivie aveuglément.

Sortles méthodes pour les tableaux et les collections standard sont un peu différentes. Avoir la sortméthode une fonction membre de chaque type de données de tableau standard aurait quelques inconvénients du point de vue du concepteur de langage, par exemple, avoir une méthode comme Array.sortpermet de garder cela dans la bibliothèque standard, en dehors du runtime Java. Mais si vous souhaitez créer un type de collection individuel qui doit parfois être trié, l'ajout en sorttant que fonction membre peut en effet être une meilleure idée que de le placer dans une classe distincte.

Il s'agit d'utiliser un mécanisme inattendu pour renvoyer une valeur de la fonction, ce qui est généralement le résultat de trop faire dans la fonction ou d'avoir des responsabilités mal alignées. De loin, la meilleure façon de communiquer le résultat d'une fonction est d'utiliser la valeur de retour. J'espère que cela va de soi. Dans les langages orientés objet, la deuxième méthode consiste à muter l'objet.

Entre ces deux options, il y a tellement de façons claires et évidentes de communiquer le résultat d'une fonction que si vous vous retrouvez à vouloir muter les arguments comme seul moyen, quelque chose a mal tourné dans votre architecture. Vous devez réorganiser vos responsabilités de classe afin que celui qui effectue la mutation soit propriétaire des données en premier lieu.

La seule exception concerne les algorithmes très génériques. Par exemple, un algorithme de tri peut à juste titre être séparé des conteneurs qu'il trie, s'il peut être appliqué de manière générique à tout type de conteneur à l'aide de son interface publique. Une appendFooterfonction ponctuelle n'a pas cette excuse.