En nuestra constante búsqueda de excelencia como desarrolladores, nos encontramos con faros de guía que iluminan nuestro camino hacia el código limpio. Hoy, nos zambulliremos en el océano de los Principios SOLID, esas estrellas polares en el diseño de software que prometen llevar nuestras habilidades de programación a nuevos horizontes. Estos principios no son meras reglas, sino los cimientos sobre los que podemos construir software robusto, mantenible y flexible. Acompáñame en este viaje para desentrañar cómo estos principios pueden transformar tu código de bueno a excepcional.

Resumen

• S: Principio de Responsabilidad Única: Imagina que cada pieza de tu código es un instrumento en una orquesta. Este principio sugiere que cada instrumento (clase) debe tocar solo una melodía (tarea). La simplicidad y singularidad en sus funciones aseguran una sinfonía armoniosa.

• O: Principio de Abierto/Cerrado: Este principio nos enseña la magia de la evolución sin destrucción. Tus clases deben ser como los legos, diseñadas para construir y expandir, pero sin necesidad de cambiar las piezas existentes.

• L: Principio de Sustitución de Liskov: En un baile de máscaras, puedes cambiar de disfraz y seguir siendo tú mismo. De manera similar, los objetos de una clase deben poder ser reemplazados por objetos de sus subclases sin alterar el espectáculo.

• I: Principio de Segregación de la Interfaz: No todos necesitan ser políglotas. Este principio aboga por interfaces específicas para cada cliente, evitando que se vean obligados a depender de lo que no usan.

• D: Principio de Inversión de Dependencias: En un juego de equipo, confía en roles, no en jugadores. Este principio propone depender de abstracciones, no de implementaciones concretas, fomentando la flexibilidad y la desacoplación.

Problemas que podemos solucionar

• SRP: Como si limpiáramos nuestro escritorio, este principio nos ayuda a organizar nuestro código para que cada clase tenga una única responsabilidad, evitando un desorden caótico y mejorando la mantenibilidad.

• OCP: Nos permite agregar nuevas funcionalidades como si añadiéramos un nuevo libro a nuestra estantería sin tener que reconstruir toda la estantería.

• LSP: Asegura que nuestro código sea como un juego de sustitución, donde podemos intercambiar elementos sin romper el juego, manteniendo la integridad del sistema.

• ISP: Evita la sobrecarga de información, como cuando llevas una mochila con solo lo necesario, haciéndola más ligera y funcional.

• DIP: Promueve una estructura donde las piezas son intercambiables y no dependen unas de otras, como en un equipo donde cada miembro puede jugar su rol independientemente.

Ventajas de aplicarlos

Estos principios no solo embellecen nuestro código, sino que lo fortalecen desde dentro, asegurando que sea fácil de leer, mantener y ampliar. Nos permiten ser artesanos del software, cuidando cada detalle para que nuestra obra pueda adaptarse y crecer con gracia a lo largo del tiempo.

Ejemplo práctico

S: Principio de Responsabilidad Única (SRP)

Caso de Uso: Separación de la lógica de cálculo de tarifas y la notificación al usuario.

• Escenario: En una aplicación de taxis, una clase gestiona tanto la lógica de cálculo de tarifas como la notificación a los usuarios. Para adherirnos al SRP, dividiremos esta responsabilidad en dos clases separadas.

• Aplicación: Implementamos una clase FareCalculator exclusivamente para calcular las tarifas de los viajes, y una clase UserNotifier para gestionar las notificaciones a los usuarios. Esto asegura que si la lógica de cálculo de tarifas cambia, no afecta el sistema de notificaciones, y viceversa.

public class FareCalculator
{
    public decimal CalculateFare(double distance, int timeOfDay)
    {
        decimal baseFare = 2.50m; // Tarifa base
        decimal distanceFare = (decimal)distance * 1.25m; // Tarifa por distancia
        decimal timeFare = (timeOfDay < 22 && timeOfDay > 6) ? 0 : 1.5m; // Tarifa nocturna

        return baseFare + distanceFare + timeFare;
    }
}

public class UserNotifier
{
    public void NotifyUser(string message)
    {
        Console.WriteLine(message);
    }
}

var fareCalculator = new FareCalculator();
var userNotifier = new UserNotifier();

double distance = 5.0; // Distancia en kilómetros
int timeOfDay = 15; // Hora del día en formato 24h

decimal fare = fareCalculator.CalculateFare(distance, timeOfDay);
userNotifier.NotifyUser($"The estimated cost of your trip is: ${fare}");

O: Principio de Abierto/Cerrado (OCP)

Caso de Uso: Añadir nuevas promociones sin modificar el código existente.

• Escenario: Tenemos una clase de sistema de promociones que debería poder extenderse con nuevas promociones sin modificar su código existente.

• Aplicación: Creamos una clase base Promotion que puede ser extendida por diferentes tipos de promociones, como HolidayPromotion. Al introducir una nueva promoción, simplemente añadimos una nueva clase que herede de Promotion, sin necesidad de modificar el código existente.

public abstract class Promotion
{
    public abstract decimal ApplyPromotion(decimal fare);
}

public class NoPromotion : Promotion
{
    public override decimal ApplyPromotion(decimal fare)
    {
        return fare; // No aplica ninguna promoción
    }
}

public class HolidayPromotion : Promotion
{
    public override decimal ApplyPromotion(decimal fare)
    {
        return fare * 0.9m; // 10% de descuento
    }
}

public class FareWithPromotion
{
    private readonly Promotion _promotion;

    public FareWithPromotion(Promotion promotion)
    {
        _promotion = promotion;
    }

    public decimal CalculateFareWithPromotion(decimal fare)
    {
        return _promotion.ApplyPromotion(fare);
    }
}

var noPromotion = new NoPromotion();
var holidayPromotion = new HolidayPromotion();

var fareWithPromotion = new FareWithPromotion(holidayPromotion);

