La programmazione orientata agli oggetti è un modo di modellare la realtà in un ambiente astratto, virtuale, cioè fondamentalmente è un modo di pensare.
E' nata negli anni 80 per migliorare la qualità dei programmi, riducendo il codice ripetuto e le dimensioni della parte 'alta' del programma, cioè permette di concentrarsi sulla macro area, delegando i dettagli a parti che non si vedono.
Si creano dei componenti riutilizzabili, tali che sempre più spesso scrivere un programma diventa un assemblaggio di parti, privilegiando la manutenzione, spesso a dispetto delle prestazioni, ottenute grazie al miglioramento delle prestazioni dell'hardware moderno.
Anni fa si scatenò l'entusiasmo dell'industria informatica, che finalmente vedeva la possibilità di creare software con criteri industriali, cioè potendo finalmente ottenere risultati paragonabili con produzioni simili e con una certa attendibilità nelle stime dei tempi di sviluppo.
I più ottimisti immaginavano anche dei mercati di componenti software, più o meno come 30 anni dopo qualcuno immagina che ci possano essere dei servizi su Internet utilizzabili da applicazioni diverse, creando una sorta di "nuvola" dell'informazione.
Poi è successo qualcosa che ha inceppato questa visione quasi positivistica, mi si consenta, della realtà dello sviluppo: un uso semplice dei componenti implica una progettazione per nulla banale.
E qui viene il difficile: se la OOP è un modo di pensare, allora progettare bene significa pensare bene.
Pensare è un'attività difficile, che si impara con l'allenamento, in natura siamo istintivi. E' l'educazione e il duro allenamento alla logica che compiono il 'miracolo'. Poi ci sono persone più o meno portate, ma più spesso ci sono persone che sono state allenate prima dall'ambiente dove sono cresciute.
Progettare in OOP è un modo più naturale, rispetto alla programmazione procedurale, dove si "naviga a vista" nel codice, proprio perché si parte da un modello, cioè un'astrazione che mappa la realtà, ma chi non ci è abituato, spesso trova questo approccio difficile, si scoraggia e si trova ad essere molto meno produttivo di prima, magari perché applica male le tattiche della OOP.
Pensare, progettare, richiede Tempo. Purtroppo il tempo è una risorsa limitata nei progetti. Pochi stakeholder accettano che si spenda tempo in pensieri, anziché in azioni, quindi la fase di progettazione/studio è rilegata nella migliore delle ipotesi a qualche giorno all'inizio del progetto. Risultato: progetti che diventano un vero incubo e morale sotto i tacchi, responsabili che sentono traballare le loro seggiole e che cominciano ad innervosirsi e perdono la loro funzione di collante tra i membri del progetto.
La realtà è semplice nella sua tristezza: non è possibile determinare quanto tempo occorre per avere un'idea.
Le stime in questo caso sono una serie di approssimazioni. Si può stimare solo un lavoro simile ad uno (o più di uno) già di fatto.
Per ovviare a questo problema, l'industria (?) informatica sta virando dal periodo d'oro della OOP verso la produzione di strumenti, che consentono di puntare dritti sull'obbiettivo, cioè si rinuncia a dover pensare, ci si deve fidare della strada tracciata da chi ha già pensato per noi, in modo da tagliare i tempi.
In pratica si prega e ci si affida allo strumento, che deve essere pensato che aiutarci nei nostri casi d'uso.
Quindi conviene forse conoscere n strumenti per non rischiare di applicarli a casi d'uso per i quali non sono stati progettati? Logicamente cercando di non legarsi al singolo fornitore di questo o quello strumento.
E' un vero vantaggio? Non converrebbe forse cercare noi, di specializzarci in un dominio applicativo, che conosciamo, comprare/usare/creare le librerie che ci servono e godere poi dei vantaggi del riutilizzo di tali strumenti, come immaginavano i pionieri, che negli anni 80, hanno rivoluzionato il mondo di concepire il software con la OOP?
La OOP è utile, non va ritenuta la panacea di tutti i mali, non sostituisce il bisogno di ascoltare le persone, non è una mera applicazione di pattern, però se compresa nei suoi intimi dettami, è un'ottima soluzione tecnica per produrre codice migliore e avere meno gente che ci chiama ad orari impossibili, per segnalare bug, oltre che un ottimo rimedio per TAGLIARE i tempi di sviluppo.
Quello che molti stakeholder non comprendono subito, è che il tempo investito nella progettazione, ritorna in tempi di sviluppo più brevi e questo beneficio molto spesso si protrae nel tempo.
Pensare prima di agire è un vantaggio. Creare qualcosa di piccolo, che poi va buttato perché si è pensato poco, non è conveniente nel lungo periodo.
Oggi ci si affida molto ai test automatici e questo è giusto, ma quando poi ci si trova a buttare sia il core che il test, azione eufemisticamente detta "refactoring", viene da chiedersi se non sarebbe stato meglio spendere giorni uomo in più per capire il dominio applicativo! Capire, modellare, poi scrivere il codice, certamente documentato e corredato da test, ma senza doverlo rifare 3 o 4 volte, ad ogni iterazione. La mia impressione è che spesso lo sviluppo 'moderno' cerchi solo di sdoganare le cattive abitudini dello sviluppo 'antico'.
Pare inoltre che il risultato del pensiero iniziale, non sia solo la soluzione del problema contingente, ma anche una migliore abilità nei pensieri che seguiranno, già questo dovrebbe essere un ottimo stimolo per non avere paura di fermarsi a riflettere.
Per finire, ci sono aziende che proprio non consentono questo approccio. In queste realtà il programmatore è un produttore di codice da vendere, come una gallina produce uova da vendere. Uova, cetrioli o procedure sono trattati allo stesso modo da quei signori.
Se il lettore si trova in uno di questi posti, il consiglio che mi sento di dargli è quello che trovai anni fa, scritto su un libro di UML: se non puoi cambiare l'ambiente dell'azienda dove lavori, prova a cambiare azienda !
