Placement de code personnalisé dans un espace de noms système

Question

Existe-t-il des bonnes pratiques selon lesquelles le code personnalisé d'état ne doit pas être placé dans un espace de nom ? System et ses enfants doivent-ils être réservés au code Microsoft?

Je demande parce que j'écris une bibliothèque de classes qui sera utilisée dans de nombreux projets et je voudrais garder les choses cohérentes en le plaçant dans System.InteropServices (puisqu'il s'agit de P/Invoke).

Answer 1

Ce n'est pas une bonne idée car cela annule l'un des principaux avantages des espaces de noms: éviter les conflits de noms. Que se passe-t-il si une version plus récente du framework introduit un type nommé de manière identique dans cet espace de noms?

Cela est particulièrement mauvais pour System namespaces car ils sont importés dans beaucoup d'autres morceaux de code avec using directives et l'introduction de types personnalisés dans les espaces de noms pollue le champ d'attribution de noms d'autres fichiers source avec des identifiants inattendus.

Pour catégoriser vos types liés à l'interopérabilité personnalisée, vous pouvez créer un nouvel espace de nom tel que MyProduct.InteropServices.

Answer 2

Si vous placez une nouvelle classe dans System.InteropServices, chaque fichier ayant une clause using System.InteropServices; est obligé d'avoir votre classe dans la portée, ce qui peut perturber le programmeur. Puisque le programmeur ne peut pas se défendre contre cela, je considérerais cette mauvaise pratique.

Answer 3

Je ne suis pas d'accord avec tout le monde.

Je pense que dans un sous-ensemble limité de cas (la plupart du temps avec des méthodes d'extension), il est parfaitement raisonnable de placer du code dans un espace de noms système.

Voici mon côté de l'argument d'un fil de discussion que nous avions débattre des méthodes d'extension dans l'espace de noms System sur au EPS:

---

Ok, voici donc mon côté de l'argument:

1. J'aime vraiment minimiser le code. Cela inclut les utilisations. Oui, ReSharper reprend les méthodes d'extension et ajoute les utilisations pour vous mais certaines personnes n'ont pas de ReSharper, et d'ailleurs, je préfère Coderush qui n'a pas encore (pour autant que je sache) d'extension espaces de noms.

2. Il existe au moins deux types différents de méthodes d'extension; ceux qui sont des méthodes auxiliaires pour notre application - y compris les aides spécifiques au domaine et à l'application, et ceux qui encapsulent les caractéristiques et la syntaxe que nous pensons que le langage devrait avoir à commencer.

Un bon exemple de ce dernier est la possibilité de faire "a {0} {1}".Format("b", "c") ou someListOfStrings.Join(", ") plutôt que d'avoir à faire String.Join(someStringList.ToArray(), ", "). D'autres exemples plus discutables sont IEnumerable<T>.ForEach et l'extension IsNull() pour prendre la place de la syntaxe maladroite object.ReferenceEquals(null, someVar). Mon argument est, qu'il y a toutes les raisons de placer cette dernière classification - votre équipe est généralement d'accord qu'elle devrait être dans la langue mais ne l'est pas - dans l'espace de nom approprié (System, System.IO, System.Linq, etc.).Nous voulons que ces fonctions soient disponibles partout, tout comme nous préférons que les mots-clés foreach et yield soient toujours visibles. Si elle est spécifique à l'application, elle doit toutefois figurer dans son propre espace de nom. 90% du temps, les extensions auxiliaires spécifiques à l'application ne devraient probablement pas être des extensions et ne sont même pas statiques. J'exclus de cette instruction en utilisant des méthodes d'extension pour fournir des alias pour les noms de fonctions.

Vous pouvez rencontrer des problèmes lors de l'appel à des assemblys contenant des extensions à l'échelle du système. Supposons que je référençais l'assembly contenant ma méthode vide IEnumerable<T>.ForEach et que je voulais créer mon propre R IEnumerable<T, R>.ForEach (qui est en fait juste un Select, mais qui ne va pas). Ce serait un problème! Ce que j'aime faire pour atténuer le problème est de définir mes classes d'extension comme étant internes afin qu'elles puissent être utilisées uniquement sur mon projet. Cela résout bien le problème.