decimal originalFare = 10.00m; // Tarifa original sin promoción
decimal discountedFare = fareWithPromotion.CalculateFareWithPromotion(originalFare);

Console.WriteLine($"Discounted rate: ${discountedFare}");

L: Principio de Sustitución de Liskov (LSP)

Caso de Uso: Manejar diferentes tipos de vehículos en el sistema de reservaciones.

• Escenario: Un sistema de gestión de vehículos donde cada tipo de vehículo (como taxi o limusina) se comporta de manera diferente al ser reservado.

• Aplicación: Todas las clases de vehículos, como Taxi y Limousine, heredan de una clase base Vehicle. Esto permite que el sistema de reservaciones trate a todos los vehículos de manera uniforme, facilitando la adición de nuevos tipos de vehículos sin alterar la lógica de reservación.

public abstract class Vehicle
{
    public abstract void Reserve();
}

public class Taxi : Vehicle
{
    public override void Reserve()
    {
        Console.WriteLine("Taxi reserved");
    }
}

public class Limousine : Vehicle
{
    public override void Reserve()
    {
        Console.WriteLine("Limousine reserved with extra features");
    }
}

public class VehicleReservation
{
    public void ReserveVehicle(Vehicle vehicle)
    {
        vehicle.Reserve();
    }
}

var taxi = new Taxi();
var limousine = new Limousine();
var vehicleReservation = new VehicleReservation();

// Reservar un taxi
vehicleReservation.ReserveVehicle(taxi);

// Reservar una limusina
vehicleReservation.ReserveVehicle(limousine);

I: Principio de Segregación de la Interfaz (ISP)

Caso de Uso: Diferenciar las operaciones disponibles para conductores y pasajeros.

• Escenario: Un sistema donde diferentes tipos de usuarios (conductor y pasajero) tienen diferentes interfaces para interactuar.

• Aplicación: Implementamos interfaces separadas para conductores (IDriverService) y pasajeros (ICustomerService), asegurando que cada usuario interactúe solo con las operaciones que le corresponden, sin ser forzado a implementar métodos que no utiliza.

public interface ICustomerService
{
    void RequestRide(string destination);
}

public interface IDriverService
{
    void AcceptRideRequest();
    void CompleteRide();
}

public class Passenger : ICustomerService
{
    public void RequestRide(string destination)
    {
        Console.WriteLine($"Ride requested to {destination}");
    }
}

public class Driver : IDriverService
{
    public void AcceptRideRequest()
    {
        Console.WriteLine("Ride request accepted");
    }

    public void CompleteRide()
    {
        Console.WriteLine("Ride completed");
    }
}

var passenger = new Passenger();
var driver = new Driver();

// Pasajero solicita un viaje
passenger.RequestRide("International Airport");

// Conductor acepta y completa el viaje
driver.AcceptRideRequest();
driver.CompleteRide();

D: Principio de Inversión de Dependencias (DIP)

Caso de Uso: Facilitar la comunicación entre usuarios y conductores mediante diferentes canales.

• Escenario: Un servicio de notificaciones donde la lógica de envío de notificaciones puede variar (por ejemplo, a través de SMS o email), y debería ser fácilmente extendible.

• Aplicación: Utilizamos una interfaz INotificationService para abstraer el envío de notificaciones (como SMS o email). Esto permite cambiar o añadir servicios de notificación sin modificar el código que depende de esta abstracción, como el NotificationManager.

public interface INotificationService
{
    void SendNotification(string message);
}

public class EmailNotificationService : INotificationService
{
    public void SendNotification(string message)
    {
        Console.WriteLine($"Sending email: {message}");
    }
}

public class SmsNotificationService : INotificationService
{
    public void SendNotification(string message)
    {
        Console.WriteLine($"Sending SMS: {message}");
    }
}

public class NotificationManager
{
    private readonly INotificationService _notificationService;

    public NotificationManager(INotificationService notificationService)
    {
        _notificationService = notificationService;
    }

    public void NotifyUser(string message)
    {
        _notificationService.SendNotification(message);
    }
}

var emailService = new EmailNotificationService();
var smsService = new SmsNotificationService();

var notificationManager = new NotificationManager(emailService); // Usar servicio de email
notificationManager.NotifyUser("Your taxi is on the way.");

notificationManager = new NotificationManager(smsService); // Cambiar a servicio de SMS sin modificar NotificationManager
notificationManager.NotifyUser("Your taxi has arrived.");

Recomendaciones

• Integración Gradual: No intentes aplicar todos los principios de golpe. Introdúcelos paulatinamente en tu código.

• Equilibrio: Mantén un balance. Aplica los principios donde aporten valor sin sobrecomplicar tu diseño.

• Reflexión: Tras cada iteración, toma un momento para reflexionar sobre cómo estos principios han impactado en tu trabajo.

Conclusión

Los Principios SOLID no son solo teoría; son la esencia de un código bien diseñado. Al igual que en nuestra previa exploración de las funciones efectivas, estos principios son herramientas en nuestro arsenal para lidiar con la complejidad y el cambio. Adoptarlos es comprometernos con la mejora continua, buscando no solo cumplir con nuestros objetivos actuales, sino también prepararnos para los desafíos futuros. En nuestro viaje como desarrolladores, permiten que nuestro codebase no solo sobreviva, sino que prospere, adaptándose y evolucionando. Así que, mientras avanzas, recuerda que cada línea de código cuenta y que, con los Principios SOLID como guía, estás un paso más cerca de la maestría en ingeniería de software.

Happy Coding 😸

La Obsesión Primitiva se refiere al uso generalizado de tipos de datos primitivos (como int, string, bool) en sistemas de software para representar conceptos de dominio complejos. Aunque inicialmente parece conveniente, este enfoque conduce a problemas como falta de expresividad, aumento de la complejidad y dificultades en el mantenimiento.

Cuándo y por qué superar la Obsesión Primitiva

• Cuándo: Es crucial superarla cuando la representación de conceptos complejos del dominio se vuelve confusa y el código es difícil de mantener.

