Odio più i “piuttosto che” o i “quant’altro”?

Beh, prima o poi dovevo cominciare a scrivere delle cose che odio, visto che il blog si chiama "Legendary Diplomacy" :)

Non so se ci avete fatto caso, ma l'informatico in prevendita, o più in generale nelle riunioni (più spesso in quelle in giacca e cravatta), adotta un linguaggio un po' diverso dal suo solito, un linguaggio con cui cerca di darsi un tono. Non solo l'informatico, certamente: ma purtroppo frequento quasi esclusivamente questa bistrattata categoria...

Tipicamente nei discorsi del prevenditore in azione troverete avverbi inutili, oscure espressioni pseudo-anglosassoneggianti che pretende tutti capiscano, snobismi vari e più in generale parole artificialmente forbite che hanno sinonimi molto più semplici ed immediati. Penso la cosa sia in fondo piuttosto normale, poichè nelle riunioni spesso si cerca di apparire più fighi ed intelligenti di quello che si è veramente. E nelle riunioni in cui si cerca di vendere qualcosa ovviamente molto di più.

Ma in tutto questo [normale] fastidio ci sono però alcune espressioni veramente antipatiche, parole che mi danno letteralmente il voltastomaco e che passano il confine del semplice irritamento cerebrale:


  • Piuttosto che

  • Quant'altro



Frase tipica: "Beh, qui il prodotto usa hibernate, e come ben sapete con hibernate potete usare MySql [pausa artificiale] piuttosto che Postgres [pausa artificiale un po più lunga] piuttosto che Oracle, [qui fa la faccia navigata, del tipo che ha la tecnologia in mano, li sa tutti ma non serve dirli] o quant'altro"

A questo punto di solito mi voglio alzare ed urlare, ed ultimamente mi trattengo sempre più a fatica. "Piuttosto che" in italiano non ha valore disgiuntivo, non è sinonimo di "oppure". Manco per sogno. Si usa per dire "Piuttosto che comprare il tuo prodotto, mi faccio frate", ossia esprime come minimo una forte preferenza, se non addirittura una scelta già fatta od obbligata. Usarlo come disgiuntivo è un vezzo snob, ed è pure sbajato. Secondo Beppe Severgnini il mostriciattolo "piuttosto che" è di provenienza "agiato settentrionale", ma credo che ormai abbia invaso tutta l'Italia.

"Quant'altro" invece non so proprio da dove venga e perchè. Forse il neosnob, memore dell'avvertimento della maestra delle elementari di non concludere mai le frasi con eccetera, pensa di trovare salvezza in questa schifezza? Suvvia, diciamo eccetera, o meglio ancora non diciamo niente. Oppure concludiamo con una bella ricorsione infinita così il cervello va in tilt e il problema è risolto alla radice.

Ora mi sento molto meglio: ho messo giù i miei pensieri sconnessi e mi rendo conto chiaramente che odio molto di più i "piuttosto che" che i "quant'altro". E' già un bel risultato, no?
Comments (3) Show Comments

Idiomatica #1: il polimorfismo dei poveri

Comincerò a postare regolarmente il materiale pubblicato sulla versione cartacea di JavaJournal . Questo è il primo numero della rubrica.

Voglio cominciare questa rubrica con una “worst practice” fra le più orribili, il polimorfismo dei poveri. Non che non abbia materiale a disposizione per decine e decine di rubriche, e centinaia di esempi di come non si dovrebbe scrivere del codice in Java... ma questa particolare pratica, oltre a essere veramente brutta, ha delle caratteristiche che secondo me la rendono unica. E per questo deve avere l'onore del primo numero di questa rubrica dedicata alle brutture nel design.



  • E' assolutamente non necessaria, e l'alternativa è nell'abc della programmazione ad oggetti

  • Non offre nessun vantaggio particolare rispetto all'alternativa corretta, ma solo svantaggi. Altre brutture perlomeno hanno una qualche giustificazione più o meno fondata, questa no.

  • E' incredibilmente diffusa





Il polimorfismo dei poveri è caratterizzato da codice simile a questo:



if (a instanceof b) {

// fai qualcosa

} else if (a instanceof c) {

// faiqualche altra cosa

}



Ora, gia' l'uso di instanceof di per se' è criticabile: instanceof in un linguaggio ad oggetti non dovrebbe mai essere usato, se non in un caso particolare che lascio come simpatico esercizio agli amici lettori.

Ma usare instanceof per fare eseguire logiche diverse ad un oggetto a seconda del suo tipo, è veramente abominevole: a cosa serve il polimorfismo – che fa esattamente la stessa cosa - se poi devo ricostruirmelo malamente da solo? Notare che il fatto che l'operazione sia eseguita sullo lo stesso oggetto su cui si è operata la condizione o su un altro è irrilevante: in quest'ultimo caso è solo segno di un cattivo assegnamento di responsabilità e della necessità di spostare l'eventuale metodo al posto giusto.


a.faiQualcosa()


E' evidente come il vero polimorfismo sia infinitamente superiore alla sua brutta copia: l'”if” viene fatto dal runtime automaticamente, e voi non dovete fare nulla di particolare se non usare degli oggetti in maniera polimorfa. Il polimorfismo dei poveri invece va invece mantenuto, ogni volta che si introducono nuovi tipi e nuove logiche: di solito fra l'altro questo tipo di strutture condizionali si trovano ripetute in diversi punti del codice, poichè è molto comune che esistano diverse logiche da eseguire, rendendo l'introduzione di bug così probabile da essere quasi scontata. Il vero polimorfismo invece vi permette semplicemente di aggiungere nuovi metodi per ogni nuova logica, concentrando così in unico punto tutto ciò che ha gli stessi motivi per cambiare.

Eseguite per curiosità un bel


grep -R instanceof .


nella directory demo del vostro JDK, e troverete molti esempi di poliformismo dei poveri. Sembra che Swing sia un portatore (sano?) di polimorfismo dei poveri!

Permettetemi di riformulare il concetto in maniera più immediata: se trovate del codice che usa “il polimorfismo dei poveri”, è codice strutturato e non codice ad oggetti. Che sia nelle librerie di java, che l'autore sia considerato un guru, che sia uno dei software open più blasonati, che l'abbiate trovato su un libro (di solito di API, non certo di design), o che l'abbiate scritto voi stessi in quello che considerate il vostro capolavoro di programmazione ad oggetti, non cambia la sostanza: non sarà che in 20 anni questa benedetta programmazione ad oggetti a molti non è ancora entrata in testa?

Esercizi:
Eliminare il polimorfismo dei poveri da uno qualsiasi degli esempi Swing del jdk. Come dite? Eh no, così bisogna rivedere le gerarchie... e poi inserire nuove interfacce. E poi bisogna eliminare quelle istanziazioni di oggetti concreti... bene, quella si chiama programmazione ad oggetti.
Ora salutate con la manina quella brutta e vecchia programmazione strutturata, e cercate di lasciarvela per sempre alle spalle!

Conclusioni:
Il polimorfismo dei poveri è una delle peggiori pratiche che si possa adottare per avere codice difficilmente manutenibile, inutilmente complicato e soggetto a bug. Il polimorfismo dei poveri indica inoltre che non state sfruttando la potenza degli oggetti. Se siete pagati per linee di codice, o per bug risolti, usatelo pure liberamente! Ma se poi vi trovate nei guai, non dite che nessuno vi aveva avvertito...
Comments