Introducción
Los principios SOLID son un conjunto de cinco principios de diseño de software en orientado a objetos que se utilizan para crear código de alta calidad y fácilmente mantenible. Los principios SOLID son:
- Principio de Responsabilidad Única (SRP): Una clase debe tener una sola razón para cambiar. Es decir, una clase debe tener una única responsabilidad. Si una clase tiene más de una responsabilidad, entonces se vuelve difícil de mantener y modificar. Por ejemplo, si tenemos una clase que se encarga de la lógica de negocio y también de la persistencia de datos, entonces esta clase viola el principio SRP. En su lugar, deberíamos tener dos clases separadas, una para la lógica de negocio y otra para la persistencia de datos.
- Principio Abierto/Cerrado (OCP): Las clases deben estar abiertas para la extensión pero cerradas para la modificación. Es decir, una clase debe ser fácil de extender sin necesidad de modificar su código fuente. Por ejemplo, si tenemos una clase que se encarga de la generación de informes, deberíamos poder extender esta clase para generar diferentes tipos de informes sin necesidad de modificar la clase original.
- Principio de Sustitución de Liskov (LSP): Las subclases deben ser sustituibles por sus clases base. Es decir, una subclase debe ser capaz de reemplazar a su clase base sin cambiar el comportamiento del programa. Por ejemplo, si tenemos una clase base que representa una forma geométrica y una subclase que representa un círculo, entonces la subclase debe ser capaz de reemplazar a la clase base en cualquier lugar donde se use la clase base.
- Principio de Segregación de Interfaces (ISP): Los clientes no deben depender de interfaces que no usan. Es decir, una clase no debe verse obligada a implementar interfaces que no necesita. En su lugar, deberíamos tener interfaces más pequeñas y específicas. Por ejemplo, si tenemos una interfaz que representa una impresora, no deberíamos obligar a todas las clases que necesitan imprimir a implementar esta interfaz. En su lugar, deberíamos tener interfaces más específicas como “Imprimible”.
- Principio de Inversión de Dependencias (DIP): Las clases de alto nivel no deben depender de las clases de bajo nivel. En su lugar, ambas deben depender de abstracciones. Es decir, una clase de alto nivel no debe depender directamente de una clase de bajo nivel. En su lugar, deberíamos tener una abstracción entre ellas. Por ejemplo, si tenemos una clase de alto nivel que necesita acceder a una base de datos, no deberíamos hacer que esta clase dependa directamente de la clase de bajo nivel que se encarga de la conexión a la base de datos. En su lugar, deberíamos tener una abstracción como una interfaz que represente la conexión a la base de datos.