[Python] Classi (Was: Walks like Python. Runs like C.)

[enrico franchi]

2015-01-14 13:12 GMT+00:00 Carlos Catucci <carlos.catucci a gmail.com>:

>
> Personalmente io parlavo di usarla io, per le mie classi, dove so bene
> cosa faccio e difficilmente eredito per piu' di tre livelli
> (ancestor<-father<-son).
>

3 livelli sono gia' tantissimi, veh.


> Nell'esempio da lui citato si parla di 20 classi (neppure tutte ancestor,
> ovvero root dell'albero al di sotto di Objects) e 400 e passa metodi.
> Grazie, si e' scelto un esempio calzante ma non e' che tutto funzioni in
> quel modo.
>

Si, e li e' dove vedi il fallimento spettacolare. Ma anche quando dici:

"""
Ecco questo punto, come dire, io ho sempre adorato l'ereditarieta'
multipla, Magari e' solo una questione di design che sbaglio io, ma
preferisco avere tante piccole classi anche "astratte"da usare come
mattoncini lego per comstruire classi piu' complesse. Magari deriva dal
fatto che il mio rimo linguaggio sia stato il Forth?
"""

a primo pelo verrebbe da dire che stai sbagliando tutto il design. Se vuoi
comporre cose a partire da elementi base, usi appunto la composizione, non
l'ereditarieta'. L'ereditarieta' e' un metodo inerentemente piu' statico (a
meno di non fare porcate aggiuntive, che lasciamo per esercizio al lettore)
ed estremamente meno flessibile. Inoltre pone un livello di accoppiamento
estremamente piu' alto fra le entita' coinvolte.

Da quello che scrivi, quello che fai, si farebbe meglio usando semplice
composizione. Il "fallimento" dell'OOP come tecnica per il riuso e la
manutensibilita' negli anni 90 e' proprio legato a questo abuso
dell'ereditarieta' in tale direzione.

Di fatto la maggior parte degli usi "sani" dell'ereditarieta' sono legati
al volere avere una qualche forma di supporto per implementare interfacce
comuni (eventualmente aperte), potenzialmente con qualche forma ti template
method pattern. E anche li i tradeoff con uno strategy puro non sono
necessariamente in favore di tmp. E nota che sono tutti esempi in cui hai
essenzialmente progettato il tuo codice per funzionare tramite estensione
per ereditarieta': la stessa cosa fatta su codice non pensato in tal senso
non funziona altrettanto bene.

Resto per ora della mia idea, che sia preferibile avere l'E.M. usandola cum
> grano salis, piuttosto che non averla e dovrr imoazzire poi per
> implementare una forma bastrada (chi ha detto Java?).
>

Fatico a pensare a molti posti in cui ho usato ereditarieta' multipla e
soprattutto fatico a ricordare casi in cui non avendola mi e' davvero
mancata. In pratica, l'unico caso che mi viene e' per implementare cose
tipo i mixin, con tutti i problemi che si portano dietro (quindi di rado,
in casi molto limitati e pensati con attenzione).

Poi io non sono certo di quelli che trovano che il linguaggio debba essere
reso cretino per impedire ai cretini di fare danni, quindi non ho veramente
problemi con features chiacchierate. Semplicemente so quando si possono
usare e quando assolutamente e' una pessima idea.

Ma questo non vuole dire che MI sia qualcosa di cui ci sia effettivamente
bisogno (o che sia utile) nel semplificare un gran numero di use-case
comuni. E' una feature oggettivamente pericolosa, di cui e' facile abusare.
Il suo pregio e' che e' sufficientemente generale da risolvere un buon
numero di casi con una sola feature del linguaggio (rispetto per esempio
introdurre i semplici mixin che alla fine dei conti sono quasi ugualmente
pericolosi, hanno una fama molto migliore e quindi sono ancora piu' proni
all'abuso, e che a quel punto ci vuole anche una qualche forma di
ereditarieta' delle interfacce verosimilmente multipla pure lei, etc etc).
E allora se devo avere 2-3 feature potenzialmente rischiose da incrociare
per fare  la stessa cosa, tanto vale MI e ci staro' attento.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150114/7cc12bf2/attachment.html>