• Por qué: Superar esta práctica mejora la expresividad del código, facilita la validación y reduce la duplicación, resultando en un software más robusto y fácil de mantener.

Técnicas para abordar la Obsesión Primitiva

Antes de profundizar en la implementación específica, me gustaría establecer una base sólida mediante la introducción de dos clases útiles: Error y Result. Estas clases nos permitirán manejar de manera eficiente y coherente los resultados y errores a lo largo de nuestra aplicación, asegurando que el código sea robusto y fácil de mantener.

Clase Error

public record Error(string Code, string Name)
{
    public static Error None = new(string.Empty, string.Empty);

    public static Error NullValue = new("Error.NullValue", "Null value was provided");
}

Se utiliza para encapsular información relacionada con errores que pueden ocurrir durante la ejecución de nuestro programa. Esta clase es un registro, lo que significa que es inmutable y su estado no cambia una vez que se ha creado una instancia.

• Code: Un identificador único para el tipo de error.

• Message: Un mensaje descriptivo asociado con el error.

La clase también incluye errores predefinidos como None (que representa la ausencia de un error) y NullValue (que se utiliza cuando se proporciona un valor nulo donde no se espera).

Clase Result

Es fundamental para el manejo de operaciones que pueden tener éxito o fallar. Esta clase encapsula el resultado de una operación, junto con cualquier error que pueda haber ocurrido.

public class Result
{
    protected internal Result(bool isSuccess, Error error)
    {
        if (isSuccess && error != Error.None)
        {
            throw new InvalidOperationException();
        }

        if (!isSuccess && error == Error.None)
        {
            throw new InvalidOperationException();
        }

        IsSuccess = isSuccess;
        Error = error;
    }

    public bool IsSuccess { get; }

    public bool IsFailure => !IsSuccess;

    public Error Error { get; }

    public static Result Success() => new(true, Error.None);

    public static Result Failure(Error error) => new(false, error);

    public static Result<TValue> Success<TValue>(TValue value) => new(value, true, Error.None);

    public static Result<TValue> Failure<TValue>(Error error) => new(default, false, error);

    public static Result<TValue> Create<TValue>(TValue? value) =>
        value is not null ? Success(value) : Failure<TValue>(Error.NullValue);
}

public class Result<TValue> : Result
{
    private readonly TValue? _value;

    protected internal Result(TValue? value, bool isSuccess, Error error)
        : base(isSuccess, error)
    {
        _value = value;
    }

    [NotNull]
    public TValue Value => IsSuccess
        ? _value!
        : throw new InvalidOperationException("The value of a failure result can not be accessed.");

    public static implicit operator Result<TValue>(TValue? value) => Create(value);
}

Constructor Protegido Interno:

El constructor de la clase Result es protegido e interno, lo que significa que sólo puede ser llamado desde dentro de la clase o desde clases derivadas. Acepta dos parámetros: isSuccess (un booleano que indica si la operación fue exitosa) y error (un objeto Error que contiene información sobre un error si ocurrió).

Validaciones en el Constructor:

Dentro del constructor, hay validaciones para asegurarse de que el estado del objeto sea coherente: si isSuccess es true, entonces error debe ser Error.None, y si isSuccess es false, entonces error no debe ser Error.None. Si estas condiciones no se cumplen, se lanza una excepción InvalidOperationException.

Propiedades:

• IsSuccess: Un valor booleano que indica si la operación fue exitosa.

• IsFailure: Un valor booleano derivado que indica si la operación falló.

• Error: Un objeto de tipo Error que contiene detalles del error si la operación falló.

Métodos Estáticos de Fábrica:

• Success(): Crea un resultado exitoso sin valor.

• Failure(error): Crea un resultado fallido con un error específico.

• Success<TValue>(value): Crea un resultado exitoso con un valor de tipo TValue.

• Failure<TValue>(error): Crea un resultado fallido de tipo TValue.

• Create<TValue>(value): Crea un resultado basado en si value es nulo o no.

Clase Genérica Result<TValue> :

• Esta clase derivada permite manejar resultados que incluyen un valor de tipo TValue.

• Tiene un campo privado _value para almacenar el valor.

• El constructor de esta clase derivada también verifica la consistencia del resultado.

• La propiedad Value devuelve el valor si IsSuccess es true; de lo contrario, lanza una excepción, asegurando que los valores de los resultados fallidos no se puedan acceder.

Conversión Implícita:

Hay un operador de conversión implícita que permite convertir un valor de tipo TValue en un objeto Result<TValue>. Esto simplifica la creación de resultados exitosos.

Esta clase Result ofrece métodos estáticos para crear instancias que representen éxitos (Success) o fracasos (Failure). También se proporciona una sobrecarga genérica de Result para operaciones que devuelven un valor.

El uso de estas clases en conjunto proporciona un marco claro y consistente para manejar los resultados y errores en una aplicación, lo que facilita la escritura de código más limpio y mantenible.

Implementación

Crea clases o estructuras personalizadas para encapsular datos primitivos y comportamientos relacionados, mejorando la expresividad y conteniendo la lógica de validación.

Ahora si, veamos como podemos implementar las diferentes técnicas.

Técnica #1: Con clase abstracta

Clase Abstracta ValueObject:

ValueObject es una clase abstracta, lo que significa que no puede ser instanciada por sí misma. En su lugar, está diseñada para ser heredada por otras clases que representan objetos de valor.

public abstract class ValueObject : IEquatable<ValueObject>
{
    public abstract IEnumerable<object> GetAtomicValues();

    public bool Equals(ValueObject? other)
    {
        return other is not null && ValuesAreEqual(other);
    }

    public override bool Equals(object? obj)
    {
        return obj is ValueObject other && ValuesAreEqual(other);
    }

    public override int GetHashCode()
    {
        return GetAtomicValues().Aggregate(default(int), HashCode.Combine);
    }

