Ancora su Kotlin e sul sexy coding.

Ciao a tutti amici!

Sono qui su Medium a calcare nuovamente la mano sul linguaggio di cui vi parlai in questo articolo: il Kotlin.

E’ passato un po’ da quando lo scrissi (già 10 mesi!) e nel frattempo il nostro bel Mr. K è evoluto parecchio. Ed io con lui.

Innanzitutto voglio dirvi che da quell’articolo non ho mai smesso di utilizzare questo linguaggio, avendolo approfondito un po’ sotto tutti gli aspetti.
Chi mi conosce, sa che è una cosa più unica che rara, siccome tendo sempre a muovermi verso qualcosa di migliore… ma in questo caso credo di aver centrato abbastanza il mio obiettivo.

Qualcuno si chiederà “Ma qual’è questo obiettivo di cui farnetichi?”. L’avrò detto un numero improponibile di volte nei miei articoli ed a chiunque mi abbia rivolto parola: il mio linguaggio perfetto è quello che permetta di scrivere software di qualsiasi tipo con una sintassi semplice, minimizzando al massimo il codice inutile e soprattutto che debba essere SEXY.

Sì, avete letto bene: sexy. Una donna può esserlo, un uomo può esserlo, una patata può esserlo ed anche un codice può esserlo.

Per spiegarvi cosa intendo per sexy coding, lasciate che vi faccia qualche esempio.

Il codice qui sopra è una normalissima classe Java, detta anche POJO. Come possiamo osservare, contiene una caterva di boilerplate code, cioè di codice che sarà identico per tutte le classi che scriveremo.
Getter, setter, iterazioni, quell’orrendo System.out.println, è codice che scriveremo per ogni nostra classe.

Questo cosa significa? Che il codice conterrà roba che non serve, brandelli di codice penzolanti e sempre uguali, che rendono il codice stesso pesante e noioso da leggere. Tutto ciò non è sexy.

“E allora cosa è sexy?” — sento già il tipo lì in fondo. 
La mia risposta? Beh, qualcosa del genere:

Quello che fa questa classe Kotlin è la perfetta copia di ciò che fa la classe Java vista prima. La differenza? Beh fate voi: niente più getter o setter, il System.out è stato importato direttamente nel codice, l’array di interi è stato inizializzato inline con la funzione (nativa di Kotlin) intArrayOf(). Il rapporto di codice è 35 linee a 11: il codice è ridotto a meno di un terzo.

So che qualcuno si starà chiedendo come venga rispettato il paradigma di incapsulamento e l’isolamento della rappresentazione interna della variabile, senza getter e setter. La risposta è che di per sé il “field” in Kotlin non è un campo, ma una proprietà, e cioè nasconde al suo interno un getter ed un setter comunque modificabili. Per chi volesse approfondire, lo rimando alla pagina della guida ufficiale di Kotlin dedicata alle properties.

Qui non stiamo parlando solo di una semplice migliorìa grafica, ma di una vera e propria rivoluzione per quanto riguarda la manutenibilità e la leggibilità del nostro codice.

Quante volte, ad esempio, ci è capitato di dover creare un Singleton, cioè una classe che verrà istanziata una sola volta, per poi essere utilizzata in giro per tutto il progetto? Perfetto, quindi avete una idea di quanto sia brutto farlo con Java:

Se proviamo a leggere il codice, a noi che abbiamo un buon occhio da sviluppatore esperto ci riesce abbastanza facile cogliere il significato di quella classe, ma non così immediato come dovrebbe essere. Stiamo creando una classe con un costruttore privato, ed un metodo statico getInstance() che controlla se l’istanza è già stata creata o deve essere ancora creata, restituendoci una nuova istanza, od una “riciclata”, della nostra classe.

Inoltre, ancora una volta abbiamo introdotto del boilerplate code che non ha senso di esistere, siccome per ogni classe che deve essere inizializzata in quel modo, ci sarà lo stesso identico pattern da seguire, e quindi, ripetendomi, brandelli di codice inutile.

Con Kotlin:

Non spendo altre parole per questo esempio.

Vorrei chiudere questo articolo testimoniando di stare utilizzando ormai quasi da un anno Kotlin in produzione, avendo rilasciato diverse app Android per lavoro e per progetti personali, totalmente scritte in questo bellissimo linguaggio.

Ormai ho soppiantato del tutto Java (infatti inizio quasi a dimenticare come sia fatto…) in ogni ambito: desktop, server e mobile.

Un giorno, forse, avremo un mondo con del codice migliore. #MakeSexyCode