Archivo de la categoría: C#

La evolución de las PCL con .NET Standard para Xamarin

En un anterior post hablé sobre la unificación de las librerías .NET a través de .NET Standard para desarrollos cross-platform.

Muchas de ellas, recientemente, han añadido soporte a la librería de .NET estándar. La virtud de esta librería es que agrupa un conjunto de API’s básicas y versiones construidas de forma agnóstica a la plataforma que las va a usar. Por este motivo, las librerías construidas con este subconjunto de dotnet se consideran una evolución a las librerías portables (PCL). Estas no tienen un Profile asignado si no que tienen un alias único que permite una comptaibilidad transversal de forma que las nuevas versiones de esta son compatibles con otras más antiguas.

Para entenderlo mejor, podemos ver un diagrama especifico que muestra el interior de la librería,netstandard

Y otro, de cómo esta organizado por dentro y como la capa de contratos hace posible esta compatibilidad lineal, 

.NET Standard contracts

Tenemos que tener en cuenta que la librería no puede tener todas las APIs que tenemos en .NET debido a que muchas de ellas están atadas a versiones especificas de Microsoft Windows y la totalidad del .NET Framework tradicional no es compatible con el enfoque cross-platform y por lo tanto, algunas API, dejan de tener sentido con este.

Cuantas más frameworks tenga que soportar la versión de .netstandard, menos APIs tendrá disponibles. Por ejemplo, netstandard1.0 es compatible con la mayoría de las plataformas pero con menos APIs y, por otro lado, netstandard1.6 soporta únicamente .NET Core 1.0 y .NET Framework 4.6.3 pero con disponibilidad de todas las APIs recientes de .NET. Para que tengáis una idea en cifras de lo que comento, .netstandard 1.0 tiene 7.949 APIs y 2.0, 32.638.

Xamarin, actualmente, soporta esta librería para los diferentes tipos de aplicaciones. Para ello nos debemos asegurar que estamos usando Visual Studio 2015 Update 3 y tener actualizado Xamarin a la versión 4.1.2.

Para hacer uso de ellas es muy sencillo y no conlleva ninguna complicación; nos vamos a VS > Nuevo Proyecto y seleccionamos la plantilla estándar de creación de PCL tal y como se muestra en la imagen,VS Standard Library

Una vez creado el proyecto, vamos a las propiedades del mismo y cambiamos el target,

propiedades_proyecto

Y ya tenemos nuestra librería cross-platform trabajando con un modelo más modular y portable que las propias PCL con una abstracción completa sin conocimiento de cuál será el destino en el que se va a usar.

Finalmente, tan solo necesitamos agregar nuestra lib a nuestro proyecto Xamarin como una referencia más y ya podemos seguir!

Principios SOLID – Principio de Abierto/Cerrado (OCP)

En una anterior entrada, explicaba los principios SOLID y, además, hice un vídeo del primero de ellos con varios ejemplos.

En esta entrada, quiero explicar el segundo de ellos y dar a conocer la importancia de entenderlo y saberlo aplicar. Este, dice así,

Principio de Abierto – Cerrado (OCP)  toda clase debe ser extensible sin requerir modificación en la implementación de sus métodos internos. Esto se consigue mediante la abstracción.

Es decir, que una entidad (clase) en nuestro desarrollo debería estar abierta a extensión pero cerrada a modificación.
Para ver esto más claro y entender OCP más rápidamente, primero, veremos una violación del principio OCP. Dentro de un entorno profesional académico dónde tenemos diferentes perfiles y cada uno de ellos tiene variables salariales en función de su antigüedad. En un inicio, lo que haremos, será implementar este conjunto de clases,

public class Teaching {
      public double VariableSalary { get; set; }
      public double Antiquity { get; set; }
}

public class VariableSalaryCalculator {
      public double VariableSalary(IList<Teaching> personal)
      {
          double salary = 0;
          foreach(Teaching p in personal)
              salary = p.Antiquity * 1.2d;
          return salary;
      }
}

Cómo podemos observar, tenemos la clase Teacher con sus propiedades y posteriormente otra para calcular el salario variable.

