Esiste un nome specifico per il paradosso "Quadrato eredita dal rettangolo"?

Un certo fallimento di OOP viene mostrato con una classe Square che eredita da Rectangle, dove Logicamente Square è una specializzazione di Rectangle e dovrebbe quindi ereditare da esso, ma tutto cade a pezzi quando si tenta di modificare la lunghezza o la larghezza di un quadrato.

Esiste un termine specifico per descrivere cosa non va in quel caso?

object-oriented inheritance liskov-substitution

— Vincitore
fonte

potresti per favore spiegare cosa esattamente "sta andando storto"? Non capisco cosa intendi

— moscerino

Supponendo che un rettangolo abbia un metodo virtuale che consente di impostare le dimensioni passando lunghezza e larghezza, l'impostazione di una lunghezza e larghezza diverse su un quadrato potrebbe restituire un rettangolo e l'impostazione di una stessa lunghezza e larghezza su un rettangolo potrebbe restituire un quadrato. Qualsiasi codice che deve conoscere esplicitamente il quadrato può tentare di eseguire il cast in un quadrato. Non vedo come si verifica un errore ...

Questo non è un paradosso. Questo è un caso di modellazione impropria del dominio problematico. La gerarchia ereditaria NON si allinea necessariamente con la gerarchia delle cose nel dominio problematico. È bello quando lo fa, ma il trucco di un buon modello è capire dove devi fare le cose in modo diverso dal mondo reale.

— Michael Kohne,

FWIW: Più specificamente, il problema è che le interfacce di lettura e scrittura non corrispondono. Cioè puoi leggere un cerchio come specializzazione di un'ellisse, ma solo scrivere un'ellisse come specializzazione di un cerchio.

— Macke,

@GrandmasterB Vado per "qualsiasi persona, cosa o situazione esibendo una natura apparentemente contraddittoria". La contraddizione è che se il quadrato ha proprietà diverse, dobbiamo dire "un quadrato non è una sorta di rettangolo", quando in realtà ci aspettiamo che Square sia un sottotipo di rettangolo. Probabilmente nessuna vera applicazione avrebbe tipi di rettangolo e quadrato, è solo un'astrazione per illustrare un certo tipo di problema che può apparire in paradigmi basati su classi.

— Victor,

Risposte:

Wikipedia si riferisce semplicemente ad esso come al problema dell'ellisse circolare

Il problema delle ellissi circolari nello sviluppo del software (talvolta noto come problema del rettangolo quadrato ) illustra una serie di insidie che possono sorgere quando si usa il polimorfismo dei sottotipi nella modellazione di oggetti. I problemi si verificano più comunemente quando si utilizza la programmazione orientata agli oggetti.

Questa è la L nell'acronimo SOLID che è noto come principio di sostituzione di Liskov . Questo problema sorge come una violazione di tale principio.

Il problema riguarda quale sottotipo o relazione ereditaria dovrebbe esistere tra le classi che rappresentano cerchi ed ellissi (o, analogamente, quadrati e rettangoli). Più in generale, il problema illustra le difficoltà che possono verificarsi quando una classe base contiene metodi che mutano un oggetto in un modo che potrebbe invalidare un invariante (più forte) trovato in una classe derivata, causando la violazione del principio di sostituzione di Liskov ...

— Mark Canlas
fonte

E, leggendolo, Wikipedia menziona la spiegazione più accademica come "[violazione del] principio di sostituzione di Liskov". Grazie :)

— Victor,

Bene, è solo una violazione a seconda di come la guardi. Personalmente, tutti i cerchi sono ellissi; non c'è violazione. Inizia a esserci una violazione se i metodi per l'ellisse diventano restrittivi. Quindi, in quel particolare scenario, un cerchio non può essere un sottotipo di quel particolare contratto di ellisse.

— Mark Canlas,

@MarkCanlas Il problema è senza dubbio una violazione del principio di sostituzione di Liskov. Potrebbe non essere una violazione di altri principi, ma nessuno l'ha affermato. Quando il problema non si verifica perché i contratti non includono alcun invariante che potrebbe essere rotto (anche se non riesco a immaginare un modello utile in cui questo è vero), potrebbe non esserci una violazione dell'LSP, ma ciò non significa che il il problema , quando si verifica, non è dovuto a una violazione di LSP.

@Mark Canlas: no, il cerchio costante è un'ellisse costante , il cerchio mutabile non è un'ellisse mutabile. Nella geometria si presume la costanza, non è possibile modificare un'ellisse, è possibile prendere un'altra ellisse

— 1000

Il vincolo / regola della storia del principio di sostituzione di Liskov afferma che quando un sottotipo aggiunge nuovi metodi, tali metodi non sono autorizzati a manipolare lo stato dell'oggetto in modo tale da creare una storia (cioè una serie di stati) che non è consentito nel supertipo. Ad esempio, non è possibile creare un sottotipo di un mutevole immutabile, perché quando manipolato solo attraverso i metodi del supertipo, lo stato è sempre lo stesso, mentre quando manipolato attraverso i metodi mutatori del sottotipo, lo stato cambia. Questa è una storia che non è consentita dal supertipo.

— Jörg W Mittag,

Lo considererei una violazione del principio di sostituzione di Liskov - la Squaresottoclasse viola specificamente l'invariante secondo cui lunghezza e larghezza sono indipendenti.

— Paul Phillips
fonte

A un livello più fondamentale del principio di sostituzione di Liskov, si tratta di un errore di categoria o di categoria

Nel contesto del comportamento di modellazione, un quadrato semplicemente non è un tipo di rettangolo.

Quando ti rendi conto di questo, il problema evapora poiché l'assunto iniziale (un quadrato è un tipo di rettangolo) viene rimosso dal gioco.

Il problema con questa risposta è che dalla scuola viene praticato in chiunque faccia geometria che un quadrato è un tipo di rettangolo. Ma è molto importante capire che questo è vero solo in un contesto molto specifico (la classificazione delle forme geometriche in base alle proprietà dei loro angoli interni). In termini di comportamento, un quadrato non è un rettangolo. Vedere un set di classificazione nel contesto sbagliato è un errore di categoria.

— Cormac Mulhall
fonte