Principios SOLID en C#: teoría y práctica de la A a la Z

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Introducción: ¿por qué son necesarios los principios SOLID en C#?

Cada desarrollador de C# tarde o temprano se enfrenta al problema del "código sucio": clases que hacen de todo, dependencias ilegibles y la imposibilidad de realizar cambios sin riesgo de romper todo el proyecto. SOLID es el acrónimo de cinco principios fundamentales del diseño orientado a objetos, formulados por Robert Martin. Ayudan a crear código flexible, mantenible y testeable en C# (.NET).

En este artículo, analizaremos cada principio SOLID con una base teórica y ejemplos prácticos en C#. Aprenderá cómo aplicarlos en proyectos reales, evitando errores típicos.

1. Single Responsibility Principle (SRP) — principio de responsabilidad única

Teoría

Una clase debe tener solo una razón para cambiar. En otras palabras, cada clase es responsable de una sola parte de la funcionalidad del programa. La violación del SRP provoca que un cambio en una operación (por ejemplo, guardar en la BD) afecte la lógica de cálculos o de visualización.

Práctica en C#

Consideremos un ejemplo típico de violación del SRP: una clase que simultáneamente calcula el salario y guarda al empleado en la base de datos:

// ❌ Violación del SRP: la clase hace demasiadopublic class Employee{    public string Name { get; set; }    public decimal Salary { get; set; }

    public decimal CalculateBonus()    {        return Salary * 0.1m;    }

    public void SaveToDatabase()    {        // Lógica de guardado en la BD        Console.WriteLine("Empleado guardado en la BD");    }}

Corrijamos la situación separando las responsabilidades:

// ✅ SRP: cada clase es responsable de su tareapublic class Employee{    public string Name { get; set; }    public decimal Salary { get; set; }}

public class BonusCalculator{    public decimal Calculate(Employee employee)    {        return employee.Salary * 0.1m;    }}

public class EmployeeRepository{    public void Save(Employee employee)    {        Console.WriteLine("Empleado guardado en la BD");    }}

2. Open-Closed Principle (OCP) — principio de abierto/cerrado

Teoría

Las entidades de software (clases, módulos, funciones) deben estar abiertas para la extensión, pero cerradas para la modificación. Esto significa que puede agregar nueva funcionalidad sin modificar el código existente.

Práctica en C#

Supongamos que necesitamos calcular el área de diferentes figuras. La violación del OCP es usar if-else o switch para cada nuevo tipo de figura:

// ❌ Violación del OCP: al agregar una nueva figura, hay que cambiar el códigopublic class AreaCalculator{    public double Calculate(object shape)    {        if (shape is Circle circle)            return Math.PI * circle.Radius * circle.Radius;        else if (shape is Rectangle rect)            return rect.Width * rect.Height;        // Al agregar Triangle, habría que añadir otro if        return 0;    }}

Solución: usar abstracción y polimorfismo:

// ✅ OCP: extendemos mediante herencia, sin tocar el código existentepublic abstract class Shape{    public abstract double GetArea();}

public class Circle : Shape{    public double Radius { get; set; }    public override double GetArea() => Math.PI * Radius * Radius;}

public class Rectangle : Shape{    public double Width { get; set; }    public double Height { get; set; }    public override double GetArea() => Width * Height;}

public class AreaCalculator{    public double Calculate(Shape shape)    {        return shape.GetArea(); // Funciona para cualquier figura    }}