Aparentemente, esto, parece correcto. El problema viene, cuando pasado un tiempo, nos solicitan que el salario variable ahora es aplicable para todo el personal relacionado con la enseñanza y no únicamente para los profesores, y que además, es diferente en función de ese rol.

Si no tenemos en cuenta este principio, nuestro código sería modificado con un resultado similar al siguiente,

public class VariableSalaryCalculator
{
    public double VariableSalary(IList<Object> teachers)
    {
        double salary = 0;
        foreach (var p in teachers)
        {
            if (p is Teacher)
            {
                Teacher pItem = (Teacher)p;
                salary = pItem.Antiquity * 1.2d;
            }
            else
            {
                Administrative pItem = (Administrative)p;
                salary = pItem.Antiquity * 1.1d;
            }
        }
        return salary;
    }
}

Cómo podemos observar, esto es incorrecto. No únicamente por el principio OCP si no porque estamos escribiendo un código altamente acoplado y una cohesión baja teniendo que modificar la clase para cada rol que tengamos.

Siguiendo el ejemplo, y para aplicar el principio OCP, tenemos una solución muy sencilla; crear una clase base que represente al personal docente y extenderlo mediante nuevas clases que sobrescriban el método según el rol del personal.

public class Teaching {
      public abstract double VariableSalary { get; set; }
      public double Antiquity { get; set; }
}

public class Teacher : Teaching {
      public override double VariableSalary {
      	salary = this.Antiquity * 1.2d;
      }
}

public class Administrative : Teaching {
      public override double VariableSalary { 
	salary = this.Antiquity * 1.1d;
      }
}

Sencillo, ¿Verdad?

Esto nos asegura que nuestro sistema se podrá extender, será fácil de mantener, de hacer Unit Testing en él… y además, cumpliremos con el principio OCP.

Happy clean code :)

Novedades en C# 6.0 (II)

En mi anterior entrada hacia un anticipo de las novedades que ofrece la nueva versión de C#. Todas las novedades, recaen en una evolución hacia la simplicidad y mejora de la escritura del propio lenguaje.

Operador condición NULL

¿Cuantas veces has visto en tu aplicación un NullReferenceException por no controlar correctamente un posible valor null? Seguramente en diferentes ocasiones. En esta nueva versión se nos propone una forma simple y limpia de hacer esta validación.
Observemos cómo hacíamos la validación hasta el momento,

public string Truncate(string value, int length)
{
  string result = value;
  if (value != null)
    result = value.Substring(0, Math.Min(value.Length, length));
  return result;
}

Si no hacemos la validación del value a null, el método Substring nos devolvería una excepción NullReferenceException. Vamos a hacer exactamente lo mismo, pero con la nueva sintaxis de código,

public string Truncate(string value, int length)
{          
  return value?.Substring(0, Math.Min(value.Length, length));
}

Cómo podemos observar, nos simplifica la validación y la expresa de forma natural para que nos sea más simple y ágil tener en cuenta este tipo de validaciones que tantos quebraderos de cabeza nos dan cuándo las olvidamos.
Debemos tener en cuenta que el operador ? va a devolver siempre un tipo nullable, es decir, que si el tipo de devolución es int deberemos expresar el tipo cómo int? para que pueda aceptar el valor después de la validación con el operador o bien un null.
De hecho, si no indicamos esto, el IDE no nos dejará compilar indicando que el error es de conversión de tipos int? a int.

Mejoras en al gestión de excepciones

Tenemos dos mejoras muy importantes, la primera de ellas es el uso de operaciones async/await dentro de los bloques de excepciones y la segunda es el filtrado de excepciones.

try
{
  WebRequest webRequest = WebRequest.Create("http://contoso.com");
  WebResponse response = await webRequest.GetResponseAsync();
}
catch (WebException exception)
{
  await WriteErrorToDb(exception);
}

De forma totalmente asíncrona escribiríamos la traza en en nuestro log y seguiremos ejecutando el código mejorando así el performance de nuestra aplicación. Haciendo uso del mismo bloque de código podemos, ahora, filtrar por el tipo de excepción y actuar en consecuencia. Veamos el ejemplo,

