Principio di sostituzione di Liskov

[shodan]

qui cadi in contradizione: dato che la natura non ha forme rigide la natura non può pensare niente del quadrato perché non esiste.

Io non la vedo. Se in natura non esistono quadrati, allora il problema quadrato => caso particolare del rettangolo è solo un problema umano. E dato che la geometria è stata inventata dall'uomo, all'uomo fa comodo definire un caso particolare del rettangolo, quadrato.

questo è un problema dell'OOP e non della geometria.

Ma qui si sta parlando di OOP non di geometria. Se per sua natura l'OOP è meno precisa della geometria, si adatta la geometria all'OOP non viceversa.

errato: il parallelogramma è solo un caso speciale di poligono a 4 lati che a sua volta è un caso speciale di poligono che è un caso speciale di poligonale... figura. Inoltre rombo e rettangolo sono un caso speciale di parallelogramma e quadrato un caso speciale di questi ultimi due.

E quindi? Il concetto rimane quello di raffinare il grezzo. Il punto di partenza scelto è tra quelli che ci fa più comodo. Altrimenti dovrei dire che in ultima analisi il quadrato è un caso particolare di punto in movimento. Bello, ma poco pratico

Una soluzione già accennata da MItaly è la ereditarietà multipla.

Se non ricordo male Java ha tolto questa possibilità e nemmeno in C++ che chi ne è entusiasta. Io in C++ userei l'ereditarietà protetta, più che altro per nascondere l'interfaccia del rettangolo e definire la nuova interfaccia solo per il quadrato. Ma si può fare in Java (non lo conosco molto)?

Questa è la soluzione più logica ed è anche il motivo per cui nei linguaggi che adottano principi funzionali non si incorre in questi problemi.

Ce ne saranno altri. Non mancano i problemi, mancano le soluzioni

[Scara95]

Io non la vedo. Se in natura non esistono quadrati, allora il problema quadrato => caso particolare del rettangolo è solo un problema umano. E dato che la geometria è stata inventata dall'uomo, all'uomo fa comodo definire un caso particolare del rettangolo, quadrato.

Invece c'è perché dato che siamo noi a creare la gerarchia definendola siamo noi che abbiamo creato il quadrato. La natura non ha una definizione di quadrato e non ha una definizione di figura per il semplice fatto che queste non esistono ma sono nostre rappresentazioni (Che Schopenhauer sia con me). 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.

Ma qui si sta parlando di OOP non di geometria. Se per sua natura l'OOP è meno precisa della geometria, si adatta la geometria all'OOP non viceversa.

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

E quindi? Il concetto rimane quello di raffinare il grezzo. Il punto di partenza scelto è tra quelli che ci fa più comodo. Altrimenti dovrei dire che in ultima analisi il quadrato è un caso particolare di punto in movimento. Bello, ma poco pratico

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". Può funzionare anche da alterata, ma non è comunque corretta: ed è proprio qui che emergono evidenti problemi nell'oop, specialmente in quello a ereditarietà singola: perché come principio si propone di ricostruire la gerarchia reale, ma non ne è in grado perché troppo limitato (già Eiffel migliora molto la situazione).

Se non ricordo male Java ha tolto questa possibilità e nemmeno in C++ che chi ne è entusiasta. Io in C++ userei l'ereditarietà protetta, più che altro per nascondere l'interfaccia del rettangolo e definire la nuova interfaccia solo per il quadrato. Ma si può fare in Java (non lo conosco molto)?

In C++ l'ereditarietà multipla fa altamente schifo, è per questo che ho citato Eiffel.

Ce ne saranno altri. Non mancano i problemi, mancano le soluzioni

Non ho detto che questo è l'unico problema, ma che la tua soluzione, seppur possibile, è concettualmente sbagliata. La soluzione di non consentire modifiche invece può essere implementata senza errori concettuali.

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.

Note:
Natura: che non riguarda l'uomo.
Natura umana/dell'uomo: modo di agire o pensare innato nell'uomo che impone i suoi schemi di ragionamento sul reale.
Rappresentazione: realtà mediata dagli schemi mentali umani.

[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 ^_^