¿Existe un nombre específico para la paradoja "El cuadrado hereda del rectángulo"?

Un cierto fallo de OOP se muestra con una clase Square heredando de Rectangle, donde lógicamente Square es una especialización de Rectangle y, por lo tanto, debe heredar de él, pero todo se desmorona cuando intenta cambiar la longitud o el ancho de un Square.

¿Existe un término específico para describir lo que está mal en ese caso?

object-oriented inheritance liskov-substitution

— Víctor
fuente

¿podría explicar qué exactamente "va mal"? No entiendo lo que quieres decir

— mosquito

Suponiendo que un rectángulo tiene un método virtual que le permite a uno establecer el tamaño pasando el largo y el ancho, establecer un largo y ancho diferentes en un cuadrado podría devolver un rectángulo y establecer un mismo largo y ancho en un rectángulo podría devolver un cuadrado. Cualquier código que necesite conocer el cuadrado explícitamente puede intentar convertirlo en un cuadrado. No veo cómo hay una falla ...

Esto no es una paradoja. Este es un caso de modelado incorrecto del dominio del problema. La jerarquía de herencia NO necesariamente se alineará con la jerarquía de cosas en el dominio del problema. Es agradable cuando lo hace, pero el truco en un buen modelo es comprender dónde debe hacer las cosas de manera diferente al mundo real.

— Michael Kohne

FWIW: Más específicamente, el problema es que las interfaces de lectura y escritura no coinciden. Es decir, puede leer un círculo como especialización de una elipse, pero solo escribir una elipse como especialización de un círculo.

— Macke

@GrandmasterB Voy por "cualquier persona, cosa o situación que exhibe una naturaleza aparentemente contradictoria". La contradicción es que si el cuadrado tiene propiedades diferentes, tenemos que decir "un cuadrado no es una especie de rectángulo", cuando de hecho esperamos que el cuadrado sea un subtipo de rectángulo. Probablemente ninguna aplicación real tenga los tipos Rectángulo y Cuadrado, es solo una abstracción para ilustrar un cierto tipo de problema que puede aparecer en paradigmas basados en clases.

— Victor

Respuestas:

Wikipedia simplemente se refiere a él como el problema del círculo-elipse

El problema de círculo-elipse en el desarrollo de software (a veces conocido como el problema de rectángulo cuadrado ) ilustra una serie de dificultades que pueden surgir cuando se utiliza el polimorfismo de subtipo en el modelado de objetos. Los problemas se encuentran más comúnmente cuando se usa programación orientada a objetos.

Esta es la L en el acrónimo SÓLIDO que se conoce como el principio de sustitución de Liskov . Este problema surge como una violación de ese principio.

El problema se refiere a qué subtipo o relación de herencia debería existir entre clases que representan círculos y elipses (o, de manera similar, cuadrados y rectángulos). En términos más generales, el problema ilustra las dificultades que pueden ocurrir cuando una clase base contiene métodos que mutan un objeto de una manera que podría invalidar un invariante (más fuerte) encontrado en una clase derivada, haciendo que se viole el principio de sustitución de Liskov ...

— Mark Canlas
fuente

Y, leyéndolo, Wikipedia menciona la explicación más académica como "[violación del] principio de sustitución de Liskov". Gracias :)

— Victor

Bueno, es solo una violación dependiendo de cómo lo veas. Personalmente, todos los círculos son elipses; No hay violación. Comienza a haber una violación si los métodos para elipse se vuelven restrictivos. Entonces, en ese escenario particular, un círculo no puede ser un subtipo de ese contrato particular de elipse.

— Mark Canlas

@ MarkCanlas El problema es indiscutiblemente una violación del principio de sustitución de Liskov. Puede que no sea una violación de otros principios, pero nadie lo afirmó. Cuando el problema no se produce porque los contratos no incluyen ninguna invariante que se rompa (aunque no imagino un modelo útil donde esto sea cierto), puede que no haya una violación del LSP, pero eso no significa que el El problema , cuando ocurre, no se debe a una violación de LSP.

@ Mark Canlas: no, el círculo constante es una elipse constante , el círculo mutable no es una elipse mutable. En geometría se supone la

— constancia

La restricción / regla de historia del principio de sustitución de Liskov dice que cuando un subtipo agrega nuevos métodos, esos métodos no pueden manipular el estado del objeto de tal manera que cree una historia (es decir, una serie de estados) que no permitido en el supertipo. Por ejemplo, no puede hacer un subtipo de una mutable inmutable, porque cuando solo se manipula a través de los métodos del supertipo, el estado es siempre el mismo, mientras que cuando se manipula a través de los métodos mutantes del subtipo, el estado cambia. Esa es una historia que no está permitida por el supertipo.

— Jörg W Mittag

Lo consideraría una violación del Principio de sustitución de Liskov : la Squaresubclase viola específicamente la invariante de que la longitud y el ancho son independientes.

— Paul Phillips
fuente

En un nivel más fundamental que el Principio de sustitución de Liskov, este es un error de categoría o error de categoría

En el contexto del comportamiento de modelado, un cuadrado simplemente no es un tipo de rectángulo.

Cuando te das cuenta de esto, el problema se evapora ya que la suposición inicial (un cuadrado es un tipo de rectángulo) se elimina del juego.

El problema con esta respuesta es que, desde la escuela, se perfora en cualquiera que haga geometría que un cuadrado es un tipo de rectángulo. Pero es muy importante comprender que esto solo es cierto dentro de un contexto muy específico (la clasificación de formas geométricas en función de las propiedades de sus ángulos internos). En términos de comportamiento, un cuadrado no es un rectángulo. Ver un conjunto de clasificación en el contexto incorrecto es un error de categoría.

— Cormac Mulhall
fuente