try
{
  WebRequest webRequest = WebRequest.Create("http://contoso.com");
  WebResponse response = await webRequest.GetResponseAsync();
}
catch (WebException exception)
 when (exception.Status == WebExceptionStatus.Timeout)
  {
     await SendEmail(exception);
  }

Inicialización de diccionarios

Esta característica nos permite inicializar con valores por defecto nuestros diccionarios con mucho menos código que antes,

Dictionary<string, string> airportCode = new Dictionary<string, string>()
{
["BCN"] = "Barcelona",
["LER"] = "Lleida",
["SVQ"] = "Sevilla"
};

Constructores primarios

Esta es una fantástica feature para nuestro código, aunque a mi personalmente, me gusta más tener los constructores correctamente ubicados en regiones dentro de mi clase aunque debo reconocer que ubicar el constructor a nivel de clase es práctico y nos da, de un solo vistazo, que información precisa la clase para funcionar debidamente.

public class BasketItem(int unit, int productId, double price)
{
public string Unit{ get; set; } = unit;
public string ProductId { get; set; } = productId;
public string Price { get; set; } = price;
}

Espero disfrutéis de estas novedades y sobretodo, que las apliquéis 😉 ¡vuestro código lo agradecerá!

Novedades en C# 6.0 (I)

En mi anterior entrada, dónde hacia una introducción a Roslyn, ya citaba que no solo del compilador se trataba si no que tendríamos mejoras para que nuestro código sea mas compacto, legible y este mejor organizado.

El concepto de code smell lo podremos aplicar aquí y podremos ver cómo C# en su versión 6.0 nos ayuda mucho en ello con pequeñas pero significativas mejoras. Cómo hay varias y en bastantes quiero profundizar en detalle, he preparado una serie de entradas diferentes y en esta,me he centrado en aquellas que son más mundanas pero no por ello menos importantes.

Inicializar las propiedades

En todas nuestras clases tenemos propiedades y estas, en ocasiones, deben ser inicializadas. Con esta nueva versión, esto se puede hacer directamente al momento de declarar la propiedad y asignar su valor.

public class Employee
{
   public string First { get; set; } = "Francesc";
   public string Last { get; set; } = "Jaumot";
}

Propiedades de solo lectura

Relacionada con la anterior, podemos hacer exactamente lo mismo aunque nuestra propiedad sea solo de lectura, es decir, solo con get y sin set.

public class Employee
{
   public string First { get; } = "Francesc";
   public string Last { get; } = "Jaumot";
}

Por debajo, esto, es implícitamente declarado cómo readonly y esta se puede inicializar en el constructor de la siguiente manera,

public class Employee
{
   public string Name{ get; };

   public Employee(string first, string last)
   {
       Name = first + " " + last;
   }
}

Mejora en el uso de clases estáticas

¿Cuantas veces hemos visto Console.WriteLine(“”); o bien Math.Sqrt(2); entre muchas otras? En esta versión tan solo deberemos ocuparnos de hacer el correspondiente using y poder usar el método de dentro de la clase estática de una forma más simple.

using System.Console;
using static System.Math;

class Program
{
    static void Main(string[] args)
    {
        WriteLine(Sqrt(2));
    }
}

Interpolación en el string

Personalmente, la que más me gusta. Muchas veces deberemos devolver un string formateado, por ejemplo en una pantalla modal que nos muestre el nombre del cliente, o bien un nombre desde recursos en función del tipo de error, etc..Hasta ahora, debíamos hacer,

String.Format("¿Está seguro de eliminar el cliente {0} y número {1}?",obj.NombreCompleto, obj.IdentificadorCliente);

Ahora esto se ha simplificado y en casos dónde tengamos que concatenar varias cadenas el código, nos quedará limpio y ordenado.

return s = $"¿Está seguro de eliminar el cliente {obj.NombreCompleto} y número {obj.IdentificadorCliente}?";

Nombre del operador o clase

Este me encanta, sobretodo para los mensajes de error. Anteriormente teníamos el código así,

if (paramValue == null) throw new ArgumentNullException("paramValue");

Actualmente, lo veremos así,

if (paramValue == null) throw new ArgumentNullException(nameof(paramValue));

