Principio de Sustitución de Liskov en Desarrollo de Software
Clase 7 de 27 • Curso de Patrones de Diseño y SOLID en Python
Resumen
El principio de sustitución de Liskov (LSP) es clave para garantizar la coherencia y la interoperabilidad en sistemas orientados a objetos. Propone que las subclases deben ser intercambiables con sus clases base sin alterar el comportamiento esperado. Esto evita problemas inesperados y asegura que las clases que implementen una interfaz o hereden de otra puedan utilizarse de manera consistente, facilitando la reutilización del código y reduciendo errores en tiempo de ejecución.
¿Qué establece el principio de sustitución de Liskov?
Este principio, propuesto por Barbara Liskov, establece que las subclases deben ser sustituibles por sus clases base sin afectar el comportamiento del programa. Es esencial para asegurar que el sistema se mantenga coherente y funcione correctamente cuando se emplean clases derivadas.
¿Cómo se aplican las subclases en LSP?
Las subclases deben respetar el contrato de la clase base. Esto significa que:
- No se puede cambiar la firma de los métodos.
- No se deben agregar nuevos atributos que afecten la funcionalidad de los métodos existentes.
- La interfaz y los tipos deben mantenerse compatibles.
¿Qué errores evita el principio de sustitución?
El LSP ayuda a evitar errores como:
- Excepciones inesperadas cuando se requieren parámetros adicionales no previstos en la clase base.
- Cambios en el tipo de retorno de los métodos que interrumpen la compatibilidad entre clases.
¿Cuáles son los beneficios del principio de sustitución?
- Reutilización del código: Las clases que cumplen con LSP pueden ser utilizadas en diferentes contextos sin modificaciones.
- Compatibilidad de interfaces: Facilita que las clases puedan interactuar de forma coherente sin errores inesperados.
- Reducción de errores en tiempo de ejecución: El código se mantiene predecible y coherente, disminuyendo la posibilidad de fallos imprevistos.
¿Cuándo aplicar el principio de sustitución de Liskov?
Es necesario aplicarlo cuando:
- Hay violación de precondiciones o poscondiciones, es decir, cuando los parámetros o el tipo de retorno de los métodos cambian.
- Se presentan excepciones inesperadas al usar subclases, lo que indica que no se puede hacer una sustitución sencilla entre ellas.