# 5 problemi della programmazione orientata agli oggetti
La programmazione orientata agli oggetti ha certamente dato un forte contributo alla tecnologia. Tuttavia, nonostante sia facile da imparare ed intuitiva, porta con sé un numero di problemi che compaiono in maniera ricorrente anche quando viene usata in maniera corretta.
# 1. Maggiore complessità
Nella programmazione object oriented noi pensiamo agli oggetti come contenitori di informazioni oltre che di comportamenti. Queste informazioni cambiano nel tempo ed è complesso tenere traccia di come i dati contenuti negli oggetti varino nel tempo.
Nella programmazione funzionale la dimensione temporale viene eliminata. Gli array e altre strutture dati sono immutabili. Non è necessario chiedersi cosa contenga una data variabile nel tempo perché questa non cambia mai.
A Zena Software abbiamo tratto enorme vantaggio da questa semplificazione ottenendo cicli di manutenzione più brevi grazie a codice più leggibile.
# 2. Codice non modulare
La programmazione ad oggetti si prefigge come primo scopo quello di avere più modularità e separazione degli interessi. Paradossalmente questo avviene solo per programmi relativamente semplici. Quando i software crescono, gli oggetti tendono ad intrecciarsi tra di loro in una matassa confusa. Questo perché è difficile mantenere la disciplina (pensiamo a SOLID o GRASP) quando si ha a che fare con scadenze e pressione di rilascio.
Con la programmazione funzionale si ottiene una modularità per costruzione. Ogni funzione accetta un input e restituisce un output. Le possibilità di sbagliarsi sono ridotte all’osso in quanto per collegare due funzioni esistono un numero molto ristretto di modi per farlo. Il più semplice, la composizione di funzioni, rende il codice molto leggibile e modulare oltre che riutilizzabile.
# 3. Refactoring impegnativo
Il refactoring del codice dovrebbe essere effettuato ad intervalli regolari per recuperare il debito tecnologico. Purtroppo nella programmazione ad oggetti si tratta di un compito tedioso. Il problema principale sta nel fatto che spostando un pezzo di codice nel programma non sempre si ha la garanzia che tutto continui a funzionare come prima.
La programmazione funzionale ha una proprietà chiamata trasparenza referenziale. Secondo questa proprietà posso sempre sostituire un’intera funzione con il valore che essa restituisce. Esattamente come in matematica, posso sostituire intere porzioni di codice a cuor leggero, sapendo che il comportamento del programma rimarrà invariato.
In Zena Software questo, in combinazione con una buona copertura di testing, ci permette di passare una buona porzione di tempo a lavorare su codice di alta qualità che rispecchia meglio il business.
# 4. Arduo da testare
Per testare un oggetto bisogna procurarsi tutte le dipendenze per istanziarlo e creare i vari collaboratori (e quindi le loro dipendenze). Spesso i metodi da testare non espongono un’interfaccia adatta al testing e questo porta ad usare mock, stub e variabili temporanee. Ispezionare il risultato del test può presentare ulteriori problemi in caso di chiamate asincrone.
Per testare una funzione non bisogna inventarsi niente. Inserisci un input, controlla l'output. Nei casi in cui le funzioni siano impure, cioè interagiscono con il mondo esterno (ad esempio salvare un file) è possibile modificare parti dell’implementazione per il testing (nell esempio del file, si può scrivere in una locazione della memoria).
# 5. Totalmente imprevedibile
I metodi di un oggetto possono fare qualunque cosa, possono scrivere un file su disco, mandare un e-mail o lanciare un razzo nucleare. Non è mai possibile saperlo senza leggere il codice.
Una funzione pura è invece molto più noiosa: dato un input restituisce un output. Estremamente prevedibile. Nei pochi casi in cui la funzione interagisce con il mondo esterno è chiaramente specificato nella segnatura (questo in realtà dipende dal linguaggio di programmazione).
# Conclusione
Certamente tutti questi vantaggi non sono senza un prezzo da pagare, usare la programmazione funzionale richiede un addestramento specifico e una conoscenza di base di teoria delle categorie. Zena Software offre questo e altro per garantire i più elevati standard di programmazione.
Andrea Passaglia (opens new window)