    private bool ValuesAreEqual(ValueObject other)
    {
        return GetAtomicValues().SequenceEqual(other.GetAtomicValues());
    }
}

Interfaz IEquatable<ValueObject> :

La clase implementa la interfaz IEquatable<ValueObject>, lo que significa que proporciona una implementación personalizada para determinar si dos objetos de valor son iguales.

Método Abstracto GetAtomicValues :

• Este método abstracto debe ser implementado por las clases derivadas para devolver los valores individuales (atómicos) que componen el objeto de valor.

• Estos valores son los que se utilizan para determinar la igualdad entre dos instancias.

Método Equals (Sobrecarga de IEquatable<ValueObject>):

• Este método determina la igualdad con otro ValueObject.

• Utiliza ValuesAreEqual para comparar los valores atómicos de ambos objetos.

• Devuelve false si el otro objeto es nulo.

Método Equals (Sobrecarga de Object):

• Esta sobrecarga asegura que la igualdad se maneje correctamente cuando el objeto se trata como un Object.

• Realiza una comprobación de tipo antes de llamar a ValuesAreEqual.

Método GetHashCode :

• Sobrescribe el método GetHashCode de Object.

• Proporciona un código hash que se basa en los valores atómicos del objeto, utilizando Aggregate y HashCode.Combine.

• Este código hash es consistente con la definición de igualdad de la clase.

Método Privado ValuesAreEqual :

• Compara los valores atómicos de this y otro ValueObject para determinar si son iguales.

• Utiliza SequenceEqual para comparar las secuencias de valores atómicos.

En resumen, ValueObject es una clase base diseñada para proporcionar una implementación consistente y robusta de igualdad basada en valores atómicos para objetos de valor. Esta clase es esencial para garantizar que la igualdad de objetos en tu dominio se base en sus valores y no en sus referencias de memoria, lo cual es un aspecto clave en el diseño orientado al dominio y en la creación de modelos de dominio ricos y expresivos.

Clase EmailAddress:

Esta es una implementación de ejemplo para entender como podemos utilizar nuestra clase abstracta de ValueObject.

public sealed class EmailAddress : ValueObject
{
    public const int MaxLength = 100; // Longitud máxima típica para un email

    private EmailAddress(string value)
    {
        Value = value;
    }

    public string Value { get; }

    public static Result<EmailAddress> Create(string email)
    {
        if (string.IsNullOrWhiteSpace(email))
        {
            return Result.Failure<EmailAddress>(new Error(
                "EmailAddress.Empty",
                "Email address is empty."));
        }

        if (email.Length > MaxLength)
        {
            return Result.Failure<EmailAddress>(new Error(
                "EmailAddress.TooLong",
                "Email address is too long."));
        }

        if (!IsValidEmail(email))
        {
            return Result.Failure<EmailAddress>(new Error(
                "EmailAddress.Invalid",
                "Email address is not valid."));
        }

        return new EmailAddress(email);
    }

    public override IEnumerable<object> GetAtomicValues()
    {
        yield return Value;
    }

    private static bool IsValidEmail(string email)
    {
        // Patrón de regex para validar el correo electrónico
        var emailRegex = @"^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$";
        var regex = new Regex(emailRegex, RegexOptions.IgnoreCase);

        return regex.IsMatch(email);
    }
}

Herencia de ValueObject :

Al heredar de ValueObject, EmailAddress obtiene una implementación de igualdad basada en el valor, esencial para objetos de valor como una dirección de correo electrónico.

Propiedad MaxLength :

Define una constante MaxLength para establecer la longitud máxima permitida para una dirección de correo electrónico, lo que ayuda a mantener la validez y la integridad de los datos.

Constructor Privado:

El constructor es privado y solo se llama dentro de la clase, lo que garantiza que las instancias de EmailAddress solo puedan ser creadas a través del método Create, asegurando que todas las direcciones de correo electrónico pasen por las validaciones necesarias.

Propiedad Value :

Almacena el valor de la dirección de correo electrónico, manteniendo la inmutabilidad del objeto después de su creación.

Método Estático Create :

• Proporciona un punto de creación controlado para instancias de EmailAddress.

• Realiza varias validaciones: verifica que el correo electrónico no esté vacío, que no exceda la longitud máxima y que sea válido según una expresión regular.

• Devuelve un objeto Result<EmailAddress>, permitiendo un manejo elegante de errores o un éxito en la creación del objeto.

Sobrescritura de GetAtomicValues :

Implementa el método abstracto heredado de ValueObject, devolviendo los componentes que definen la igualdad del objeto, en este caso, el valor de la dirección de correo electrónico.

Método Privado Estático IsValidEmail :

• Utiliza una expresión regular para validar el formato de la dirección de correo electrónico.

• Proporciona una verificación de formato adicional y esencial para garantizar la validez del correo electrónico.

En resumen, EmailAddress encapsula de manera efectiva las características y validaciones necesarias para manejar direcciones de correo electrónico en una aplicación. Al integrarse con ValueObject y Result, esta clase no solo garantiza la validez y la integridad de las direcciones de correo electrónico sino que también facilita la gestión de errores y el mantenimiento de la inmutabilidad de los objetos.

Ejemplo de uso de la ténica #1

public class User
{
    // Constructor(es)

    // Otras propiedades

    public Email Email { get; set; }

    // Métodos
}

var user = new User();
var email = EmailAddress.Create("khanakat@email.com");

if (email.IsFailure)
{
    Console.WriteLine(email.Error);
    return;
}

user.Email = email.Value;
Console.WriteLine(user.Email.Value);

Técnica #2: Con clase record

Utiliza Value Objects para representar conceptos del dominio definidos por sus atributos en lugar de su identidad. Estos son inmutables y su igualdad se basa en el valor de sus propiedades.

Por ejemplo podemos utilizar una clase record la cual ya contiene la implementación de IEquatable por ende ya no es necesario implementar una clase abstracta.
De una manera muy sencilla podría ser de la siguiente manera:

