Colocación de código personalizado en un espacio de nombres del sistema

Question

¿Existen prácticas recomendadas que indiquen que el código personalizado no se debe colocar en un espacio de nombre System? ¿Deberían reservarse System y sus hijos para el código de Microsoft?

Lo pido porque estoy escribiendo una biblioteca de clases que se usará en muchos proyectos y me gustaría mantener las cosas consistentes colocándolas en System.InteropServices (ya que se trata de P/Invocar).

Answer 1

No es una buena idea porque anula uno de los principales beneficios de los espacios de nombres: evitar los conflictos de nombres. ¿Qué ocurre si una versión más reciente del marco introduce un tipo de nombre idéntico en ese espacio de nombres?

Esto es particularmente malo para System espacios de nombres ya que se importan en muchas otras piezas de código con using directivas y la introducción de tipos personalizados en dichos espacios de nombres contamina el ámbito de denominación de otros archivos de origen con identificadores inesperados.

Para categorizar sus tipos de interoperabilidad relacionados, puede crear un nuevo espacio de nombres como MyProduct.InteropServices.

Answer 2

Si coloca una nueva clase en System.InteropServices, cada archivo que tiene una cláusula using System.InteropServices; está obligado a tener su clase en alcance, lo que puede confundir al programador. Como el programador no puede defenderse de esto, consideraría esta mala práctica.

Answer 3

No estoy de acuerdo con todos.

Creo que en un subconjunto limitado de casos (principalmente con métodos de extensión) es perfectamente razonable colocar el código en un espacio de nombres del sistema.

Aquí es mi lado de la discusión de una cadena de correos electrónicos que habíamos debatir métodos de extensión en el espacio de nombres System encima en EPS:

---

Ok, así que aquí está mi lado de la discusión:

1. Me gusta mucho minimizar el código. Eso incluye usings.

2. Sí, ReSharper recoge los métodos de extensión y agrega los usos para usted, pero algunas personas no tienen ReSharper, y además, prefiero Coderush que hasta el momento no (hasta donde yo sé) recoger la extensión espacios de nombres

3. Existen al menos dos tipos diferentes de métodos de extensión; los que son métodos auxiliares para nuestra aplicación, incluidos los asistentes de dominio y específicos de la aplicación, y los que encapsulan características y sintaxis que creemos que el lenguaje debería haber tenido para comenzar.

Un buen ejemplo de esto último es la capacidad de hacer "a {0} {1}".Format("b", "c") o someListOfStrings.Join(", ") lugar de tener que hacer String.Join(someStringList.ToArray(), ", "). Otros ejemplos más debatibles son IEnumerable<T>.ForEach y la extensión IsNull() para tomar el lugar de la sintaxis object.ReferenceEquals(null, someVar) torpe.

Mi argumento es que hay muchas razones para ubicar esta última clasificación -su equipo generalmente acepta que debe estar en el idioma pero no está- en el espacio de nombres apropiado (System, System.IO, System.Linq, etc.)Queremos que esas funciones estén disponibles en todas partes, al igual que preferimos el foreach y ceder palabras clave para que siempre estén visibles. Sin embargo, si es específico de la aplicación, debe ir en su propio espacio de nombres. El 90% de las veces las extensiones de ayuda específicas de la aplicación probablemente no sean extensiones y ni siquiera sean estáticas. Excluyo de esta declaración el uso de métodos de extensión para proporcionar alias para nombres de funciones.

Puede obtener algunos problemas con esto, por supuesto, al llamar a los ensamblados que contienen extensiones de todo el sistema. Supongamos que estaba haciendo referencia al ensamblaje que contiene mi método void IEnumerable<T>.ForEach y quería crear mi propio ruby-like R IEnumerable<T, R>.ForEach (que en realidad es solo un Select, pero no lo sé). ¡Esto sería un problema! Lo que me gusta hacer para mitigar el problema es definir mis clases de extensión como internas para que puedan usarse solo en mi proyecto. Esto resuelve el problema muy bien.