Devo cambiare modo di pensare per passare ai linguaggi ad oggetti?

[fek]

Originariamente inviato da cdimauro

Questo: http://www.python.it/doc/Howtothink/...l-it/index.htm

Ormai sei peggio di Criceto con Apple

[cdimauro]

Originariamente inviato da AnonimoVeneziano

Bel papiro.

Questo è niente: in genere sono decisamente più prolisso.

Ma io sto parlando di apprendimento non di potenza in generale.

Io non parlavo di potenza, ma di modellazione della realtà.

Puoi craccare gli attributi protected e private? Bene, ma è una forzatura, non è la norma per il linguaggio. Il linguaggio ti guida verso un altra strada.

OK, ma non è detto che sia quella giusta.

L'ereditarietà multipla porta,per chi non ha mai usato il paradigma object oriented, a mostruosi errori come schemi di ereditarietà a rombo .

Li consente, ma arrivarci è tutto un altro paio di maniche.

Si può fare benissimo a meno dell'ereditarietà multipla e didatticamente non è il massimo.

Didatticamente è più semplice e naturale imparare il concetto che una classe possa ereditare da più classi, piuttosto che possa ereditare da una sola classe ed eventualmente implementare una o più interfacce.

Poi, come hai detto, si può anche fare a meno dell'ereditarietà multipla (e io generalmente ne faccio a meno, ma in alcuni casi m'è tornata molto comoda e utile).

Le interfacce sono uno strumento fantastico in Java . Formalizzano in maniera chiara il comportamento di una classe permettendo di separare nettamente l'implementazione dal comportamento. Tutto a favore di leggibilità e apprendimento al contrario dell'"emulazione" (come già dice il nome) tramite ereditarietà multipla.

Emulazione è un modo di dire: con l'ereditarietà multipla posso modellare "quello che voglio", per cui anche il comportamento delle interfacce.