El operador nameof es en tiempo de compilación y no penaliza en rendimiento, ademas que nos servirá y mucho, para los que usamos INotifyPropertyChanged en MVVM.
Si alguna vez tenemos que hacer una refactorización, esto nos serviría muchísimo pues el nameof se verá afectado y dentro de la cadena, a no ser que uses alguna herramienta adicional, no aplicaría.

Recordar que algunas de estas mejoras pueden cambiar en su versión final, pero tenéis mi compromiso de que actualizaré el post a medida que tengamos más información 😉

Saludos y a por el siguiente!

¿Qué es “Roslyn” de Microsoft?

Muchos meses llevamos escuchando el nombre de “Roslyn” los que nos dedicamos a .net, pero, exactamente, ¿Qué es Roslyn?

Estoy plenamente convenido que todos los programadores de software queremos escribir el mejor código posible, participar en proyectos dónde todo este muy bien definido, donde existan las pruebas unitarias y dónde tengamos diferentes entornos para realizar nuestras pruebas cómo es debido. Los proyectos de este tipo, cuentan con arquitecturas y estándares que los programadores debemos seguir.

Existen herramientas en Visual Studio, como Code Analysis, que pueden analizar el código e informar de posibles code smells que no huelan demasiado bien. Desafortunadamente, este, no se ejecuta hasta que tenemos el código compilado y esto es poco productivo pues deberíamos saber como esta nuestro código al mismo momento que escribimos.

Una de las mejores herramientas que tenemos a nuestro abasto es nuestro compilador y este sabe analizar nuestro código, tratarlo, ejecutarlo y convertir lo que hemos escrito en algo tangible basado en nuestro código. El compilador realiza esto por nosotros pero este no tiene o no puede tener todo el conocimiento que pueden tener los programadores según el proyecto, entorno u otros. Roslyn es un conjunto de API de compilador que nos dan acceso a todos los pasos de la compilación. La siguiente imagen nos muestra una imagen de cómo actúa el compilador desde que pulsamos F6 si usamos Visual Studio.

Roslyn

Esta plataforma de compiladores para C# y Visual Basic es de código abierto y podemos acceder a él completamente en GitHub para poder ver cómo es y cómo actúa el nuevo compilador pudiendo compilar herramientas de análisis de código, entre otros aspectos mas complejos, con las API que el propio Visual Studio esta implementado.

Cuando Roslyn analiza nuestro código, devuelve un árbol de sintaxis. Este contiene todo lo relacionado con nuestro código, incluido aspectos simples como espacios, tabuladores, corchetes, paréntesis u cualquier otros símbolo escrito en la sintaxis de nuestro código.

Mediante .NET Compiler Platform Syntax Visualizer y con Visual Studio 2015 Preview instalado, podemos ver justo nuestro árbol de sintaxis si lo instalamos. Para ello deberemos ir a Ver > Otras Ventanas > Roslyn Syntax Visualizer y nos mostrará esta nueva ventana que nos analizará el código,

Roslyn_Syntax

Si nos basamos en algo tan simple cómo un “using System;” veremos, en la parte izquierda que todo comienza con una CompilationUnit del carácter 0 al 261, sigue con un UsingDirective que tiene un espacio en blanco entre using y System identificado cóm un IdentifierName con su IdentifierToken y finalmente un SemicolonToken que es un EndOfLineTrivia. Todo esto, es lo que Roslyn nos informa que va a hacer por debajo y nosotros, al ser de código abierto, lo podremos modificar.

Con Roslyn tendremos un compilador dinámico, simple y fácil de manejar con un lenguaje orientado a objetos y de alto nivel dejando de ser una caja negra para todos nosotros.

Esto no termina aquí, en próximos capítulos veremos que incorpora Roslyn en nuestro Visual Studio 2015 y en C# 6.0. Recordar que Visual Studio 2015 y todo lo que le acompaña, incluyendo Roslyn esta en Preview y que por lo tanto, puede ir evolucionando. Mantendré el post actualizado a medida que se vaya avanzando, este, y todos los que tengo preparados.

En las próximas entregas hablaré del las mejoras del entorno Visual Stuido 2015 y de C# 6.0. En la última de ellas, de ASP.NET vNext.

Happy coding! 😉