c# - org - ¿Está bien escribir mis propios métodos de extensión en el espacio de nombres del sistema?

mapwindows 5

Question

He estado usando métodos de extensión bastante recientemente y he encontrado muchos usos para ellos. El único problema que tengo es recordar dónde están y qué espacio de nombres usar para obtener los métodos de extensión.

Sin embargo, recientemente pensé en escribir los métodos de extensión en el espacio de nombres del sistema, el espacio de nombres System.Collections o algún otro espacio de nombres del sistema que tenga sentido. Entonces, por ejemplo, he implementado lo siguiente.

namespace System
{
/// <summary>Various array extensions</summary>
public static class ArrayExtensions
{
/// <summary>Converts the array to a hex string</summary>
/// <param name="value">The value.</param>
/// <returns>The array as a hex string</returns>
public static string ToHexString(this byte[] value)
{
var hex = new StringBuilder(value.Length * 2);
foreach (byte b in value)
{
hex.AppendFormat("{0:X2}", b);
}
return hex.ToString();
}
}
}

¿Es esto lo correcto?

Answer 1

De las Pautas de diseño del marco (2da edición):

NO coloque los métodos de extensión en el mismo espacio de nombres que el tipo extendido, a menos que sea para agregar métodos a las interfaces o para la administración de la dependencia.

Si bien esto no cubre explícitamente su escenario, generalmente debe evitar extender un espacio de nombre de Marco (o cualquier espacio de nombre sobre el que no tenga control) y optar por poner esas extensiones en su propio espacio de nombres. Si tiene muchas ganas de "agrupar" las extensiones (de modo que las extensiones de la colección estén juntas, etc.), entonces podría introducir un espacio de nombres secundario. En su escenario, la extensión a las colecciones iría en un espacio de nombres System.Collection.Extensions o un espacio de nombres Company.Collections o incluso un espacio de nombres Company.Collections.Extension .

Para usar métodos de extensión, se debe importar el espacio de nombres que contiene la clase de patrocinador (la clase que define los métodos de extensión). Si agrega métodos de extensión a uno de los espacios de nombres estándar de .NET Framework, estarán siempre (e implícitamente) disponibles.

Answer 2

Debe evitar aumentar los espacios de nombres sobre los que no tiene control primario, ya que los cambios futuros pueden romper su código (mediante la introducción de duplicados, por ejemplo).

Tiendo a imitar los espacios de nombres estándar con un espacio de nombres raíz diferente que identifica todos los espacios de nombres secundarios como pertenecientes a mi trabajo. El espacio de nombre raíz podría ser su nombre, el nombre de su organización u otra cosa que identifique el contenido de ese espacio de nombres como suyo.

Por ejemplo, si desea extender System.Collections , puede usar NickR.Collections o NickR.System.Collections .

Answer 3

No estoy seguro si está mal (o correcto, para el caso), pero ¿por qué no tener su propio espacio de nombres ''Extensiones''? Luego ponga todos sus métodos de extensión en ese espacio de nombres y sea consecuente al respecto.

No creo que el verdadero problema sea dónde colocarlos o cómo nombrarlos (sistema o cualquier otro espacio de nombres), sino ser coherentes y usar siempre los mismos para evitar su problema (olvidando dónde están).

Answer 4

Lo único que el espacio de nombre realmente afecta con los métodos de extensión es la visibilidad y la visibilidad, por lo que depende de si desea que los métodos de extensión aparezcan siempre en ese tipo o no. Las directrices de diseño del marco están destinadas principalmente a API públicas, por lo que, aunque en general es una buena idea seguirlas, las reglas están muy por romperse para las API internas cuando tenga sentido.

Por ejemplo, trabajamos mucho con objetos TimeSpan en la base de código y no existen métodos para multiplicarlos o dividirlos en el marco, por lo que hemos agregado métodos de extensión MultiplyBy y DivideBy , entre otros, y los hemos incluido en el espacio de nombres del System porque quiero que sean accesibles y TimeSpan donde sea que se use TimeSpan .

Por otro lado, también hacemos un poco de trabajo de reflexión, operando en objetos Type , y hay muchos métodos de extensión que son muy útiles en áreas específicas, pero no en general, por lo que estos viven en un espacio de nombres OurCompany.Reflection para que tiene que ser importado específicamente

Entonces, para las API internas, la decisión se reduce a "¿quiero que este método esté disponible en todos los lugares donde el tipo esté disponible en nuestra base de código?". Si la respuesta es sí, póngalo en el mismo espacio de nombres, de lo contrario colóquelo en otro lugar.

Answer 5

Puse mis métodos de extensión en un espacio de nombres dependiendo de la visibilidad que quiero que tengan. De esa forma son más fáciles de descubrir, y generalmente obtengo menos importaciones de espacio de nombres.