Utilizzare delle classi (con l'ereditarietà multipla) per definire un "comportamento" non è un'emulazione né tanto meno una loro "castrazione", ma una precisa scelta di design.

Per quanto riguarda la sintassi ... beh, a me la sintassi di Python aborre . Ritengo Python un linguaggio dai tanti lati positivi, ma la sintassi per me non è uno di quelli. La sintassi è una questione di gusto comunque, ormai è provato da lunghe discussioni in questo stesso forum che non è un parametro di valutazione oggettivo valido.

Esatto, per cui non ho nulla da dire: de gustibus, appunto.

Per l'ultima parte ... beh,non sta scritto da nessuna parte, ma didatticamente a mio parere può confondere non definendo bene la strada da seguire per creare un buon progetto OO , portando magari a ragionamenti come : " adesso definisco la classe, dopo una volta istanziata la classe ci aggiungo attributi e metodi", che per me sono sbagliati . Un oggetto è un entità con delle sue proprietà ed è importante che uno impari a definirle fin da subito.

Saluti

Ed è una cosa che puoi fare (e, anzi, generalmente si fa) benissimo in Python: quando dichiari una classe definisci anche i suoi attribuiti e/o metodi esattamente come faresti con Java, C#, C++, Delphi o qualunque altro linguaggio OO "tradizionale".

IN PIU' hai la possibilità di cambiare il comportamento di singole istanze o di un'intera classe a runtime, se il modello del tuo progetto lo prevede oppure ti accorgi che lo semplifica (il modello).

Riassumendo il tutto: con Python non hai nulla di meno di quanto offrono linguaggi come Java in termini di modellazione di una soluzione tramite il concetto di oggetto. Anzi, hai una semplificazione (grazie anche al weak typing) ed eventualmente degli strumenti aggiuntivi.

[cdimauro]

Originariamente inviato da Matrixbob

Ma la fisolofia della programmazione OO qual'è?
Che esistono solo oggetti che comunicano tra loro?

http://it.wikipedia.org/wiki/Program...a_agli_oggetti

[cdimauro]

Originariamente inviato da fek

Ormai sei peggio di Criceto con Apple

Ma io non dico cose insensate o false!!!

[fek]

Originariamente inviato da cdimauro

Ma io non dico cose insensate o false!!!

Ma sei quasi altrettanto zelota

[cdimauro]

Solo io? http://www.hwupgrade.it/forum/showthread.php?t=1671120

[k0nt3]

Originariamente inviato da Matrixbob

Pensa che io pensavo fosse JSP/Servlet/Tomcat ...
CMQ mi ricodo che 8 anni fa cercavano programmatori Java con J2ee ed adesso cercano ancora quelli.
Come mai? Siamo sempre alla rincorsa di qualcosa?

in effetti è jsp/servlet/java beans ecc.. JEE non è altro che una specifica in realtà. poi i vari tomcat, jboss, glassfish implementano più o meno parti di questa specifica

[fek]

Originariamente inviato da cdimauro

Solo io? http://www.hwupgrade.it/forum/showthread.php?t=1671120

Ma Gunnerson non e' uno zelota

[k0nt3]

Originariamente inviato da cdimauro

Hai dimenticato SmallTalk.

no per me non è un linguaggio adatto. forse perchè lo conosco molto poco, ma visto che sono in buona compagnia ci sarà un motivo

Originariamente inviato da cdimauro

Ne abbiamo già discusso n volte, con n sufficientemente grande da non lasciar dubbi su com'è fatto Python e come funziona, ma vedo che puntualmente ritorni con lo stesso ritornello.

Ripeti con me: in Python ogni elemento è un oggetto e ciò che si può fare (leggi: i paradigmi che si possono usare) dipende strettamente dal modo in cui li usi.

python è e sarà sempre multiparadigma

[AnonimoVeneziano]

Originariamente inviato da cdimauro

Questo è niente: in genere sono decisamente più prolisso.

Ahimè ... lo so

Io non parlavo di potenza, ma di modellazione della realtà.

E cos'è la potenza di un linguaggio se non la sua capacità di modellare la realtà? (del problema)

OK, ma non è detto che sia quella giusta.

Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Io faccio una classe che contiene e gestisce degli elementi. Inizialmente per implementare questo comportamento uso una lista (in python) come attributo, poi però l'implementatore della classe si accorge di non avere bisogno di una lista perchè la classe non deve modificare gli elementi, così decide di cambiare l'implementazione usando una tupla.
Con accesso libero ai membri niente vieta ad un cliente della classe di prendersi la lista e farci un "obj.attributo.append(x)" che , dopo il cambiamento da lista a tupla diventerà un espressione invalida. Definendo l'attributo come private e regolando l'accesso allo stesso attraverso dei metodi si sarebbe potuto evitare questo inconveniente.

Li consente, ma arrivarci è tutto un altro paio di maniche.

Beh, se li consente allora didatticamente è meglio un linguaggio che non li consente

Didatticamente è più semplice e naturale imparare il concetto che una classe possa ereditare da più classi, piuttosto che possa ereditare da una sola classe ed eventualmente implementare una o più interfacce.
Poi, come hai detto, si può anche fare a meno dell'ereditarietà multipla (e io generalmente ne faccio a meno, ma in alcuni casi m'è tornata molto comoda e utile).

Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile

Emulazione è un modo di dire: con l'ereditarietà multipla posso modellare "quello che voglio", per cui anche il comportamento delle interfacce.

Non puoi negare che però è più chiaro in Java perchè c'è un elemento facente parte del linguaggio apposito per rappresentarle. Quando ho imparato il C++ (mio primo linguaggio OO) non ho capito immediatamente a che servissero le classi astratte. Dopo aver imparato il Java e averlo usato un po' in OO mi è stato subito chiaro.

