Pourquoi les paramètres "out" en .NET sont-ils une mauvaise idée ?
On m'a récemment posé cette question, mais je n'avais pas de véritable réponse, si ce n'est qu'il s'agit tout simplement de compliquer inutilement une application. Quelles autres raisons y a-t-il ?
Ce n'est pas une mauvaise idée, je pense. Dictionary<K, V> a un TryGetValue qui est un très bon exemple de la raison pour laquelle les paramètres de sortie sont parfois une chose très agréable à avoir.
Bien sûr, il ne faut pas abuser de cette fonctionnalité, mais ce n'est pas une mauvaise idée par définition. Surtout pas en C#, où il faut écrire le nom de l'élément out mot-clé dans la déclaration de la fonction et qui rend évident ce qui se passe.
Le problème est que vous n'avez pas à écrire le mot-clé out pour les objets et qu'ils peuvent toujours être modifiés au sein de la méthode, ce qui entraîne des effets secondaires. Personnellement, je préfère de loin le paradigme de la programmation fonctionnelle.
Non, vous avez tort. Le contenu de l'objet peut changer, mais l'objet lui-même ne peut pas être échangé à un autre objet, sauf si vous le passez avec ref ou out . C'est le véritable intérêt de ces modificateurs ! Et oui, je suis d'accord que cela frappe lourdement le paradigme fonctionnel. Mais cela a quand même du mérite parfois.
Si vous souhaitez écrire un code fiable en adoptant l'immuabilité et en supprimant les effets secondaires, les paramètres out sont une idée absolument terrible. Ils vous obligent à créer des variables mutables juste pour les gérer. (Non pas que C# supporte les variables de niveau méthode en lecture seule de toute façon (du moins dans la version que j'utilise, 3.5)).
Deuxièmement, ils réduisent la composition des fonctions en obligeant le développeur à mettre en place et à traiter les variables qui reçoivent les valeurs de sortie. C'est une cérémonie ennuyeuse. Vous ne pouvez pas composer des expressions en les utilisant avec une quelconque facilité. Par conséquent, le code faisant appel à ces fonctions se transforme rapidement en un grand désordre impératif, offrant de nombreux endroits où les bogues peuvent se cacher.
out Les paramètres peuvent être utiles dans quelques situations particulières exactement parce que ils empêchent la composition des fonctions : Par exemple, lorsqu'une fonction peut retourner un null et vous voulez obliger l'appelant à vérifier explicitement la présence de la valeur null avant que le résultat de la fonction ne soit transmis à la fonction suivante.
De plus, il est très difficile de réutiliser cette fichue méthode avec 128 paramètres. Il y a un collègue de travail qui adore faire ça et j'ai beaucoup de mal à maintenir son code.
C'est une bonne idée. Parce que parfois, vous voulez simplement retourner plusieurs variables à partir d'une méthode, et vous ne voulez pas créer une structure de classe "lourde" pour cela. La structure de classe enveloppante peut cacher la façon dont l'information circule.
Je l'utilise pour :
Si vous ne voulez pas d'une structure de classe "lourde", qu'y a-t-il de mal à utiliser une structure en C# plutôt qu'une classe à part entière ?
Parce que cela va ajouter de la complexité à votre code. Au lieu d'un simple appel, vous avez ajouté une dépendance à un type supplémentaire.
Cette réponse suggère à tort que l'utilisation de paramètres out est le seul moyen de renvoyer plusieurs valeurs à partir d'une fonction sans définir un type au préalable. Il existe de mauvaises façons, faiblement typées, de faire cela, par exemple en retournant une List<object> ou une ArrayList. Il existe également de bonnes façons, fortement typées, par exemple en retournant KeyValuePair<T, U> pour deux valeurs ou un type anonyme pour plus de deux valeurs. Aucune de ces approches ne nécessite de définir une classe ou une structure à l'avance.
Out - Les paramètres sont une mauvaise idée à mon avis. Ils augmentent le risque d'effets secondaires et sont difficiles à déboguer. La seule bonne solution sont les résultats de fonction et voici le problème : Pour les résultats de fonction, vous devez créer pour chaque résultat complexe un tuple ou un nouveau type. Maintenant, cela devrait être assez facile en C#, avec les types anonymes et les génériques.
Et d'ailleurs : Je déteste aussi les effets secondaires.
Le libellé de la question est le suivant de la "As-tu arrêté de frapper ta femme ?" variété -Cela suppose que out sont nécessairement une mauvaise idée. Il existe des cas où out les paramètres peuvent être abusés, mais
Ils s'intègrent en fait très bien dans le langage C#. Ils sont comme réf. sauf que la méthode est assurée de lui attribuer une valeur et que l'appelant n'a pas besoin d'initialiser la variable.
Les valeurs de retour normales des fonctions sont poussées sur la pile où elles sont appelées et quittent. Lorsque vous fournissez un out vous donnez à la méthode une adresse mémoire spécifique pour y placer le résultat. Cela permet également d'obtenir plusieurs valeurs de retour, bien que l'utilisation d'une structure soit souvent plus logique.
Ils sont merveilleux pour le motif TryParse et fournissent également des métadonnées pour d'autres choses comme dans le cas de SQL-CLR où out sont mis en correspondance avec les paramètres out paramètres de la signature d'une procédure stockée.
LOL J'ai trouvé ça après que Hanselman ait listé "Pourquoi les paramètres out sont une mauvaise idée en .NET ? Est-ce qu'ils le sont ? " comme question d'entretien, et la première pensée que j'ai eue a été " Quand avez-vous arrêté de battre votre femme ? ". Votre réponse montre que nous pensions la même chose.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
