Principios SOLID ¿Qué son, cómo y dónde los he usado?

SOLID

Es un término que recien vengo escuchando, aunque para mi sorpresa se viene utilizando desde el 2000. Esto demuestra que no en todos lados los consideran o no todos los equipos los implementan, tal vez sí lo hacen pero no toman conciencia de ello.

Revisando a qué se refiere puedo decir que significa:

• Single responsibility
• Open-closed
• Liskov substitution
• Interface segregation
• Dependency inversion

Pero ahora... ¿qué son, cómo y dónde los he utilizado?

Single responsibility

¿Has utilizado clases/objetos y/o microservicios? Pues ahí estás utilizando este principio.

Este principo indica que cada elemento desarrollado debe realizar solamente una tarea. Por ejemplo: Tu clase Libro solo debería tener métodos como Prestar, Devolver, Retirar, nada de VerHistorialUsuarios, de igual forma, el método Prestar solo debe hacer eso y no algo como además de prestar debe verificar si el usuario puede solicitar más préstamos o si tiene adeudos o revisar la vigencia de la membresía de este.

Open-closed

El código de la clase debe estar cerrado a modificaciones (un código funcional y depurado) y la clase abierta a ampliaciones, de esta forma se agregan nuevas funcionalidades, se realizan mejoras y el código original se mantiene sin cambios. Para ello la clase ha de ser abstracta, obligando a ser heredada para ser consumida, algo similar al uso de interfaces.

      public abstract class Punto {
        public float X { get; set; }
        public float Y { get; set; }
        public float Z { get; set; }
    }
    public abstract class MathVector {
        public Punto A { get; set; }
        public Punto B { get; set; }
        public float ProductoPunto { get { return (A.X * B.X) + (A.Y * B.Y) + (A.Z * B.Z); } }
        public float ProductoCruz { get { return (A.Y * B.Z) + (A.Z * B.X) + (A.X * B.Y) - (A.Y * B.X) - (A.Z * B.Y) - (A.X * B.Z); } }
    }
    public class Punto3D : Punto {
        public Punto3D(float x, float y, float z) {
            X = x;
            Y = y;
            Z = z;
        }
    }
    public class Vector3D : MathVector {
        public Vector3D(Punto origen, Punto destino) {
            A = origen;
            B = destino;
        }
        public double ObtenerDistancia() {
            float X = A.X - B.X,
                Y = A.Y - B.Y,
                Z = A.Z - B.Z;
            return Math.Sqrt((X * X) + (Y * Y) + (Z * Z));
        }
    }
  

Liskov substitution

Básicamente dice que cualquier clase heredada debería poderse cambiar por su clase ancestro o base.

Interface segregation

Dice que lo mejor es tener un conjunto de interfaces bien enfocadas, básicamente que tengan solo los elementos necesarios para cierta (en singular) funcionalidad en vez de tener una gran interfaz más general. Ya que una clase que consume una interfaz se obliga a implementar esos métodos, tener varias interfaces pequeñas asegura que la clase solo implemente lo requerido y no tener que implementar cosas que no se utilizarán. ¿"Single responsibility"?

Dependency inversion

Este principio ofrece formas para desacoplar el código, es decir, cada clase no debe depender de las demás para realizar su función. No se debería obligar a crear instancias de clases en específico en los módulos desarrollados, por el contrario, se deben ofrecer mecanismos que permitan utilizar diferentes clases sin "amarrar" los objetos entre sí. El uso de constructores con interfaces en vez de clases específicas.

A manera de conclusión

Seguir estos principios, al inicio puede ser confuso pero a la larga permiten que nuestros desarrollos sean más ágiles y flexibles. Tal vez como efecto colateral sea el que escribamos más código pero la ventaja es que será más facil de probar, depurar, ampliar y reutilizar.

Comienza con uno o dos princpios, luego revisa tus proyectos personales agregando otro más y en futuros desarrollos irás viendo mejoras