public sealed record FirstName(string Value);

Pero si quisieramos que nuestro ValueObject sea mas robusto podriamos hacerlo de la siguiente manera:

public sealed record FirstName
{
    public const int MaxLength = 50;

    private FirstName(string value)
    {
        Value = value;
    }

    public string Value { get; }

    public static Result<FirstName> Create(string firstName)
    {
        if (string.IsNullOrWhiteSpace(firstName))
        {
            return Result.Failure<FirstName>(new Error(
                "FirstName.Empty",
                "First name is empty."));
        }

        if (firstName.Length > MaxLength)
        {
            return Result.Failure<FirstName>(new Error(
                "FirstName.TooLong",
                "First name is too long."));
        }

        return new FirstName(firstName);
    }
}

Uso de record :

Al ser un record, FirstName es inmutable por diseño. Los registros en C# son tipos de referencia que proporcionan valor semántico de igualdad y son ideales para modelar objetos inmutables.

Constante MaxLength :

La constante MaxLength define la longitud máxima permitida para un nombre, lo que ayuda a mantener la validez y consistencia de los datos.

Constructor:

El constructor es privado y establece el valor del nombre. Se espera que las instancias sean creadas mediante el método estático Create.

Propiedad Value :

Almacena el valor del nombre de pila, garantizando que una vez que se crea una instancia de FirstName, su valor no puede ser modificado.

Método Estático Create :

• Este método es el punto de creación recomendado para instancias de FirstName.

• Realiza validaciones para asegurarse de que el nombre de pila proporcionado no esté vacío y no exceda la longitud máxima establecida.

• En caso de error (nombre vacío o demasiado largo), devuelve un objeto Result<FirstName> indicando el fallo, junto con un mensaje de error apropiado.

• Si las validaciones son exitosas, devuelve una nueva instancia de FirstName.

En resumen el diseño de la clase FirstName garantiza que todos los nombres de pila manejados por tu sistema cumplan con las reglas definidas, evitando estados inválidos y facilitando el manejo de errores. Al utilizar un enfoque basado en registros y métodos estáticos para la creación y validación, esta clase promueve un uso seguro y coherente de los nombres de pila en toda tu aplicación.

Ejemplo de uso de la ténica #2

public class User
{
    // Constructor(es)

    // Otras propiedades

    public FirstName FirstName { get; set; }

    // Métodos
}

var user = new User();
var firstName = FirstName.Create("Fernando");

if (firstName.IsFailure)
{
    Console.WriteLine(firstName.Error);
    return;
}

user.FirstName = firstName.Value;
Console.WriteLine(user.FirstName.Value);

Conclusión

Conclusión: La Obsesión Primitiva y el Arte de la Abstracción Efectiva

Para concluir, es esencial recordar que superar la Obsesión Primitiva no es solo una cuestión de aplicar técnicas; es un aspecto fundamental en la evolución de nuestras habilidades como desarrolladores. Cada vez que elegimos representar un concepto complejo del dominio de manera más abstracta y significativa, no solo estamos escribiendo código más limpio y mantenible, sino también perfeccionando nuestro arte.

Este artículo es solo un paso en el viaje hacia una mejor comprensión y aplicación de prácticas de desarrollo de software eficaces. Espero que este enfoque en la Obsesión Primitiva te haya inspirado a reflexionar sobre cómo representas los conceptos en tus proyectos y a buscar constantemente formas de mejorar tu código.

Nos vemos en futuros artículos donde continuaremos desglosando los principios del diseño de software limpio y su aplicación práctica en el mundo del desarrollo. ¡Hasta entonces, feliz codificación y recuerda que cada línea de código cuenta!

😸 Happy Coding!

La importancia de las funciones bien escritas no puede subestimarse

Son la esencia de nuestro código, y su calidad afecta directamente la claridad, eficiencia y mantenibilidad de nuestro software. Imaginen funciones como los ladrillos de una casa; si están bien hechos y colocados con cuidado, la casa será sólida y duradera. De lo contrario, podríamos enfrentarnos a una estructura débil y problemática.

Ahora, hablemos de algunos principios clave que Uncle Bob nos enseña en su libro "Clean Code" y cómo podemos aplicarlos a nuestras funciones:

1. Mantener las funciones cortas y enfocadas: Una función debería hacer una cosa y hacerla bien. Si te encuentras escribiendo una función que parece querer hacer demasiado, probablemente necesite ser dividida en funciones más pequeñas y específicas.

    // ❌ Incorrecto
    void AddToppingAndCalculatePrice(Pizza pizza, string topping, List<string> priceList) 
    {
        pizza.Toppings.Add(topping);
        pizza.Price += priceList.Find(p => p.Topping == topping).Price;
        // Más código para actualizar inventario, etc.
    }
   

     // ✔️ Correcto
    void AddTopping(Pizza pizza, string topping) 
    {
        pizza.Toppings.Add(topping);
    }
   

   En el primer bloque de código, además de añadir el ingrediente, calcula el precio y potencialmente realiza otras tareas. Esto hace que la función sea más difícil de entender y mantener. En cambio en el segundo bloque de código la función hace una sola cosa: añade un ingrediente a la pizza.

2. Nombres descriptivos: El nombre de una función debe indicar qué hace. Si tienes dificultades para nombrar una función, podría ser una señal de que no tiene un propósito claro.

    // ❌ Incorrecto
    void PrepareFood(Pizza pizza) 
    {
        // Lógica para hornear la pizza
    }
   

    // ✔️ Correcto
    void BakePizza(Pizza pizza) 
    {
        // Lógica para hornear la pizza
    }
   

   'BakePizza' describe claramente lo que hace la función: hornear una pizza. 'PrepareFood', por otro lado, es vago y no indica qué tipo de preparación de alimentos se está realizando.

