Dominar el principio DRY: Aplicación de patrones de diseño en C# para un código más limpio

Pasos y ejemplo:

1. Código inicial: La lógica para generar el ID de empleado estaba directamente en el manejador de eventos de clic de un botón.

   

2. Código refactorizado: Tim mejora el método haciéndolo más flexible. En lugar de depender de elementos específicos de la UI, el método ahora acepta firstName y lastName como parámetros y devuelve el ID generado. Este cambio permite utilizar el método en diversos contextos y elementos de la interfaz de usuario:

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   private string GenerateEmployeeID(string firstName, string lastName)
   {
     string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
     return employeeID;
   }

   A continuación, Tim demuestra cómo se llama a este método desde el evento de clic:

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   employeeIdText.Text = GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   También señala que este método puede utilizarse ahora en otras partes de la aplicación, como en el procesamiento de archivos CSV con múltiples registros de empleados, sin repetir el código.

Pasos y ejemplo:

1. Creación de la biblioteca de clases:

   • Tim en (9:47), crea un nuevo proyecto de biblioteca de clases en .NET Framework, llamándolo DRYDemoLibrary.

   • Dentro de esta biblioteca, él define una clase pública EmployeeProcessor y mueve el método GenerateEmployeeID a esta clase:

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

     public class EmployeeProcessor
     {
      public string GenerateEmployeeID(string firstName, string lastName)
      {
         string employeeID = firstName.Substring(0, 4) + lastName.Substring(0, 4) + DateTime.Now.Millisecond.ToString();
         return employeeID;
      }
     }

2. Uso de la biblioteca de clases en proyectos:

   • En sus proyectos WinForms (13:18) y WPF (14:00), Tim añade una referencia a la biblioteca de clases DRYDemoLibrary.

   • Luego reemplaza el código antiguo con llamadas al método GenerateEmployeeID desde la biblioteca de clases:

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

     EmployeeProcessor processor = new EmployeeProcessor();
     employeeIDText.Text = processor.GenerateEmployeeID(firstNameText.Text, lastNameText.Text);

   • Este enfoque elimina la redundancia, ya que el método se mantiene ahora en un único lugar. Tim demuestra que la misma biblioteca de clases puede utilizarse en distintos marcos de interfaz de usuario (WinForms y WPF) sin repetir el código.

3. Ventajas:

   • Consistencia: Al centralizar la lógica en una biblioteca de clases, Tim se asegura de que los cambios en la lógica (por ejemplo, correcciones de errores) se apliquen de manera uniforme en todos los proyectos.

   • Mantenimiento reducido: Los cambios en el método solo deben realizarse en la biblioteca de clases, lo que evita incoherencias y reduce la sobrecarga de mantenimiento.

Pasos y ejemplo:

1. Creación de una nueva solución y proyecto:

   • Tim en (17:29), comienza creando una nueva solución para una aplicación de consola, simulando un escenario en el que podrías necesitar utilizar la DRYDemoLibrary en un tipo diferente de proyecto, como un servicio de Windows o una aplicación de consola.

   • Nombra el nuevo proyecto ConsoleUI y muestra cómo configurar una aplicación de consola básica.

     class Program
     {
      static void Main(string[] args)
      {
         Console.ReadLine();
      }
     }

     class Program
     {
      static void Main(string[] args)
      {
         Console.ReadLine();
      }
     }

2. Añadir una referencia a la biblioteca de clases:

   • Tim explica cómo añadir una referencia a la DLL DRYDemoLibrary en el nuevo proyecto. Se trata de buscar el archivo DLL en la carpeta bin del proyecto de biblioteca de clases y añadirlo a la aplicación de consola.

     using DRYDemoLibrary;

     using DRYDemoLibrary;

   • Una vez añadida la referencia, Tim (19:24) utiliza la clase EmployeeProcessor de la biblioteca para generar un ID de empleado basado en la entrada del usuario.

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

     Console.WriteLine("What is your first name?");
     string firstName = Console.ReadLine();
     
     Console.WriteLine("What is your last name?");
     string lastName = Console.ReadLine();
     
     EmployeeProcessor processor = new EmployeeProcessor();
     string employeeID = processor.GenerateEmployeeID(firstName, lastName);
     
     Console.WriteLine($"Your employee ID is {employeeID}");

3. Ejecución de la aplicación de consola:

   • Tim demuestra la ejecución de la aplicación de consola para mostrar que genera correctamente el ID de empleado utilizando la biblioteca. Esto confirma que el mismo código de la biblioteca de clases puede reutilizarse en distintos proyectos.

     

4. Actualización de la DLL:

   • Tim menciona brevemente que si la DLL cambia, se puede actualizar en los proyectos que hacen referencia a ella. Señala que, aunque este vídeo no lo trata en detalle, el uso de paquetes NuGet es un enfoque recomendado para gestionar y actualizar DLL en varios proyectos.

Puntos clave:

1. Creación de un paquete NuGet:

   • En lugar de gestionar manualmente los archivos DLL, Tim sugiere crear un paquete NuGet para la biblioteca de clases. Esto implica empaquetar la DLL en un paquete NuGet y subirlo a un servidor NuGet (privado o público).

2. Paquetes de actualización:

   • Al utilizar un paquete NuGet, puede actualizar la biblioteca en todos los proyectos que hagan referencia a ella simplemente actualizando la versión del paquete. De este modo se garantiza la coherencia y se reduce el riesgo de que se produzcan desajustes entre versiones o de que falten actualizaciones.

