Principios SOLID en el diseño orientado a objetos

Los 5 pilares de SOLID

  • S: Single Responsibility Principle (SRP): Una clase o módulo debe tener una y solo una razón para cambiar. Cada componente del sistema debería concentrarse en una única funcionalidad o actor de negocio, evitando clases enormes con responsabilidades cruzadas, como lógica de negocio mezclada con persistencia y formato de salida.
  • O: Open/Closed Principle (OCP): Las entidades de software (clases, módulos, funciones) deben estar abiertas para su extensión, pero cerradas para su modificación. Esto se logra diseñando con polimorfismo, interfaces y clases abstractas, de modo que se incorporen comportamientos nuevos sin alterar el código ya probado.
  • L: Liskov Substitution Principle (LSP): Las clases derivadas deben poder sustituir a sus clases base en cualquier momento sin alterar las propiedades deseables ni el comportamiento esperado del programa. Una subclase nunca debe debilitar las precondiciones ni fortalecer las postcondiciones del contrato heredado.
  • I: Interface Segregation Principle (ISP): Es preferible contar con varias interfaces pequeñas y altamente especializadas antes que con una sola interfaz genérica y de gran tamaño. Ninguna clase debería verse obligada a implementar métodos o contratos que no usa realmente.
  • D: Dependency Inversion Principle (DIP): Los módulos de alto nivel (la lógica de negocio principal) no deben depender de los módulos de bajo nivel (los detalles técnicos de infraestructura o persistencia); ambos deben depender de abstracciones (interfaces). Además, las abstracciones nunca deben depender de los detalles concretos.

Impacto arquitectónico en el desarrollo backend

La aplicación conjunta de SOLID consolida bases sólidas para arquitecturas limpias y microservicios. En particular, el principio DIP habilita de forma directa patrones como la inyección de dependencias, logrando que los núcleos de negocio permanezcan agnósticos ante cambios de frameworks, motores de bases de datos o servicios externos.

Preguntas clave

  1. ¿De qué forma específica una clase derivada puede violar el Principio de Sustitución de Liskov (LSP), por ejemplo lanzando excepciones inesperadas ante métodos heredados?
  2. ¿Por qué la aplicación excesiva o dogmática de los principios SOLID en proyectos con plazos reducidos puede derivar en sobreingeniería innecesaria?

© Arturo Juárez Monroy