3. Evitar argumentos excesivos: Cuantos menos argumentos tenga una función, mejor. Demasiados argumentos pueden hacer que la función sea difícil de entender y usar.

    // ❌ Incorrecto
    void UpdatePizza(Pizza pizza, PizzaSize newSize, string newCrust, int newTemperature, bool isGlutenFree) 
    {
        // Actualizar múltiples propiedades de la pizza
    }
   

    // ✔️ Correcto
    void UpdatePizzaSize(Pizza pizza, PizzaSize newSize) 
    {
        pizza.Size = newSize;
    }
   

   En el primer bloque de código, la función intenta hacer demasiado, actualizando múltiples aspectos de la pizza, lo que la hace menos clara y más difícil de usar. En cambio en el segundo bloque de código, la función tiene un propósito claro: actualizar el tamaño de la pizza.

4. Minimizar efectos secundarios: Una función ideal no debería tener efectos secundarios inesperados. Debería realizar su tarea y no modificar el estado de otros elementos del programa sin una buena razón.

    // ❌ Incorrecto
    void CalculateAndUpdateTotalPrice(Pizza pizza) 
    {
        pizza.TotalPrice = pizza.BasePrice;
        foreach (var topping in pizza.Toppings) {
            pizza.TotalPrice += ToppingPrices[topping];
        }
        // Actualizar la propiedad TotalPrice de la pizza
    }
   

    // ✔️ Correcto
    decimal CalculateTotalPrice(Pizza pizza) 
    {
        decimal totalPrice = pizza.BasePrice;
        foreach (var topping in pizza.Toppings) {
            totalPrice += ToppingPrices[topping];
        }
        return totalPrice;
    }
   

   En el primer bloque de código, además de calcular el precio, actualiza la propiedad de la pizza, lo que es un efecto secundario que puede llevar a errores si no se maneja correctamente. En cambio en el segundo bloque de código, solo calcula el precio total y lo devuelve, sin modificar el estado de la pizza.

5. Pruebas unitarias: Cada función debe ser probada. Las pruebas unitarias no solo ayudan a garantizar que tu función hace lo que debe hacer, sino que también te obligan a escribir funciones más limpias y desacopladas.

    // ❌ Incorrecto
    [Test]
    public void AddTopping_ShouldDoMultipleThings() 
    {
        var pizza = new Pizza();
        AddToppingAndCalculatePrice(pizza, "Pepperoni", priceList);
        // Intentar probar múltiples comportamientos a la vez
    }
   

    // ✔️ Correcto
    [Test]
    public void AddTopping_ShouldAddToppingToPizza() 
    {
        var pizza = new Pizza();
        AddTopping(pizza, "Pepperoni");
        Assert.Contains("Pepperoni", pizza.Toppings);
    }
   

   En el primer bloque de código, la prueba es menos clara y trata de probar múltiples comportamientos a la vez, lo que puede llevar a pruebas menos confiables y más difíciles de mantener. En cambio en el segundo bloque de código, la prueba unitaria es clara y se enfoca en un solo comportamiento: añadir un ingrediente.

Ejemplo práctico

En este ejemplo, vamos a explorar un escenario común en una aplicación para gestionar pedidos en una pizzería. El código estará dividido en varias partes clave, cada una enfocada en un aspecto específico del proceso de pedido de pizzas.

Escenario General:

Imaginemos una pequeña pizzería que ofrece un servicio de pedidos en línea. Los clientes pueden elegir el tamaño de la pizza, agregar ingredientes adicionales y realizar su pedido a través de la aplicación. La aplicación debe ser capaz de gestionar los pedidos, calcular el precio total y mantener la información del cliente.

Partes del Código:

1. Definición de Clases: Crearemos clases básicas para representar los componentes esenciales de la pizzería: pizzas, pedidos y clientes. Estas clases servirán como la base de nuestra aplicación.

2. Creación y Manejo de Pedidos: Desarrollaremos una clase de servicio que maneje la lógica de negocio, como la creación de pedidos y la construcción de pizzas con sus respectivos ingredientes.

3. Interacción del Usuario con el Servicio: Finalmente, veremos cómo un usuario (en este caso, simulado por el método Main) interactúa con el servicio de la pizzería para hacer un pedido, añadir pizzas y visualizar el resumen del pedido.

Cada bloque de código estará acompañado de una descripción para entender mejor su función y cómo se relaciona con los principios de Clean Code. Este enfoque modular y descriptivo nos ayudará a visualizar cómo cada parte contribuye al funcionamiento general de la aplicación de la pizzería.

Ahora, veamos cada parte en detalle.

1. Definición de Clases

Primero, definiremos algunas clases básicas para representar los elementos de nuestra pizzería: Pizza, Order, y Customer.

public enum PizzaSize { Small, Medium, Large }

public class Pizza 
{
    public PizzaSize Size { get; set; }
    public List<string> Toppings { get; private set; } = new List<string>();

    public void AddTopping(string topping) => Toppings.Add(topping);
}

public class Customer 
{
    public string Name { get; set; }
    public string Address { get; set; }
}

public class Order 
{
    public Customer Customer { get; set; }
    public List<Pizza> Pizzas { get; private set; } = new List<Pizza>();
    public decimal TotalPrice { get; private set; }

    public void AddPizza(Pizza pizza) 
    {
        Pizzas.Add(pizza);
        CalculateTotalPrice();
    }

    private void CalculateTotalPrice() 
    {
        // Cálculo del precio total
    }
}

Aquí, cada clase tiene una responsabilidad clara. La clase Pizza se encarga de todo lo relacionado con una pizza individual, como su tamaño y los ingredientes. La clase Customer maneja la información del cliente. La clase Order gestiona un pedido, incluyendo las pizzas ordenadas y el cliente que realizó el pedido.

2. Creación y Manejo de un Pedido

Ahora, veamos cómo estas clases pueden utilizarse para crear y gestionar un pedido.

public class PizzaShopService 
{
    public Order CreateOrder(Customer customer) 
    {
        return new Order { Customer = customer };
    }

