Principio de sustitución de Liskov — Python: Profundizando en las clases

• ¿Qué es el Principio de Sustitución de Liskov?
• Caso práctico: un logger
  • Problema al sobrescribir el método
  • Donde todo se rompe
• ¿Por qué importa esto?
• Reglas al diseñar jerarquías de tipos
  • 1. No reforzar los precondiciones
  • 2. No debilitar los postcondiciones
  • 3. No cambiar la forma de modificar datos heredados
• ¿Y cómo nos protegemos?
• ¿Qué se puede y qué no se puede hacer?

Hasta ahora, hemos aprendido a crear clases, heredar de otras y sobrescribir métodos. Sin embargo, usar estas herramientas sin cuidado puede generar problemas. En esta lección, veremos el LSP (Principio de Sustitución de Liskov), que nos ayuda a escribir código orientado a objetos más robusto y fácil de mantener.

¿Qué es el Principio de Sustitución de Liskov?

Este principio fue formulado en 1987 por la ingeniera de software Barbara Liskov. La idea, en palabras sencillas, es esta:

Esto parece obvio, pero cuando uno cambia la forma en que se comportan los métodos en una subclase, puede romper esa "compatibilidad" entre padre e hijo.

Caso práctico: un logger

Supongamos que queremos escribir un sistema que registre (loggee) mensajes con distintos niveles de importancia, por ejemplo: debug, info, error, etc.

class Logger:
    def log(self, level, message):
        # Aquí iría la lógica para registrar el mensaje
        print(f"[{level.upper()}] {message}")

# Ejemplo de uso
logger = Logger()
logger.log('debug', 'Iniciando proceso')
logger.log('info', 'Proceso en progreso')

Con esto, podemos registrar mensajes con diferentes niveles: 'debug', 'info', 'warning', 'error', etc.

La firma (o "forma") del método log es siempre igual: primero va el nivel, luego el mensaje.

Problema al sobrescribir el método

Ahora supongamos que queremos hacer un pequeño cambio para que el nivel de log sea opcional y, por defecto, tenga el valor 'debug'. Para eso creamos una subclase:

class MyLogger(Logger):
    def log(self, message, level='debug'):
        print(f"[{level.upper()}] {message}")

Ahora podemos usar MyLogger así:

logger = MyLogger()
logger.log('Cargando datos')  # Usa nivel debug por defecto
logger.log('Conexión completada', 'info')  # Cambia el nivel

Parece útil... pero ¿cuál es el problema?

Donde todo se rompe

Imaginemos que este logger lo vamos a usar en otra parte del sistema, que espera trabajar con un objeto Logger. Esa parte del código espera que log() reciba primero el nivel y luego el mensaje.

# Supongamos una función que recibe un Logger
def procesar(logger: Logger):
    logger.log('info', 'Inicio de proceso')

Ahora pasamos un MyLogger a esa función:

procesar(MyLogger())

El problema es que MyLogger espera que el primer argumento sea el mensaje, pero la función le está pasando el nivel primero. Resultado: un comportamiento erróneo o una excepción.

¿Por qué importa esto?

✅ El principio de sustitución nos ayuda a evitar errores cuando diseñamos jerarquías de clases. Si creamos objetos que se parecen, pero se comportan distinto, arruinamos el polimorfismo (la capacidad de usar objetos de distintas clases indistintamente, mientras cumplan con la misma interfaz).

Reglas al diseñar jerarquías de tipos

El principio va más allá de que las subclases "parezcan" sus padres. También hace recomendaciones sobre:

1. No reforzar los precondiciones

Los métodos en una subclase no deben exigir más que los de la clase padre.

Por ejemplo, si Logger.log() acepta ocho niveles de mensaje, no podemos hacer que una subclase sólo acepte tres. Eso sería "reforzar una restricción".

# Incorrecto: este logger acepta sólo niveles 'debug', 'info' y 'error'
class RestrictiveLogger(Logger):
    def log(self, level, message):
        if level not in ['debug', 'info', 'error']:
            raise ValueError('Nivel no soportado')
        print(f"[{level.upper()}] {message}")

Esto rompe el contrato del padre, porque alguien puede pasarle un nivel válido según Logger, pero inválido según RestrictiveLogger.

2. No debilitar los postcondiciones

Esto significa que no podemos devolver "menos" de lo que promete la clase padre. Por ejemplo, si el método del padre siempre confirma que algo se grabó correctamente, no podemos simplemente hacer nada o devolver un mensaje incompleto en la subclase.

3. No cambiar la forma de modificar datos heredados

Si una subclase sobreescribe propiedades o cambia la forma en que se modifican los datos del padre, también podemos romper este principio.

Esto se llama restricción histórica: la subclase no debe cambiar cómo funciona el tipo de datos base.

¿Y cómo nos protegemos?

Lo ideal es mantener la misma interfaz (firma y comportamiento) cuando sobrescribimos métodos. Si queremos cambiar cómo se usan algunas partes, es mejor hacerlo creando nuevas funciones o métodos, no reescribiendo los existentes con firmas incompatibles.

También podemos usar herramientas como @abstractmethod o clases abstractas para asegurarnos de que nuestras clases sigan ciertas reglas, pero eso lo vamos a ver más adelante.

¿Qué se puede y qué no se puede hacer?