3. Beneficios:

   • Gestión centralizada: Los paquetes NuGet proporcionan una forma centralizada de gestionar las versiones y dependencias de las bibliotecas.

   • Facilidad de actualización: La actualización de la biblioteca en varios proyectos resulta más sencilla y fiable.

   • Integración: NuGet se integra con varias herramientas y entornos de desarrollo, agilizando el proceso de gestión de dependencias de bibliotecas.

Configuración de la prueba inicial

Tim comienza ejecutando una prueba unitaria que falla debido a un error en la DLL. Destaca la importancia de las pruebas unitarias para identificar problemas, incluso cuando el código está fuera de la solución principal. El código esperaba una entrada de 4 letras, pero en su lugar Tim pasó un nombre de 3 letras que se cuela en el archivo DLL aunque no esté incluido directamente en la solución.

Refactorización de código para corregir errores

Para resolver el problema del tratamiento del nombre de pila, Tim refactoriza el código. Explica cómo se puede aplicar DRY al desarrollo mediante la creación de un nuevo proyecto de biblioteca de clases (23:50). Este enfoque garantiza que los cambios en varios objetos puedan hacerse una vez y probarse eficazmente sin repetir correcciones.

Añadir pruebas unitarias

Tim introduce una nueva clase de prueba como EmployeeProcessorTest en el proyecto de biblioteca de clases y configura pruebas unitarias utilizando XUnit. Demuestra cómo crear un método de prueba para generar ID de empleados y analiza la importancia de simular dependencias en lugar de confiar en valores reales.

Escribir un método de prueba

Tim escribe un método de prueba unitaria llamado GenerateEmployeeID_ShouldCalculate. Establece una teoría con datos en línea para probar diferentes escenarios, asegurándose de que el método devuelve los resultados esperados. También explica cómo utilizar Assert.Equal para verificar la salida.

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      // Arrange
      var processor = new EmployeeProcessor();

      // Act
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, 8);

      // Assert
      Assert.Equal(expectedStart, actualStart);
   }
}

Ejecución de la prueba unitaria

Tim hace hincapié en la importancia de simular datos dinámicos, como valores de fecha y hora, para controlar las condiciones y los resultados de las pruebas. Se analiza el reto de trabajar con cadenas dinámicas y cómo probar diferentes escenarios utilizando valores controlados. Luego él ejecuta la prueba unitaria, pero antes añade dos paquetes NuGet necesarios para ejecutar las pruebas: xunit.runner.console y xunit.runner.visualstudio.

Tras ejecutar correctamente todas las pruebas para un dato en línea, el resultado es el siguiente:

Ahora, en (31:30), Tim añadió otro dato en línea y cambió el segundo parámetro de la subcadena a expectedStart.Length:

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

public class EmployeeProcessorTest
{
   [Theory]
   [InlineData("Timothy", "Corey", "TimoCore")]
   [InlineData("Tim", "Corey", "TimCore")]
   public void GenerateEmployeeID_ShouldCalculate(string firstName, string lastName, string expectedStart)
   {
      var processor = new EmployeeProcessor();
      var actualStart = processor.GenerateEmployeeID(firstName, lastName).Substring(0, expectedStart.Length);
      Assert.Equal(expectedStart, actualStart);
   }
}

Después de ejecutar la prueba unitaria de nuevo en (32:05), con la segunda teoría la prueba se rompió:

Mejorando el código con métodos privados

Para adherirse a DRY, Tim refactoriza aún más el código creando un método privado GetPartOfName en la clase actual EmployeeProcessor bajo DRYDemoLibrary. Este método se encarga de la extracción de partes de un nombre, lo que mejora la reutilización y legibilidad del código. Tim realizó los siguientes cambios:

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

public string GenerateEmployeeID(string firstName, string lastName)
{
   string employeeID = $@"{GetPartOfName(firstName, 4)}{GetPartOfName(lastName, 4)}{DateTime.Now.Millisecond.ToString()}";
   return employeeID;
}

private string GetPartOfName(string name, int numberOfCharacters)
{
   string output = name;

   if (name.Length > numberOfCharacters)
   {
      output = name.Substring(0, numberOfCharacters);
   }

   return output;
}

Actualización de pruebas unitarias

Tim actualiza las pruebas unitarias para reflejar los cambios en el código, como la modificación de la longitud esperada de las subcadenas. Explica cómo la ejecución de estas pruebas ayuda a identificar rápidamente los problemas y a validar que el código cumple los nuevos requisitos. Tim añade nuevas teorías y luego ejecuta las pruebas unitarias para verificar si los resultados son los esperados:

Creación de una biblioteca .NET Standard

Reducir la repetición en el desarrollo

Tim Corey hace hincapié en que, al adoptar una biblioteca .NET Standard, se minimiza la repetición de código no sólo en la base de código, sino también en el proceso de desarrollo. En lugar de duplicar el código en diferentes proyectos de plataformas específicas, se centraliza en una única biblioteca que funciona en múltiples entornos.

Beneficios:

• Código base unificado: Una base de código para varias plataformas reduce el esfuerzo necesario para mantener y actualizar su código.
• Pruebas simplificadas: Con una biblioteca .NET Standard, puede escribir pruebas unitarias una vez y asegurarse de que se aplican a todas las plataformas compatibles.

Pruebas y depuración: Tim presenta las pruebas unitarias como una forma de reducir aún más el esfuerzo y la repetición. Las pruebas automatizadas verifican la corrección del código sin necesidad de probar manualmente cada iteración de la aplicación.