    public Pizza CreatePizza(PizzaSize size, List<string> toppings) 
    {
        var pizza = new Pizza { Size = size };
        foreach (var topping in toppings) {
            pizza.AddTopping(topping);
        }
        return pizza;
    }
}

PizzaShopService es una clase que encapsula la lógica para crear pedidos y pizzas. Proporciona métodos para crear un nuevo pedido y para construir una pizza con un tamaño y toppings específicos.

3. Uso del Servicio de Pizzería

Por último, veamos cómo un cliente podría utilizar estos servicios para hacer un pedido.

public class PizzaShopApplication 
{
    public static void Main(string[] args) 
    {
        var pizzaShopService= new PizzaShopService();
        var customer = new Customer { Name = "John Doe", Address = "Calle Falsa 123" };
        var order = pizzeriaService.CreateOrder(customer);

        var pizza = pizzaShopService.CreatePizza(PizzaSize.Medium, new List<string> { "Pepperoni", "Queso extra" });
        order.AddPizza(pizza);

        // Mostrar detalles del pedido
        Console.WriteLine($"Pedido para: {order.Customer.Name}");
        Console.WriteLine($"Dirección: {order.Customer.Address}");
        Console.WriteLine($"Total a pagar: {order.TotalPrice}");
    }
}

Aquí, creamos una instancia del servicio de pizzería, un cliente y luego un pedido para ese cliente. Creamos una pizza y la añadimos al pedido. Finalmente, mostramos los detalles del pedido. Este código demuestra cómo se pueden usar las clases y métodos definidos anteriormente de manera cohesiva y ordenada.

Al finalizar nuestro recorrido por el ejemplo práctico de la pizzería, espero que haya quedado claro cómo los principios de Clean Code se aplican en un escenario real de desarrollo de software. A través de este ejemplo en C#, hemos visto la importancia de mantener nuestro código organizado, modular y centrado en su propósito.

Lo más destacado de este ejemplo es cómo cada clase y función tiene un rol bien definido. Las clases Pizza, Customer y Order encapsulan claramente las responsabilidades y datos relevantes. El servicio PizzaShopService actúa como un intermediario entre la lógica de negocio y la interacción del usuario, manteniendo una separación limpia y ordenada entre estas capas.

Además, la manera en que se estructuró el código facilita su comprensión y mantenimiento. Por ejemplo, si en el futuro quisiéramos agregar nuevas características, como ofertas especiales o tipos de masa diferentes, podríamos hacerlo con cambios mínimos y bien localizados, gracias a la estructura clara y modular que hemos establecido.

Conclusión: El poder de una función

Para concluir, recordemos que escribir funciones limpias y eficientes no es solo una cuestión de seguir reglas; es una práctica que mejora con el tiempo y la experiencia. Cada función que escribimos es una oportunidad para mejorar nuestro oficio y contribuir a un código más saludable y sostenible. ¡Así que la próxima vez que te sientes a escribir una función, recuerda estos consejos y haz que cada línea de código cuente!

Espero que hayan encontrado útil este post. En los próximos artículos, seguiremos explorando otros aspectos del Código Limpio y cómo podemos aplicarlos en nuestro día a día como desarrolladores de software. ¡Hasta la próxima!

Happy Coding 😸

Por Qué Importan los Nombres en el Código

Los nombres son las primeras pistas que tenemos sobre la función de una variable, la acción de una función o la esencia de una clase. Un buen nombre nos ahorra tener que decodificar el propósito del elemento, simplificando la comprensión y mantenimiento del código. Así, un código bien nombrado se defiende por sí solo y minimiza la dependencia de comentarios explicativos.

El Arte de Nombrar en la Programación

Nombrar correctamente es un arte que mejora con la práctica y el estudio. Aquí algunas directrices extraídas del capítulo para que tus nombres hablen por sí solos:

1. Relevancia: Escoge nombres que revelen intención. Deja que el nombre comunique por qué existe la variable, qué hace y cómo se usa.

    // ❌ Incorrecto 
    var d1 = new DateTime();
   

    // ✔️ Correcto
    var checkInDate = new DateTime();
   

   En el ejemplo incorrecto, d1 no indica qué representa. En cambio, checkInDate comunica claramente su propósito.

2. Claridad: Opta por nombres que puedan pronunciarse. Las abreviaturas y jergas complican la comunicación entre desarrolladores.

    // ❌ Incorrecto
    var rmNum = "101A";
   

    // ✔️ Correcto
    var roomNumber = "101A";
   

   rmNum podría ser confuso y difícil de pronunciar, mientras que roomNumber es claro y fácil de entender.

3. Precisión: Cuando el tipo de dato no es explícito, inclúyelo en el nombre. Esto añade claridad y reduce la ambigüedad.

    // ❌ Incorrecto
    var guestInfo = "John Doe";
   

    // ✔️ Correcto
    var guestName = "John Doe";
   

   guestInfo podría referirse a cualquier información del huésped, pero guestName especifica que se trata del nombre.

4. Acción para Funciones: Las funciones hacen algo, así que sus nombres deben ser verbos o frases verbales que describan esa acción.

    // ❌ Incorrecto
    void Reservation() { ... }
   

    // ✔️ Correcto
    void CreateReservation() { ... }
   

   Reservation parece más un nombre de clase; CreateReservation aclara que la función está destinada a crear una reserva.

5. Sustancia para Clases: Las clases representan entidades u objetos, por lo que sus nombres deben ser sustantivos o frases sustantivas.

    // ❌ Incorrecto
    class ManagingRooms { ... }
   

    // ✔️ Correcto
    class RoomManager { ... }
   

   ManagingRooms suena más a una actividad. RoomManager identifica claramente la clase como una entidad o un objeto que gestiona habitaciones.

