Principios SOLID

Principios SOLID son una serie de principios de diseño orientado a objetos que nos ayudan a crear código más mantenible y reutilizable. Estos principios fueron definidos por Robert C. Martin (Uncle Bob) en su libro “Agile Software Development, Principles, Patterns, and Practices” en 2000.

Los principios SOLID son:

S: Single Responsibility Principle (Principio de Responsabilidad Única)
O: Open-Closed Principle (Principio de Abierto-Cerrado)
L: Liskov Substitution Principle (Principio de Sustitución de Liskov)
I: Interface Segregation Principle (Principio de Segregación de Interfaces)
D: Dependency Inversion Principle (Principio de Inversión de Dependencias)

Single Responsibility Principle (Principio de Responsabilidad Única)

Este principio nos dice que una clase debe tener una única responsabilidad, es decir, que debe tener una única razón para cambiar. Esto nos ayuda a crear clases más pequeñas y con una única responsabilidad, lo que facilita su mantenimiento y reutilización. Por ejemplo, si tenemos una clase que se encarga de gestionar los usuarios de nuestra aplicación, esta clase debería tener las siguientes responsabilidades: CRUD de usuarios

Open-Closed Principle (Principio de Abierto-Cerrado)

Este principio nos dice que las entidades de nuestro código (clases, módulos, funciones, etc.) deben estar abiertas a la extensión pero cerradas a la modificación. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una clase que implementa una funcionalidad, no deberíamos modificar esa clase para añadir nuevas funcionalidades, sino que deberíamos crear una nueva clase que herede de la clase base y que implemente la nueva funcionalidad.

Liskov Substitution Principle (Principio de Sustitución de Liskov)

Este principio nos dice que las clases derivadas deben ser sustituibles por sus clases base. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una clase base que implementa una funcionalidad, las clases derivadas deben poder usar esa funcionalidad sin tener que modificar el código de la clase base.

Interface Segregation Principle (Principio de Segregación de Interfaces)

Este principio nos dice que las interfaces deben ser lo más pequeñas posibles. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una interfaz que define una funcionalidad, no deberíamos añadir más funcionalidades a esa interfaz, sino que deberíamos crear una nueva interfaz que herede de la interfaz base y que defina la nueva funcionalidad.

Dependency Inversion Principle (Principio de Inversión de Dependencias)

Este principio nos dice que las clases de alto nivel no deben depender de las clases de bajo nivel, sino que ambas deben depender de abstracciones. Esto nos ayuda a crear código más mantenible y reutilizable. Es decir, si tenemos una clase que implementa una funcionalidad, no deberíamos depender de la implementación de esa funcionalidad, sino que deberíamos depender de una interfaz que defina la funcionalidad.