Hay escenarios en los que en el interior de una clase utilizamos de forma intensiva miembros estáticos de otras clases. Un ejemplo habitual podemos encontrarlo en componentes que hagan mucho uso de
System.Math
para la realización de cálculos matemáticos, o incluso en el conocido System.Console
:Pues bien, en C# 6 podremos indicar mediante un
using
que vamos a realizar llamadas a miembros estáticos de la clase que indiquemos, por lo que no será necesario especificarla en cada llamada:Internamente, cuando el compilador encuentra esas llamadas a
WriteLine()
o ReadLine()
, determinará que pertenecen al objeto System.Console
porque no existe ningún otro candidato más apropiado que las implemente. Si la propia clase Program
dispusiera de un método estático WriteLine()
, se habría utilizado éste.También se tienen en cuenta casos en los que la llamada pudiera resultar ambigua para evitar. Por ejemplo, si estamos haciendo un
using
de dos clases que implementan un método estático con el mismo nombre y signatura, el compilador se quejará y tendremos que referenciarlas de forma explícita, como hemos hecho hasta ahora.Ciertamente usando esta característica podemos ahorrar muchas pulsaciones de teclas, así como hacer más claro nuestro código… ¿o no? El problema lo veo justamente ahí: en la claridad. Aunque visualmente el código resulta menos denso y más fácil de leer, estamos incluyendo un cierto grado de “ofuscación” (por llamarlo de alguna forma) que puede complicar la comprensión de lo que se hace o dónde se hace. Por ejemplo, fijaos en las llamadas que se realizan desde el siguiente método:
Podemos ver que usamos muchos métodos matemáticos y por tanto sería un caso de uso de esta nueva característica del lenguaje, pero en un vistazo no se sabríamos quién los está implementando. En versiones de C# anteriores a la 6, podríamos asegurar que
Sinh()
, Pow()
, Sqr()
o Floor()
son miembros de la clase actual o algunas de sus antecesoras, pero en la nueva versión un using System.Math
al principio del archivo podría invalidar esta afirmación.De hecho, ni aún existiendo ese
using System.Math
podríamos estar seguros de dónde se encuentra definido un método, porque podríamos tener una implementación local a la clase del mismo que sería la utilizada aunque a nivel de código no quede explícitamente indicado. Y también puede dar lugar a confusiones casos como la llamada a Sqr()
del código anterior porque, aunque parezca lo contrario, no existe en System.Math
(el método que realmente existe es Sqrt()
).En fin, supongo que ocurre como con muchas otras características del lenguaje, que no son de por sí buenas ni malas: todo depende del uso que se les dé. Probablemente hacer un uso razonable de esta característica en un contexto concreto y acotado podría ser útil para ahorrarnos trabajo, pero no tengo claro si el coste en términos de legibilidad compensará en muchos casos.
Ya con el tiempo, cuando vea cómo se utiliza y los problemas que crea en proyectos reales igual cambio de idea, pero de momento pienso que se podían haber ahorrado el esfuerzo.
Publicado en Variable not found.