Tu jerarquía de herencia perfecta viola el LSP

Has diseñado una jerarquía de herencia que luce impecable sobre el papel. Un Square es un Rectangle, un Penguin es un Bird. Qué podría salir mal. Esa estructura aparentemente perfecta puede convertirse en una bomba de tiempo si viola el Principio de Sustitución de Liskov LSP, degradando la calidad del diseño orientado a objetos. No es teoría abstracta: ignorar LSP introduce errores sutiles, vuelve el código frágil y encarece el mantenimiento.

Qué es el Principio de Sustitución de Liskov LSP

En esencia, LSP establece que si una clase S es subtipo de una clase T, entonces los objetos de tipo T deben poder ser reemplazados por objetos de tipo S sin alterar las propiedades deseables del programa. Imagina un interruptor que enciende cualquier bombilla. Si al poner una bombilla nueva el interruptor deja de funcionar o provoca un fallo, esa bombilla no es un sustituto seguro y viola LSP. En código, una subclase no debe romper el contrato ni las expectativas de la clase base.

Por qué importa LSP peligros ocultos

Ignorar LSP es como construir una casa sobre cimientos inestables. Puede funcionar hoy, pero al crecer el sistema surgen comportamientos impredecibles, errores difíciles de diagnosticar y una arquitectura costosa de extender. Cuando una subclase modifica los supuestos básicos de su clase base, cualquier código que dependía de esos supuestos queda comprometido. Aparecen acoplamientos innecesarios, baja mantenibilidad y pérdida de confianza en el comportamiento del software.

Cómo rompemos LSP sin querer errores fatales

Muchas violaciones de LSP provienen de confundir es un con compatibilidad de comportamiento. No se trata de categorías del mundo real, sino de que el comportamiento sea sustituible.

La trampa de Square y Rectangle

Matemáticamente, un cuadrado es un rectángulo, y es tentador heredar Square de Rectangle. Rectangle suele exponer métodos como setWidth y setHeight. Si estableces ancho 10 y alto 5, esperas un área de 50. En Square, cambiar el ancho debería forzar el mismo valor al alto y viceversa. Si una función recibe un Rectangle y ejecuta rect.setWidth 10 y luego rect.setHeight 5, pero le pasas un Square, este no puede ajustar ancho y alto de forma independiente. O fuerza ambos a 10 o a 5 para mantener la forma, o deja de ser un cuadrado. En ambos casos rompe las expectativas del código que usa un Rectangle, por lo que Square no es un sustituto seguro de Rectangle.

El problema de Penguin y Bird

Otro tropiezo común son métodos que no aplican a todos los subtipos. Si Bird define un método fly, la mayoría de aves vuelan, pero un Pingüino no. Si Penguin hereda de Bird y fly hace nada o lanza UnsupportedOperationException, se viola LSP. Cualquier código que espera que un Bird pueda volar fallará con un Penguin. Esto sugiere que la jerarquía intenta modelar demasiado o que la clase base asume responsabilidades no universales.

Cambiar el comportamiento de forma impredecible o lanzar nuevas excepciones

LSP también trata del contrato de un método. Si la clase base promete ciertas postcondiciones y acepta determinadas precondiciones, la subclase debe respetarlas. Por ejemplo, si PaymentProcessor tiene un método processPayment cantidad que promete devolver true en éxito o false en fallo, una subclase como CreditCardProcessor no debería de repente lanzar una excepción de red no contemplada por la interfaz base ni cambiar el tipo de retorno. Una subclase no debe fortalecer precondiciones ni debilitar postcondiciones. Hacerlo vuelve frágil el sistema, porque el resultado de una misma llamada dependerá del subtipo concreto.

Cómo corregirlo construye jerarquías robustas

Adherirse a LSP obliga a pensar a fondo en las relaciones entre clases y produce código más flexible, estable y entendible.

1. Prioriza sustituibilidad conductual, no solo categorización

Antes de heredar, pregúntate si una instancia de la subclase puede reemplazar a la de la clase base en todas partes sin sorpresas. Si la respuesta es no o depende, la herencia probablemente no es la herramienta adecuada. Piensa en lo que espera el usuario de la clase base.

2. Prefiere composición sobre herencia

Lo que parece una relación es un puede ser en realidad tiene un. En lugar de que Square sea un Rectangle, podría ser que Shape tenga una Dimension. En lugar de que Penguin sea un Bird que no vuela, quizá Animal tenga capacidades como FlightCapability o SwimCapability. La composición da flexibilidad y evita imponer métodos que no aplican a todos los subtipos.

3. Usa interfaces como contratos

Las interfaces definen capacidades sin imponer una jerarquía. En vez de que Bird tenga fly, define IFlyable. Sparrow implementa IFlyable y Penguin no. Así, el código que necesita volar solo trata con objetos IFlyable, garantizando el comportamiento.

4. Separa responsabilidades con claridad

Si métodos de la base no aplican a todas las subclases, probablemente la base hace demasiado. Divide en clases o interfaces más enfocadas. Por ejemplo, FlyingBird y FlightlessBird, o simplemente interfaces para el comportamiento de vuelo.

5. Diseño por contrato

Define precondiciones y postcondiciones. Una subclase nunca debe exigir más que la base ni prometer menos que la base. Si necesitas fortalecer precondiciones o debilitar postcondiciones, es una señal de violación de LSP y de que tu modelo necesita replantearse.

Cómo te ayuda Q2BSTUDIO a aplicar LSP en el mundo real

En Q2BSTUDIO somos una empresa de desarrollo de software con amplia experiencia en aplicaciones a medida y software a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, servicios inteligencia de negocio y power bi, automatización de procesos, agentes IA e IA para empresas. Aplicamos principios SOLID como LSP para crear arquitecturas mantenibles, escalables y preparadas para crecer sin sorpresas.

Si necesitas un partner técnico para diseñar y construir soluciones robustas y escalables, visita nuestra página de software a medida y descubre cómo transformamos requisitos complejos en productos de calidad. Y si quieres acelerar tus productos con modelos y agentes inteligentes, conoce nuestros servicios de inteligencia artificial para empresas para integrarlos de forma segura y alineada con tu arquitectura.

Evita herencias frágiles, contratos incumplidos y sorpresas en producción. Con un diseño que respeta LSP, tus equipos iteran más rápido, tu base de código envejece mejor y el negocio gana velocidad y confianza.