En posts anteriores hemos hablado del operador de navegación segura “.?” y de la inicialización de propiedades automáticas, y vamos a comentar ahora otra de las novedades de la versión de C# que viene en camino, pero que en esta ocasión no tengo claro que sea un avance en la dirección correcta. Os lo cuento y ya decidís vosotros ;-)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:
Hace algún tiempo comentamos alguna de las novedades que se incluirán en la próxima versión de C#, concretamente el nuevo operador de navegación segura “?.”, pero la cosa no acaba aquí: se avecinan un buen número de cambios que prometen seguir mejorando nuestro lenguaje favorito :-)Por ejemplo, una nueva característica que tendremos disponible es la inicialización de propiedades automáticas, algo que antes también podíamos hacer, aunque de forma menos directa.
El operador “?.”, también llamado safe navigation operator, era la característica más demandada para el lenguaje C# en Uservoice, uno de los principales canales utilizado por Microsoft para obtener feedback e ideas a aplicar en nuevas versiones de sus productos, y parece que definitivamente se está considerando la posibilidad de incluir este útil azucarillo sintáctico tanto en C# como en VB.
Para los que no lo conozcáis, se trata de una construcción que permite acceder a propiedades de objetos sin temor a las null reference exceptions lanzadas cuando estos objetos son nulos.
Los parámetros opcionales son una interesante ayuda que hace tiempo que está presente en otros lenguajes como Visual Basic .NET, y ha sido introducida en la versión 4.0 de C#, para alegría de muchos.A grandes rasgos, esta característica nos permite especificar valores por defecto para los parámetros de nuestros métodos, ahorrándonos tiempo de codificación:
class Program
{
public static void Main(string[] args)
{
Muestra(); // Imprime 1,1
Muestra(8); // Imprime 8,1
Muestra(3,4); // Imprime 3,4
Console.ReadKey();
}
static void Muestra(int a=1, int b=1)
{
Console.WriteLine(a + "," + b);
}
}
Desde siempre, ignorante de mí, había pensado que esto no era más que una triquiñuela del compilador, un azucarillo sintáctico destinado a facilitarnos la creación de sobrecargas de forma rápida, pero, ahora que lo he estudiado algo más a fondo, resulta que no es así. De hecho, los parámetros opcionales están soportados a nivel de plataforma, y funcionan de forma algo extraña (o al menos diferente a lo que podía esperarse), por lo que es conveniente conocerlos bien para no cometer determinados errores.
En primer lugar, me ha llamado la atención que la detección de la ausencia de parámetros en la llamada y la asignación de los valores por defecto no la realiza el método en el que se han definido. Es decir, sobre el ejemplo anterior, no es el método
Muestra() el que comprueba si se han suministrado valores para los parámetros a y b, ni el que le asigna los valores por defecto en caso contrario. Esta "comprobación" se realiza en tiempo de compilación (!).Esto lo demostramos muy fácilmente si descompilamos esta misma aplicación con ayuda del imprescindible Reflector, que nos mostrará el siguiente código:
class Program
{
public static void Main(string[] args)
{
Muestra(1, 1);
Muestra(8, 1);
Muestra(3, 4);
Console.ReadKey();
}
public static void Muestra([Optional, DefaultParameterValue(1)] int a,
[Optional, DefaultParameterValue(1)] int b)
{
Console.WriteLine(a + ", " + b);
}
}
Como se puede observar, se ha generado un método
Muestra() cuyos parámetros incluyen atributos que indican su opcionalidad y el valor por defecto en cada caso.Pero lo curioso está en el método
Main(), desde donde se hacen las llamadas, el que podemos observar que las invocaciones a Muestra() incluyen valores para todos los parámetros, como si se tratara de constantes especificadas directamente por el desarrollador.Por tanto, no hay nada mágico en los métodos con parámetros opcionales, ni sobrecargas, ni código de comprobación o asignación insertado de forma automática. Es el propio compilador el que, en el momento de generar el código IL, extrae los valores por defecto de los parámetros no especificados en la llamada examinando los atributos presentes en la signatura y los introduce en la invocación.
Y es aquí justo donde hay que tener cuidado al utilizar los parámetros opcionales. Dado que el valor de los parámetros se determina en tiempo de compilación y se incluyen como constantes en el código IL generado, pueden producirse efectos no deseados si trabajamos con distintos ensamblados.
Veámoslo con un ejemplo, que, aunque poco real, creo que ilustrará un escenario donde los parámetros opcionales podrían jugarnos una mala pasada.
En el siguiente código, perteneciente al ensamblado
LogicaNegocio.dll, vemos un método CalculaImporteconIva(), que retorna un importe aplicándole el impuesto (IVA) correspondiente:public class LogicaNegocio
{
public double CalculaImporteConIva(double importe, double iva = 0.16)
{
return importe + importe*iva;
}
}
Así, podemos tener un ensamblado externo, pongamos
ERP.exe, que haga uso de este método de la siguiente forma:public void muestraDesglose(double importe)
{
double importeTotal = logica.CalculaImporteConIVA(importe)
// Mostrarlo...
}
En el momento de compilación de
ERP.exe, la llamada anterior quedará en el ensamblado resultante igual que si hubiéramos hecho esta llamada: double importeTotal = logica.CalculaImporteConIVA(importe, 0.16)
Si ahora se produce una subida de IVA (como lamentablemente va a ocurrir en breve), acudiríamos a modificar el valor por defecto del parámetro
iva en el método CalculaImporteConIva() y recompilaríamos LogicaNegocio.dll:public class LogicaNegocio
{
public double CalculaImporteConIva(double importe, double iva = 0.18)
{
return importe + importe*iva;
}
}
Sin embargo, si no recompilamos
ERP.EXE desde éste seguiríamos enviándole el valor anterior (0.16, recordad que este valor aparece como constante en el ensamblado), lo que podía provocar algún problema. Es decir, si queremos mantener la coherencia del sistema, nos veríamos obligados a recompilar todos los ensamblados que referencien LogicaNegocio.dll.Conclusión: en métodos públicos, y especialmente en aquellos que serán consumidos desde ensamblados externos, es conveniente utilizar parámetros opcionales sólo cuando los valores constantes sean “verdades universales”, como las constantes matemáticas o datos que con toda seguridad no van a cambiar. No es buena idea utilizarlos para reflejar valores variables o constantes de lógica de negocio, con posibilidades de cambio aunque sean remotas.
Por último, comentar que aunque este post está centrado en C#, todas estas precauciones son igualmente válidas para Visual Basic .NET.
Publicado en: Variable not found
Casualmente encuentro en el post de Chris Eargle “Any() versus Count()” un tema del que pensaba escribir hace tiempo y al final dejé en el tintero: ¿cómo podemos determinar si una enumeración está vacía? Vale, es bien fácil, una enumeración está vacía si tiene cero elementos.Si trabajamos con un array, podemos consultar la propiedad
Length; si se trata de una colección, podemos utilizar la propiedad Count, que también nos devolverá el mismo dato de forma directa.Sin embargo, cuando procesamos información es frecuente tratar con tipos de datos enumerables cuya implementación exacta desconocemos, y en los que no tenemos acceso a ninguna propiedad que nos permita conocer el número de elementos exactos que tiene almacenados. Por ejemplo, esto ocurre cuando obtenemos un conjunto de datos en forma de
IEnumerable o trabajamos con LINQ sobre alguna fuente de información.Pues bien, en estos casos hay que ser algo prudentes con la forma de consultar el número de elementos. Me he topado con código
Count(), facilitado por LINQ para las enumeraciones y otras colecciones de datos, con objeto de saber si una lista estaba vacía:var prods = services.GetProductsByCategory(category);if (prods.Count() > 0){ // Hacer algo con los elementos de la lista}
else{ // No hay elementos}
Seguro que ya os habréis percatado de que eso está mal, muy mal. El método
Count() recorrerá uno por uno los elementos para contarlos, retornando el número exacto de ellos. En escenarios de un gran número de elementos, o cuando es costoso obtener cada elemento (como al traerlos de una base de datos) puede suponer un consumo de recursos enorme.Y justo por esto existe el método
Any(), que comprueba únicamente si existe al menos un elemento en la colección. Internamente este método itera sobre la colección retornando true cuando encuentra el primer elemento, por lo que es mucho más eficiente que el anterior:var prods = services.GetProductsByCategory(category);if (prods.Any()) // Mucho mejor :-)
{ // Hacer algo con los elementos de la lista}
else{ // No hay elementos}
La utilización de
Any() también es interesante para comprobar la existencia de elementos que cumplan una condición, expresada en forma de predicado; retornará true cuando encuentre el primer elemento que lo haga cierto:if (pedidos.Any(p => p.Pendiente)){ // Mostrar alerta, hay al menos un pedido pendiente}Estamos en la puerta de un Estadio y queremos saber si vamos a ser los primeros en entrar al recinto… ¿le preguntaríamos al portero el número exacto de aficionados que ya están dentro para, si es cero, saber que somos los primeros? ¿O nos bastaría simplemente con preguntarle si hay alguien? ;-P
Publicado en: Variable not found
Hey: ¡estoy en Twitter!
Encuentro en el blog de Gunnar Peipman un post sobre el nuevo método string.IsNullOrWhiteSpace, aparecido en .NET Framework 4.0 Beta 2, cuya misión es retornar un booleano indicando si la cadena pasada como parámetro contiene un nulo, está vacío, o exclusivamente caracteres de espaciado (espacios, saltos de línea, tabulaciones, etc.), un escenario bastante frecuente cuando estamos, por ejemplo, validando formularios o cualquier tipo de datos de entrada.
Por si no podemos esperar hasta la llegada de la nueva versión del framework, Gunnar propone una solución temporal basada en crear un método de extensión sobre la clase string que realice la misma tarea:
public static class StringHelper
{ public static bool IsNullOrWhiteSpace(this string s)
{ if (s == null)
return true;
return (s.Trim() == string.Empty);
}
}
string a = null;
string b = " ";
string c = "\n";
string d = "Hey!";
Console.Write (a.IsNullOrWhiteSpace()); // True Console.Write (b.IsNullOrWhiteSpace()); // True Console.Write (c.IsNullOrWhiteSpace()); // True Console.Write (d.IsNullOrWhiteSpace()); // FalseY para los fieles a Visual Basic .NET, ahí va el código equivalente:
Imports System.Runtime.CompilerServices Public Module StringHelper
<Extension()> _
Public Function IsNullOrWhiteSpace(ByVal s As String) As Boolean
If s Is Nothing Then
Return True End If
Return s.Trim() = String.Empty
End Function
End Module
Publicado en: Variable not found.
No es algo que ocurra muy frecuentemente, pero en determinadas ocasiones puede ser útil inicializar una propiedad de un tipo anónimo con el valor nulo, por ejemplo:
var conductor = new { Nombre = ”Marisa”, Edad = 34, Auto = “Renault Megane” };var peaton = new { Nombre = “Juan”, Edad = 43, Auto = null };
En el código anterior se entiende que lo que queremos indicar estableciendo la propiedad Auto a null es que la persona que estamos representando no dispone de automóvil, o bien no conocemos este dato.
Algo muy normal… sino fuera porque el compilador se empeña en abofetearnos con el siguiente error:
Cannot assign <null> to anonymous type property
Y la verdad, en cuanto lo pensamos un poco, tiene sentido. En los casos anteriores, se está instanciando un tipo anónimo cuyas propiedades son generadas en tiempo de compilación. En el caso anterior, el compilador crearía para el tipo anónimo una propiedad “Nombre” de tipo string, una “Edad” de tipo integer, y una “Auto”, de tipo… ¿qué tipo podría asignar el compilador a esta propiedad? Ese es precisamente el problema.
Lo mismo ocurre al intentar inicializar variables implícitamente tipadas con el valor nulo; aunque cambia el error, el concepto idéntico, el compilador no es capaz de inferir el tipo de la variable:
var persona = null; // Error: Cannot assign <null> to an implicitly-typed local variable
La forma de solucionarlo en ambos casos es muy sencilla: basta con informar explícitamente al compilador del tipo de la propiedad, para que pueda crearla sin problema, por ejemplo así:
var peaton = new { Nombre = "Juan", Edad = 43, Auto = (string)null };
var persona = null as Persona;
Publicado en: Variable not found
En la plataforma .NET existen distintas formas de hacer que una llamada a un método sea omitida bajo determinadas circunstancias. Por ejemplo, los métodos parciales permiten, en C# 3.0 y VB 9.0, que el compilador omita la llamada a funciones no implementadas. También existe la posibilidad de utilizar las clásicas directivas (como #if… #endif ) para incluir código cuando existan constantes de compilación.
Es menos conocida, sin embargo, la existencia del atributo ConditionalAttribute, que aplicado a un método hace que las llamadas a éste no sean incluidas en el ensamblado si no existe la constante de compilación cuyo nombre se indica en el parámetro.
Por ejemplo, explorando un poco el espacio de nombres System.Diagnostics, vemos que todos los métodos de la clase Debug, están adornados por este atributo así:
1: [Conditional("DEBUG")]
2: public static void WriteLine(string message)
3: { 4: TraceInternal.WriteLine(message); 5: }Ahora, imaginad que tenemos un código que usa esta clase, por ejemplo de la siguiente manera:
1: public static void Main(string[] args)
2: {3: for(int i=0; i < 1000; i++)
4: {5: Debug.WriteLine("Iteración " + i);
6: ProcesaAlgoComplejo(i);7: int j = ProcesaOtraCosa(i);
8: Debug.WriteLine("Obtenido " + j);
9: // ...
10: } 11: }Si compilamos en modo “debug” (o simplemente está definida la constante de compilación con dicho nombre), las llamadas a estos métodos serán omitidas en el ensamblado resultante, por lo que el código finalmente generado será totalmente equivalente a:
1: public static void Main(string[] args)
2: {3: for(int i=0; i < 1000; i++)
4: { 5: ProcesaAlgoComplejo(i);6: int j = ProcesaOtraCosa(i);
7: // ...
8: } 9: }Pero ojo, que se omiten tanto las llamadas al método como la evaluación de sus parámetros, y esto puede provocar errores difíciles de detectar. Por ejemplo, el siguiente código daría lugar a un bucle infinito de los de toda la vida ;-) si compilamos en modo “release”; sin embargo, compilando en “debug” funcionaría correctamente:
1: int j = 0;
2: while (j < 100)
3: {4: Console.WriteLine("Hey " + j);
5: Debug.WriteLine("Procesado " + (j++)); // <-- Esta línea desaparece cuando
6: // compilamos en modo release!
7: }Aunque en el anterior ejemplo estamos jugando con la constante predefinida DEBUG, este atributo podemos utilizarlo con otras constantes, tanto existentes como personalizadas. Como muestra, podéis echar un vistazo a la definición de la clase System.Diagnostics.Trace, que vincula el uso de sus métodos a la existencia de la constante TRACE:
1: public sealed class Trace
2: { 3: // ...
4: 5: private Trace();
6: [Conditional("TRACE")]
7: public static void Assert(bool condition);
8: [Conditional("TRACE")]
9: public static void Assert(bool condition, string message);
10: [Conditional("TRACE")]
11: public static void Assert(bool condition, string message, string detailMessage);
12: [Conditional("TRACE")]
13: public static void Close();
14: [Conditional("TRACE")]
15: public static void Fail(string message);
16: [Conditional("TRACE")]
17: public static void Fail(string message, string detailMessage);
18: [Conditional("TRACE")]
19: public static void Flush();
20: [Conditional("TRACE")]
21: 22: //...
23: }Si vais a utilizar el atributo sobre vuestros métodos, condicionándolos a la existencia de constantes de compilación personalizadas, recordad que las constantes podéis definirlas:
- desde las propiedades del proyecto en el IDE
- en la línea de comandos del compilador (por ejemplo,
/define:LOG) - variables de entorno del sistema operativo (
set LOG=1) - en directivas sobre vuestro propio código (directiva
#define LOG)
Eso sí, tened en cuenta que el método siempre será compilado e introducido en el ensamblado, son las invocaciones a éste las que son omitidas en caso de no existir la constante indicada.
Hay que tener en cuenta las siguientes observaciones para el uso del atributo Conditional:
- Los métodos a los que se aplica no pueden tener tipo de retorno, es decir, serán
void. Esto tiene bastante sentido, si pensamos en los efectos laterales que podría causar la desaparición de una invocación tras la cual se haga uso del valor retornado. - Sólo se pueden aplicar a métodos en clases o estructuras. Nada de interfaces (¡tampoco tendría mucho sentido!).
- Si un método virtual está marcado como
Conditional, las reescrituras de éste realizadas desde clases descendientes también lo estarán. Es bastante lógico, puesto que así se mantienen las dependencias íntegras. - Si el atributo se aplica a un método, éste no puede ser un reemplazo del comportamiento de un antecesor (o sea, que no puede ser un override). También resulta muy lógico.
En resumen, se trata de un buen método para incluir código condicional en nuestros desarrollos, dependiente del contexto de compilación, evitando tener que usar directivas #if… #endif. Pero no lo olvidéis: cuidado con los efectos laterales citados.
Publicado en: Variable not found.
