Namespaces y extensiones ¿Es "System" el lugar adecuado?

Este post viene como respuesta al post de Lluís Franco, que a su vez respondió al post de Javier Torrecilla y a una conversación entre varios colegas en Twitter, todos hablando de la mejor forma de ubicar los métodos extensores dentro de los namespaces. Aquí les dejo mi opinión al respecto.

Para el que no leyó los articulos antes citados, básicamente la discusión ronda sobre la mejor ubicación (en namespaces) para declarar un método extensor. Por ejemplo, veamos el ejemplo usado en los artículos anteriores que sirve para determinar si un valor se encuentra dentro de un rango determinado:

namespace CustomExtensions
{
    public static class ExtensionMethods
    {
        public static bool Between<T>(this T @value, T min, T max)
            where T : IComparable<T>
        {
            return @value.CompareTo(min) >= 0 && @value.CompareTo(max) <= 0;
        }
    }
}

En este caso, el método "Between" se encuentra ubicado dentro de un namespace con el nombre "CustomExtensions", lo que provocará que al tratar de usarlo, tengamos primeramente que ponerlo en uso de la siguiente forma:

using CustomExtensions;
...
var x = 10;
Console.WriteLine(x.Between(5, 15) ? "yes" : "no");

Obviamente, si no ponemos en uso el namespace "CustomExtensions", el método "Between" no podrá ser utilizado en nuestro código a menos que nos encontremos en una clase ubicada en el mismo namespace. En el primero de los artículos referenciados al inicio de este post, el autor propone tres formas de lidiar con esto, y se decanta por la variante de ubicar las extensiones en el mismo namespace de la clase a la que están extendiendo, en este caso, en el namespace System.

Particularmente no soy partidario de esta solución.

Veamos primeramente cuál es el "problema" en cuestión, y cito del artículo de Lluís Franco (las negritas son mías):

...si deseamos evitar declarar el using (tenéis que pensar que este método extensor lo podéis reutilizar en 1000 proyectos distintos)...

¿Por qué motivo vamos a querer evitar declarar el using? El que tengamos que utilizar el método extensor en 1,000 proyectos diferentes no creo sea una razón válida para no crear nuestro propio namespace, sino todo lo contrario. Creo que esta posibilidad reafirma aún más la necesidad de definir correctamente el espacio de nombres en el cual ubicaremos nuestro método. Veamos qué dice Microsoft sobre los namespaces:

The namespace keyword is used to declare a scope. This namespace scope lets you organize code and gives you a way to create globally unique types.

En otras palabras, un namespace nos permite organizar nuestro código y crear tipos de datos globalmente únicos, evitando colisiones de nombres cuando usamos bibliotecas de terceros. Imaginemos por un instante que Microsoft decidiera comenzar a colocar todas sus clases en el namespace System, para evitar de esta manera que los desarrolladores tengan que importar (o usar) los namespaces correspondientes. ¿Tiene sentido? Obviamente no.

¿Qué sucedería si estamos usando una biblioteca cualquiera en la cuál sus desarrolladores decidieron crear una clase llamada "Persona" y colocarla en el namespace System? Supongamos que nosotros mismos necesitamos crear una clase con el mismo nombre, y "para evitar declarar el using", la queremos colocar también en el namespace System. Colisión de nombres... o dejamos de usar la biblioteca, o ubicamos nuestra clase "Persona" en un namespace diferente.

¿O qué tal si el propio Microsoft decide incluir un método extensor "Between" en su próxima versión del Framework? ¿Qué sucede con nuestro código? Obviamente no compilará, así que tendremos que cambiar el namespace e incluir todas las referencias del mismo donde quiera que lo estemos usando.

Otro punto es precisamente la afirmación de que incluyendo el método extensor en el namespace System evitará tener que declarar el using correspondiente. Esto no tiene tampoco por qué ser realidad. Todos los namespaces hay que ponerlos en uso utilizando la palabra reservada "using" a menos que nos encontremos dentro del propio namespace, lo que sucede es que, en el caso de una aplicación de Windows Forms (como el ejemplo del post referenciado), el namespace System ya estará por defecto en uso, así que no habría que declarar nada para utilizar el método extensor. Sin embargo, ¿qué sucede cuándo vayamos a usar el método extensor en una nueva clase? ¿O qué sucede cuando no estemos utilizando Visual Studio y por lo tanto nadie incluya automáticamente el namespace System?

Por último, de acuerdo con su objetivo de organizar el código, el uso correcto de los namespaces le indica al desarrollador de dónde viene cada clase utilizada. Esta información puede ser útil en muchos sentidos, y si decidimos empezar a colocar cosas en el namespace System, el código confundirá a más de uno. Simplemente no habría forma de determinar de dónde sale el método "Between": ¿es este un método del propio Framework o está definido en cualquier otra biblioteca? El hecho de que solamente se use "using System" me indica que Between es una extensión de Microsoft incluída en el framework, ¿o no?

Resumiendo, creo que hay demasiados puntos en contra de este criterio como para comulgar con él, pero me encanta el hecho de que cada cuál tenga su propia visión al respecto y la exprese abiertamente. A veces cosas que nos parecen tan sencillas y comúnes como la definición de los espacios de nombres, pueden volverse complicadas y decisivas en un buen diseño. Discutir al respecto y oír criterios dispares es el único modo de encontrar la solución adecuada.