Utilizzare delle classi (con l'ereditarietà multipla) per definire un "comportamento" non è un'emulazione né tanto meno una loro "castrazione", ma una precisa scelta di design.

Precisa, ma per me è più caotica

Ed è una cosa che puoi fare (e, anzi, generalmente si fa) benissimo in Python: quando dichiari una classe definisci anche i suoi attribuiti e/o metodi esattamente come faresti con Java, C#, C++, Delphi o qualunque altro linguaggio OO "tradizionale".

IN PIU' hai la possibilità di cambiare il comportamento di singole istanze o di un'intera classe a runtime, se il modello del tuo progetto lo prevede oppure ti accorgi che lo semplifica (il modello).

Riassumendo il tutto: con Python non hai nulla di meno di quanto offrono linguaggi come Java in termini di modellazione di una soluzione tramite il concetto di oggetto. Anzi, hai una semplificazione (grazie anche al weak typing) ed eventualmente degli strumenti aggiuntivi.

Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.

Ciao

[cdimauro]

Originariamente inviato da fek

Ma Gunnerson non e' uno zelota

Ehm, veramente mi riferivo a te che tiri spesso in ballo Gunnerson, Fowler, (Santo. Subito!) Kent, ecc.

[cdimauro]

Originariamente inviato da k0nt3

no per me non è un linguaggio adatto. forse perchè lo conosco molto poco, ma visto che sono in buona compagnia ci sarà un motivo

Il motivo per cui l'ho tirato in ballo è perché è semplice vedere in SmallTalk il concetto di passaggio dei messaggi fra le istanze, che sono la pietra miliare della programmazione OO.

python è e sarà sempre multiparadigma

Non hai ancora capito il perché, però...

Un po' come il linguaggio macchina: ci puoi fare tutto, anche la metaprogrammazione. Chissà perché...

[marco.r]

Originariamente inviato da AnonimoVeneziano

PS = Ah, un altra cosa. Python permette letteralmente di aggiungere attributi e metodi dopo che la classe è stata instanziata ... anche questo non mi piace molto a livello di rigorosità del paradigma object oriented.

E in che modo questo va contro il paradigma object oriented ?
Tanto piu' che nel padre dei linguaggi OO (Smalltalk) e' una cosa assolutamente naturale.

Ammetto pero' di essere di parte, in quanto sono un amante del duck typing e riesco ad apprezzare vincoli piu' statici solo in linguaggi che implementano un sistema di tipi decente (il che ne esclude la maggior parte, C++, Java e C# compresi).

[AnonimoVeneziano]

Originariamente inviato da marco.r

E in che modo questo va contro il paradigma object oriented ?
Tanto piu' che nel padre dei linguaggi OO (Smalltalk) e' una cosa assolutamente naturale.

Mi sono espresso male.
Parlavo di "rigorosità" in senso didattico. A mio parere più un linguaggio è rigido e definisce bene ciò che vuole esprimere con le sue strutture sintattiche e più è adatto all'insegnamento , aldilà della capacità espressiva grezza del linguaggio stesso. Tanto per intenderci all'epoca il pascal era uno di quelli.

Ammetto pero' di essere di parte, in quanto sono un amante del duck typing e riesco ad apprezzare vincoli piu' statici solo in linguaggi che implementano un sistema di tipi decente (il che ne esclude la maggior parte, C++, Java e C# compresi).

Proprio perchè il duck typing è il sinonimo stesso di quella poca rigidità didattica di cui ho parlato poco sopra preferisco consigliare Java al nostro thread starter

[cdimauro]

Originariamente inviato da AnonimoVeneziano

Ahimè ... lo so

Ah. Sei fortunato che non sono in vena oggi.

E cos'è la potenza di un linguaggio se non la sua capacità di modellare la realtà? (del problema)

Se vuoi usare questa definizione mi sta bene, ma non era mia intenzione spostare la discussione sul concetto di "potenza", perché si tende a svilire i concetti di cui si parla.

Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.
Io faccio una classe che contiene e gestisce degli elementi. Inizialmente per implementare questo comportamento uso una lista (in python) come attributo, poi però l'implementatore della classe si accorge di non avere bisogno di una lista perchè la classe non deve modificare gli elementi, così decide di cambiare l'implementazione usando una tupla.
Con accesso libero ai membri niente vieta ad un cliente della classe di prendersi la lista e farci un "obj.attributo.append(x)" che , dopo il cambiamento da lista a tupla diventerà un espressione invalida. Definendo l'attributo come private e regolando l'accesso allo stesso attraverso dei metodi si sarebbe potuto evitare questo inconveniente.

Chiaro, ma se permetti trovo sia decisamente peggio che un errore di design del progettista della classe mi porti a non poterla sfruttare (e subclassare) per risolvere i miei problemi.

Purtroppo è una cosa che m'è capitata non poche volte.

Beh, se li consente allora didatticamente è meglio un linguaggio che non li consente

Se parti subito con l'ereditarietà multipla, può succedere. Ma un principiante ha ben altro a cui pensare all'inizio.

Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile

Puoi essere contro l'ereditarietà multipla, e posso anche essere comprenderlo, ma è più facile apprendere "naturalmente" questo concetto piuttosto che quello di ereditarietà singola + interfacce.

Poi sui problemi di design sono d'accordo: non avendo maturato adeguatamente lo strumento potrebbero presentarsi più facilmente nel primo caso piuttosto che nel secondo (ma anche col secondo è facile farsi scappare la mano e tirare fuori interfacce per la qualunque, anche quando non ce ne sarebbe bisogno ).

Non puoi negare che però è più chiaro in Java perchè c'è un elemento facente parte del linguaggio apposito per rappresentarle.

Sì, non ho difficoltà ad ammetterlo.

Quando ho imparato il C++ (mio primo linguaggio OO) non ho capito immediatamente a che servissero le classi astratte. Dopo aver imparato il Java e averlo usato un po' in OO mi è stato subito chiaro.

Ma le classi astratte non ci sono anche in Java?

Precisa, ma per me è più caotica

Solo se la usi male, ma non era questo il punto.

Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.

Ciao

Indubbiamente, ma si tratta di argomenti più avanzati, ed è bene che siano affrontati in un secondo momento. Un po' come le interfacce che si studiano dopo aver appreso il concetto di classe e di ereditarietà.

Ciao. Anzi: notte.

[^TiGeRShArK^]

Originariamente inviato da fek

Ormai sei peggio di Criceto con Apple

[marco.r]

Originariamente inviato da AnonimoVeneziano

Beh, per quanto mi riguarda il permettere di accedere certi attributi solo in maniera privata può essere molto utile.

Il comportamento di python non e' che mi piaccia molto in questo senso, ma non e' cosi' grave, soprattutto se si segue un certo criterio. In particolare e' prassi considerare privati tutti gli attributi di istanza che cominciano con un doppio underscore, tanto piu' che poi vengono visti con dei nomi particolari (ad esempio l'attributo __x della classe Foo viene visto dall'esterno come _Foo__x o giu' di li'). Andare a toccarli vuol dire andare scientemente in cerca di rogne.

Sinceramente non ne vedo il motivo. Io sono contro all'ereditarietà multipla perchè può portare ad errori in generale, non perchè è facile o difficile da apprendere. La possibilità di design errato usando l'ereditarietà multipla è sicuramente maggiore rispetto a quando non la si usa. Chiaro che se uno ha acquisito dimestichezza col paradigma non succede, ma stiamo parlando di principianti, e per un principiante è facile

Ci sono dei casi in cui torna comoda (potrei portare un paio di esempi), anche se tipicamente non serve poi molto in un linguaggio dinamico.

Non ho mai detto che con python hai qualcosa in meno (ritorniamo al discorso di potenza espressiva), sto solo dicendo che tutte queste possibilità (di definire gli attributi nella definizione della classe, dentro il costruttore, dentro i metodi, addirittura dopo l'instanziamento a runtime: praticamente ovunque si ha un reference alla istanza di classe) possono creare confusione al neo-programmatore OO.

Non direi. Dall'altra parte abbiamo classi ed interfacce, tipi, attributi e metodi privati piuttosto che pubblici etc... non mi sembra meno complicato.
E' anche una questione di punto di vista. In python puoi definire gli attributi quando vuoi, basta avere l'oggetto sottomano. Punto. Non mi sembra complicato, quelli che elenchi sono casi particolari (a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo...).

[AnonimoVeneziano]

Originariamente inviato da cdimauro

Ah. Sei fortunato che non sono in vena oggi.

Se vuoi usare questa definizione mi sta bene, ma non era mia intenzione spostare la discussione sul concetto di "potenza", perché si tende a svilire i concetti di cui si parla.

Beh, "potenza" è una parola che se usata nella sezione "Console e giochi per console" , magari con un PS3 e Xbox360 inserite nel contesto, può dare luogo ad un conflitto mondiale
In questo contesto speravo fosse un po' meno equivocabile, ma per me va bene continuare ad usare il termine "capacità espressiva" o al max "potere espressivo"

Chiaro, ma se permetti trovo sia decisamente peggio che un errore di design del progettista della classe mi porti a non poterla sfruttare (e subclassare) per risolvere i miei problemi.

Beh, gli errori di design possono capitare. Il vantaggio è che con la visibilità puoi comunque permettere ai clienti di accedere agli attributi private (basta creare dei metodi getter e setter), ma nel contempo gli permetti di farlo solo in modo sicuro. Cambia l'implementazione interna dell'attributo? Cambi anche implementazione di getter e setter di conseguenza. L'interfaccia all'oggetto non cambia e il codice rimane compatibile. Con la visibilità permetti all'utilizzatore di vedere solo il comportamento della classe e non quello che ci sta sotto il cofano (che può cambiare quanto vuoi, basta che il comportamento della classe attraverso i metodi sia lo stesso )

Se parti subito con l'ereditarietà multipla, può succedere. Ma un principiante ha ben altro a cui pensare all'inizio.

Appunto, lasciamoglielo per quando imparerà il python

Puoi essere contro l'ereditarietà multipla, e posso anche essere comprenderlo, ma è più facile apprendere "naturalmente" questo concetto piuttosto che quello di ereditarietà singola + interfacce.

Mah, non ne sono così convinto...

Comunque per me non è una questione di naturalezza o meno nell'apprendimento. Converrai con me che una volta capito cos'è l'ereditarietà , che è la parte difficile, l'apprendere l'ereditarietà singola o multipla non è difficile. All'inizio è solo una regola : "Non puoi ereditare da più di una classe" . Il significato viene da se dopo

Poi sui problemi di design sono d'accordo: non avendo maturato adeguatamente lo strumento potrebbero presentarsi più facilmente nel primo caso piuttosto che nel secondo (ma anche col secondo è facile farsi scappare la mano e tirare fuori interfacce per la qualunque, anche quando non ce ne sarebbe bisogno ).

Beh, sono d'accordo. Si possono fare pasticci con tutto

Ma le classi astratte non ci sono anche in Java?

Beh, stavamo parlando di interfacce e visto che in C++ non esistono come concetto l'unico modo per "emularle" è l'uso di classi astratte con solo metodi virtual puri

Indubbiamente, ma si tratta di argomenti più avanzati, ed è bene che siano affrontati in un secondo momento. Un po' come le interfacce che si studiano dopo aver appreso il concetto di classe e di ereditarietà.

Si, ma il fatto che sia possibile già per me significa che non c'è la rigidità tipica che aiuta tanto nell'apprendimento.
Python è un linguaggio che mi piace, lo ammetto. Odio di esso solo la sintassi e certe scelte , come ad esempio quella di permettere certi costrutti che se usati impropriamente possono veramente rendere un programma illeggibile e vietare scritture come "+=" , "*=", ... etc usando come scusa che diminuiscono la leggibilità

Ciao. Anzi: notte.

Notte

[AnonimoVeneziano]

Originariamente inviato da marco.r

Il comportamento di python non e' che mi piaccia molto in questo senso, ma non e' cosi' grave, soprattutto se si segue un certo criterio. In particolare e' prassi considerare privati tutti gli attributi di istanza che cominciano con un doppio underscore, tanto piu' che poi vengono visti con dei nomi particolari (ad esempio l'attributo __x della classe Foo viene visto dall'esterno come _Foo__x o giu' di li'). Andare a toccarli vuol dire andare scientemente in cerca di rogne.

Tralasciando il fatto che ABBBBBBBBBBBBORRRRRRRO ( con B e R a piacere ) tutto ciò che in python è scritto con doppio underscore (ed è uno dei motivi che mi fa odiare la sintassi python ), concordo con te che è un comportamento "non critico" se si segue una certa convenzione...
Certo, a mio parere le costrizioni sono meglio delle convenzioni, anche se in parte ti limitano la libertà (basta che siano a fin di bene), ma è ancora più vero se tutto ciò è a fini didattici. Visto che il thread starter voleva un linguaggio con cui imparare l'OO credo che un po' di "costrizioni buone" possano fargli solo bene.

Ci sono dei casi in cui torna comoda (potrei portare un paio di esempi), anche se tipicamente non serve poi molto in un linguaggio dinamico.

Non ne dubito, comunque è sempre rimpiazzabile.

Non direi. Dall'altra parte abbiamo classi ed interfacce, tipi, attributi e metodi privati piuttosto che pubblici etc... non mi sembra meno complicato.
E' anche una questione di punto di vista. In python puoi definire gli attributi quando vuoi, basta avere l'oggetto sottomano. Punto. Non mi sembra complicato, quelli che elenchi sono casi particolari (a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo...).

Non è una questione di complicato o meno nell'imparare un linguaggio. Imparare un linguaggio in genere è piuttosto semplice (per uno che ha già programmato), il problema è acquisire la forma mentis del programmatore OO. Anche se il Java (forse) nella sintassi è un po' più complicato, vuoi perchè deriva dal C, vuoi perchè è un linguaggio più "classico" mentre Python è un linguaggio di scripting dove in genere la semplicità , la velocità di scrittura del codice e la compattezza sono componenti fondamentali ... etc non vuol dire che sia più facile imparare il paradigma OO col Python che col Java. Io ritengo personalmente che sia il contrario, perchè il Java ti guida di più nell'apprendimento. Inoltre Matrixbob viene dal C. Imparare la sintassi di Java e la tipizzazione forte per lui non dovrebbe proprio essere un problema (anzi, potrebbe di più esserlo l'apprendimento della tipizzazione dinamica del python). Inoltre voleva trovare un posto di lavoro e sicuramente qua Java la fa da padrone su tutti.

EDIT: Ah, scusa, mi sono dimenticato una cosa ...

a parte il primo: non si possono definire attributi di istanza nella definizione della classe, e d'altra parte non si ha alcuna istanza sottomano per farlo..

io intendo questo

 class classe2:
	a = [1,2]
	def __init__(self):
		return

>>> b = classe2()
>>> b.a
[1, 2]

Ciao

[cdimauro]

Originariamente inviato da AnonimoVeneziano

Beh, "potenza" è una parola che se usata nella sezione "Console e giochi per console" , magari con un PS3 e Xbox360 inserite nel contesto, può dare luogo ad un conflitto mondiale

Non mi tentare...

In questo contesto speravo fosse un po' meno equivocabile, ma per me va bene continuare ad usare il termine "capacità espressiva" o al max "potere espressivo"

OK

Beh, gli errori di design possono capitare. Il vantaggio è che con la visibilità puoi comunque permettere ai clienti di accedere agli attributi private (basta creare dei metodi getter e setter), ma nel contempo gli permetti di farlo solo in modo sicuro. Cambia l'implementazione interna dell'attributo? Cambi anche implementazione di getter e setter di conseguenza. L'interfaccia all'oggetto non cambia e il codice rimane compatibile. Con la visibilità permetti all'utilizzatore di vedere solo il comportamento della classe e non quello che ci sta sotto il cofano (che può cambiare quanto vuoi, basta che il comportamento della classe attraverso i metodi sia lo stesso )

Il problema (che m'è capitato, diverse volte) è quando anche coi getter e setter non riesci a modificare delle proprietà perché il designer le ha "nascoste" ed è impossibile riuscire a metterci mano (soltanto giocando veramente molto sporco, ma mi sono sempre rifiutato), per cui ho dovuto desistere (o crearmi un componente ex-novo che lavorasse come volevo).

Appunto, lasciamoglielo per quando imparerà il python

No no: Python lo impara da subito, ma questa cosa soltanto dopo aver maturato abbastanza il linguaggio.

Mah, non ne sono così convinto...

Comunque per me non è una questione di naturalezza o meno nell'apprendimento. Converrai con me che una volta capito cos'è l'ereditarietà , che è la parte difficile, l'apprendere l'ereditarietà singola o multipla non è difficile. All'inizio è solo una regola : "Non puoi ereditare da più di una classe" . Il significato viene da se dopo

Sì ma stai mettendo sul piatto più cose: il concetto di interfaccia (che è diverso da quello di classe), il fatto che un oggetto possa discendere da una sola classe, e infine quello che può opzionalmente implementare più interfacce.

L'ereditarietà multipla è "naturalmente semplice" da apprendere perché si ferma a una sola regola: una classe può ereditare da una o più classi.

E facendo l'esempietto del gatto che è un felino ed è pure un mammifero, oppure del carro armato che è composto da un carro e da un cannone, se ne esce fuori abbastanza agevolmente (sono due esempi del kaiser, ma a chi è digiuno di programmazione servono cose terra-terra per comprendere velocemente concetti come questo ).

Beh, sono d'accordo. Si possono fare pasticci con tutto

Specialmente in PERL & derivati.

Beh, stavamo parlando di interfacce e visto che in C++ non esistono come concetto l'unico modo per "emularle" è l'uso di classi astratte con solo metodi virtual puri

Ah, ok, non avevo afferrato l'esempio prima.

Si, ma il fatto che sia possibile già per me significa che non c'è la rigidità tipica che aiuta tanto nell'apprendimento.

Punti di vista: tante volte la rigidità è un limite e un problema per l'apprendimento.

Ad esempio se prendiamo i numeri interi, linguaggi come Java hanno dei tipi base limitati, mentre noi esseri umani siamo abituati a pensare e trattare numeri "virtualmente illimitati".
Con Python quando usi un interi non ti preoccupi di quanto spazio e fino a quale numero puoi rappresentare: li usi e basta.
Con Java, dopo esserti sorbito il concetto di dimensione di byte, short, long, poi ti viene detto che se ti serve rappresentare numeri più grandi devi ricorrere a BigInt (o BigInteger, adesso non ricordo): quindi per lavorare con gli interi "a 360°" hai bisogno di conoscere 4 cose.

Python è un linguaggio che mi piace, lo ammetto. Odio di esso solo la sintassi e certe scelte , come ad esempio quella di permettere certi costrutti che se usati impropriamente possono veramente rendere un programma illeggibile

Sono pochi, e comunque cose come le list comprehension sono "naturali" per chi ha un'infarinatura di matematica.

e vietare scritture come "+=" , "*=", ... etc usando come scusa che diminuiscono la leggibilità

Notte

Veramente quegli operatori Python li ha. Sono stati aggiunti relativamente tardi nel linguaggio, ma ci sono e li puoi usare tranquillamente anche nelle tue classi (con l'overloading degli operatori).

Personalmente tendo a usarli poco perché sono troppo C-like, e IMHO abbassano troppo la leggibilità del codice.
A questo

Count += 1

preferisco decisamente questo:

Count = Count + 1