<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-14 13:12 GMT+00:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br></div></div><div class="gmail_extra">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). <br></div></div></blockquote><div><br></div><div>3 livelli sono gia' tantissimi, veh.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">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. <br></div></div></blockquote><div><br></div><div>Si, e li e' dove vedi il fallimento spettacolare. Ma anche quando dici:</div><div><br></div><div>"""</div><div><span style="font-size:13px">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? </span><br></div><div><span style="font-size:13px">"""</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">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. </span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">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.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">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.</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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?). </div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>