6. Evolución: No temas renombrar. Si descubres un nombre más descriptivo o si el contexto cambia, actualiza los nombres para que sigan siendo relevantes.

    // ❌ Incorrecto
    var tempDate = new DateTime()
   

    // ✔️ Correcto
    var reservationCreationDate = new DateTime();
   

   Aunque inicialmente tempDate pudo haber sido un nombre adecuado, su propósito se hizo más claro con el tiempo. Cambiarlo a reservationCreationDate refleja mejor su uso actual.

Ejemplo práctico

Este es un ejemplo práctico dentro del dominio de una aplicación de reserva de habitaciones.

La Clase Reservation es el corazón del ejemplo, representando una reserva individual dentro del sistema. Esta clase está diseñada para ser clara y autodescriptiva, con propiedades que incluyen ReservationId, CheckInDate, CheckOutDate, BookingGuest, ReservedRoom y ReservationPayment, cada una nombrada de tal manera que su función y propósito son inmediatamente evidentes para el desarrollador.

A través de una serie de métodos como IsReservationDateRangeValid, CancelReservation, CheckIn, CheckOut, ExtendCheckOutDate, UpdateGuestDetails y ProcessReservationPayment, encapsulamos las acciones clave que se pueden realizar con una reserva. Estos métodos están nombrados como verbos o frases verbales, siguiendo las mejores prácticas de Clean Code, indicando las acciones que efectúan y facilitando la lectura y comprensión del código.

Este enfoque de nombramiento no solo mejora la legibilidad sino que también enriquece la base de código con semántica clara y precisa, una inversión que paga dividendos en mantenibilidad y escalabilidad a largo plazo. El ejemplo sirve como un modelo de cómo aplicar los principios de Clean Code en la vida real, creando código que no solo funciona, sino que comunica y resiste el paso del tiempo y el cambio.

public class Reservation
{
    public DateTime CheckInDate { get; set; }
    public DateTime CheckOutDate { get; set; }
    public Guest BookingGuest { get; set; }
    public Room ReservedRoom { get; set; }
    public Payment ReservationPayment { get; set; }

    // Un método bien nombrado que indica claramente lo que hace
    public bool IsReservationDateRangeValid()
    {
        return CheckOutDate > CheckInDate;
    }

    // Otro ejemplo de un método con un nombre significativo
    public void CancelReservation()
    {
        // Código para cancelar la reserva
    }

    // Realiza el check-in del huésped
    public void CheckIn()
    {
        // Código para registrar la llegada del huésped
    }

    // Realiza el check-out del huésped
    public void CheckOut()
    {
        // Código para registrar la salida del huésped y liberar la habitación
    }

    // Extiende la fecha de check-out
    public void ExtendCheckOutDate(DateTime newCheckOutDate)
    {
        if (newCheckOutDate <= CheckInDate)
        {
            throw new InvalidOperationException("La nueva fecha de salida debe ser posterior a la fecha de entrada.");
        }

        CheckOutDate = newCheckOutDate;
        // Lógica adicional para manejar la extensión de la reserva
    }

    // Actualiza los detalles del huésped en la reserva
    public void UpdateGuestDetails(Guest newDetails)
    {
        // Código para actualizar los detalles del huésped
        BookingGuest = newDetails;
    }

    // Procesa el pago de la reserva
    public void ProcessReservationPayment(decimal amount)
    {
        ReservationPayment.ProcessPayment(amount);
        // Código adicional en caso de que el pago afecte el estado de la reserva
    }
}

// Clase que representa a un huésped que realiza una reserva
public class Guest
{
    public string FullName { get; set; }
    public string Email { get; set; }
    // Otros detalles relevantes sobre el huésped pueden ir aquí
}

// Representa una habitación que puede reservarse
public class Room
{
    public string RoomNumber { get; set; }
    public string Description { get; set; }
    public int Capacity { get; set; }
    // Más propiedades relevantes de la habitación pueden ser incluidas aquí
}

// Clase que maneja los pagos de las reservas
public class Payment
{
    public decimal Amount { get; set; }
    public DateTime PaymentDate { get; set; }
    public bool IsPaymentComplete { get; set; }

    // Método que describe la acción de procesar un pago
    public void ProcessPayment(decimal amount)
    {
        // Lógica para procesar el pago
        IsPaymentComplete = true;
    }
}

Este ejemplo demuestra cómo los nombres significativos pueden hacer que el código sea mucho más legible y comprensible. Las clases y métodos están nombrados de tal manera que su propósito y uso son inmediatamente evidentes, lo que ayuda a cualquier desarrollador que esté leyendo o manteniendo el código.

Conclusión: El Poder de un Nombre

El capítulo de "Nombres Significativos" en "Clean Code" nos recuerda que los nombres que elegimos tienen un impacto profundo en la calidad y claridad de nuestro código. Adoptando estas prácticas, no solo mejoramos nuestra base de código, sino que facilitamos la colaboración y contribuimos a la creación de software de mayor calidad. Los nombres adecuados son una poderosa herramienta en las manos de un ingeniero de software comprometido con la excelencia.

Al cerrar este capítulo, queda claro que la nomenclatura no es una mera formalidad, sino una poderosa herramienta de comunicación dentro del código. Los nombres que escogemos actúan como faros de entendimiento, iluminando el propósito y uso de cada componente para cualquier persona que explore nuestro trabajo.

En la ingeniería de software, donde el código es un organismo vivo sujeto a cambios y evolución, adoptar la práctica de elegir nombres con intención es fundamental. Al hacerlo, no sólo facilitamos el mantenimiento y la colaboración, sino que también elevamos la calidad del software que entregamos.

Te animo a llevar estas reflexiones a tu entorno de desarrollo. Examina tu código con ojo crítico, pregúntate si los nombres utilizados comunican claramente su función y no dudes en renombrar cuando encuentres una palabra que ofrezca mayor claridad.

Recuerda, en el universo del código limpio, cada nombre cuenta. Que tus nombres hablen, que cuenten historias de claridad y propósito, y que tu código sea un testimonio de tu artesanía en el arte de programar.

Happy Coding 😸