Principio di sostituzione di Liskov

[Scara95]

Il discorso secondo me è che in OOP all'atto pratico non importa definire una tassonomia rigida di classi basata su criteri arbitrari - in questo caso, una classificazione basata sulle lunghezze sul parallelismo dei lati. L'utilità delle classi e dell'ereditarietà si manifesta piuttosto essenzialmente da due punti di vista:

• implementazione di un'interfaccia - ovvero, i miei tipi possono essere usati da codice che ci lavora sopra in maniera generica, sfruttando le sole funzioni definite nell'interfaccia;
• riutilizzo del codice delle classi basi - ovvero, la mia classe può riciclare il grosso del codice definito nelle classi base per portare a termine i suoi compiti.

In questo caso, una gerarchia di classi che ricalchi rigidamente la classificazione geometrica non dà alcun vantaggio pratico, perché l'interfaccia che ha senso avere in comune tra le varie figure alla fine è al più quella di un quadrilatero (e solo a livello di metodi getter); in altri termini, per quello che ci importa in OOP un quadrato in genere non è un rettangolo e un rombo, perché riciclare l'interfaccia di un rettangolo o di un rombo per il quadrato ci dà più che altro inutili complicazioni e scarso riutilizzo di codice.

Infatti non ero critico sul fatto che questa rappresentazione potesse essere usata e valida dal punto di vista pratico, ma ero critico sulla sua correttezza. L'OOP, specialmente quello singolo (o quello multiplo implementato male che poi viene usato come singolo) è un sistema troppo rigido per fare quello che si era proposto alla nascita.
I vantaggi dell'OOP comunque non stanno nel riutilizzo di codice (nel quale i linguaggi funzionali sono molto più avanti), o almeno questi vantaggi sono molto molto MOLTO ridotti. Stanno invece nell'avere sempre in combinazione oggetto e funzioni che agiscono su esso che, in molti casi, consente una facilitazione nella trattazione, nella comprensione e nella mantenibilità del codice. Nel caso ad esempio permette di calcolare l'(Area?) di una figura generica senza conoscere nello specifico di che figura si tratti (cosa fattibile anche in un linguaggio funzionale, dove però l'aggiunta di un tipo di figura potrebbe risultare più problematica).
Non ho considerato altri paradigmi e soluzioni (che risulterebbero banali) solo perché già parlando della programmazione funzionale ho sforato. Comunque se siete interessati nell'OOP vi invito a vedere Eiffel (non tanto per l'uso, anche se esistono soluzioni professionali, ma per cultura)

[shodan]

A parte tutto questo discorso filosofico: è semplicemente innaturale per l'uomo non pensare al quadrato come un caso speciale di rettangolo e rombo e, di conseguenza, è innaturale per ogni cosa "creata dall'uomo". Che poi tu dica: "Meglio andare contro le definizioni e la natura umana perché così è più semplice" è un'altro discorso, ma così non definisci la corretta e gerarchia.

Dici che è innaturale per l'uomo, eppure due uomini, Riemann e Lobachesky hanno sconvolto la geometria semplicemente negando il quinto postulato di Euclide.
Io, nei limiti delle mie conoscenze, cerco, se esiste, un'altra prospettiva, e se esiste e mi modella meglio il problema utilizzo quella.
Del resto basta passare dalla geometria euclidea alla topologia ed ecco che il quadrato è equivalente a un cerchio o una calotta sferica.
In geometria iperbolica non esistono poligoni con quattro lati uguali e quattro angoli retti, per cui non esistendo rettangoli, il quadrato non può essere un caso particolare di rettangolo, ma è una figura a se stante.
Perché quindi in OOP devo sentirmi legato alla geometria euclidea?

OOP è un po' generico: ad esempio già utilizzando Eiffel come linguaggio si dimezzano i problemi.

Di Eiffel conosco solo la torre. Qui alzo le mani

No, il concetto è diverso: puoi partire da più in alto o saltare delle astrazioni se non ti servono, ma non puoi modificare la gerarchia pretendendo che rimanga "corretta in linea teorica".

Sei tu che hai tirato fuori tutto lo schema gerarchico di parallelogrammi etc.
Io mi sono limitato ad affermare che un quadrato è una figura geometrica e che la tratto singolarmente.

Non ho detto che questo è l'unico problema, ma che la tua soluzione, seppur possibile, è concettualmente sbagliata.
Con questo non voglio dire che uno non possa scrivere la tua soluzione, ma che non si attiene alla realtà umana e che quindi commette errori concettuali e non si attiene al proposito dell'OOP.

Diversa, non sbagliata. Come già detto non esiste solo la geometria euclidea e la realtà umana afferma che se si vede un quadrilatero con lati e angoli uguali, tale quadrilatero venga chiamato quadrato, non caso speciale di rettangolo o rombo.

Comunque ormai siamo OT (credo), per cui chiudo qui.
Del resto è evidente che abbiamo concezioni diverse sulla questione per cui non insisto oltre.
In ogni caso mi hai messo una pulce nell'orecchio

[Scara95]

Allora riformulo: è innaturale pensare che il quadrato non sia un caso speciale di rombo e rettangolo se si resta all'interno dell'ambito della geometria euclidea che presupponeva l'esempio e si cerca un'implementazione in un linguaggio OOP di questa struttura.

A parte il fatto che la geometria euclidea è quella più intuitiva...

Comunque se noti bene non ho detto che non si possa fare o sia sbagliato farlo, ma è concettualmente sbagliato partendo dai presupposti (impliciti ed espliciti) che c'erano. Infatti puoi notare (non so se l'hai letto) che ho affermato che la tua è una soluzione è una delle possibili.

Ogni sistema ha le sue limitazioni e bisogna prenderne atto ^_^