• Perché l’hanno creata?
• Perché è così utilizzata?
• E’ utile nel contesto in cui ti trovi?
• Quali sono le alternative?
• Perché, tra tutte le alternative possibili, hai scelto proprio questa tecnologia?

Nessuno mi risponde perché nessuno ha scelto!
Eppure all’Università ci hanno inculcato con la forza il concetto di scouting e, fuori dall’Italia, hanno saputo rispondere alle stesse domande con estrema precisione! Tutto ciò è scrupolosamente osservato in quasi tutti i posti di lavoro visitati in Germania, Inghilterra, Australia… ma non in Italia! Noi siamo bravissimi ad andare su un qualunque forum, chiedere a qualcuno il codice per ottenere un determinato obiettivo e copiarlo con “creatività”
Questa è la realtà che ho toccato con mano per dieci anni. Mi avevano quasi convinto che il mio essere critico e il mio pormi tutte quelle domande, il mio volermi sempre migliorare e il mio voler imparare fosse davvero sbagliato! E in verità nel contesto Italia… è sbagliato!
Del resto per capire i motivi che hanno spinto i nostri “colleghi” (spero non si offendano) a creare struts, spring e tutti gli altri, bisogna necessariamente avere una forte competenza della programmazione ad oggetti, molto prima di conoscere java e il mondo infinito che lo circonda. Invece, parlando con i “professionisti” di cui sopra, si scopre molto facilmente che non conoscono concetti come “coesione” o “basso accoppiamento” né hanno un’idea troppo precisa di cosa siano i patterns o altri concetti fondamentali nella programmazione ad oggetti. Non solo. Se si prova a intraprendere con suddetti professionisti un tale discorso, si viene puntualmente snobbati e il discorso bollato come “teorico” e quindi “lontano dalla pratica aziendale”. Già, vero. Magari è proprio per questo che non esportiamo una riga di codice e riscriviamo lo stesso software ogni 2 anni!
Proseguiamo…
Da quando lavoro nell’ambito della programmazione ad oggetti (e non) non ho mai (e sottolineo mai) visto uno unit test e tanto meno un integration test. L’unico test visto più volte è il test funzionale. In verità non ho neanche visto un documento di analisi e pochissimi di progettazione, comunque senza analisi Eppure in tutti i miei studi ho sempre letto e imparato che il software va accuratamente progettato, che tutto parte da una corretta e attenta analisi, ecc. ecc. Ma quando mai? In Italia? E chi segue queste “follie”? Non c’è tempo per pensare a queste “stupidaggini” e, sopratuttto, molte aziende sono convinte che tali accortezze non producano soldi, anzi pensano che esse rallentino soltanto il processo produttivo. Non c’è quindi da meravigliarsi se:

• non ho mai trovato un collega in grado di fare un’analisi professionale di un software
• ho visto una progettazione UML solo un paio di volte (una delle quali l’ho imposta io!)
• ho visto DB senza constraints e senza un diagramma E-R

Purtroppo non ho lavorato per piccole realtà aziendali che quindi, producendo piccoli software, possono permettersi di trascurare certi aspetti (siamo sicuri che possono permetterselo?). Nel mio curriculum si trovano multinazionali come H3G, GlobalValue o enti importanti come Regione Lombardia, la federazione degli ingegneri di Puglia… in poche parole ho realizzato o gestito applicazioni (quasi sempre web) con un numero spropositato di potenziali utenti! Utenti che usavano (e usano) applicazioni costituite da jsp da 8000 righe nelle quali troviamo query SQL mischiate a codice java, database senza capo né coda e potrei continuare.
Proseguiamo…
Vogliamo poi parlare di sicurezza?
In Italia “sicurezza” per le applicazioni web significa 2 cose:

• firewall
• proxy

Fine.
E se, per esempio, installo un proxy in locale, intercetto i parametri http, li modifico e invio roba fuori di testa alla tua applicazione web, cosa succede??? Il firewall e il proxy non possono farci nulla! A questa domanda o spalancano gli occhi o mi rispondono con qualcosa del tipo: “che razza di ipotesi strampalata stai facendo? Questa è fanta informatica!”. Scusate, ma non posso non pormi una domanda!
Per quale motivo i miei colleghi agiscono e reagisocno in questo modo? Eppure hanno i miei stessi titoli e io non son mai stato un genio! E allora? Il problema l’ho esposto all’inizio e l’ho identificato solo dopo aver visto come “ragionano” fuori dalla nostra Nazione e sapete cosa vi dico?
Non sono le Università italiane a essere lontane dal mondo lavorativo! E’ il mondo lavorativo italiano ad essere lontano dalle pratiche internazionali nella produzione del codice!.
Questa è la verità in ambito informatico!
Ecco il tipico ragionamento di un’azienda inglese (tedesca, francesce, americana, australiana). “Ehi man, tu hai studiato all’Università come si crea un software? Hai studiato i princìpi dell’ingegneria del software? Hai studiato come si fa un test, come si procede nella fase di analisi, di progettazione e di implementazione di un software? Bene! Noi cerchiamo proprio te! Paghiamo le tue competenze perché tu possa metterle al nostro servizio nella produzione del nostro business! Tu metti in pratica le tue competenze acquisite all’Università e noi ti paghiamo! Non solo! Se ci indichi quali sono le competenze che ritieni opportuno approfondire per migliorare la produzione del software, noi ti paghiamo i migliori corsi perché tu possa diventarne padrone e usarle per noi.”. Lo so, in Italia queste frasi sono pura fantascienza e infatti i nostri laureati sono tutti andati via! Uno dei problemi che ci impedisce di essere concorrenziali è che molte (troppe) delle nostre aziende sono ancora di stampo “padronale” e quindi i dirigenti pretendono di indicare ai tecnici come produrre il software, quali strumenti usare e magari anche come! Mi viene in mente un brano musicale dal titolo “io non mi sento italiano”
Vogliamo quindi aggiungere qualche parolina sulle retribuzioni italiane e sulle nostre “aziende”?
Dai, proviamoci!
Le cose stanno esattamente nei seguenti termini.
Un neo-laureato in (ingegneria) informatica in Italia inizia a lavorare a non meno di 27 anni. Se si occupa di programmazione software il suo stipendio iniziale non supererà mai i 1200 euro al mese. Dopo 5 anni guadagnerà circa il 15% in più, producendo software come sopra descritto Quando questo povero cristo inzierà la sua ricerca di un impiego in Italia, troverà annunci di aziende che recitano puntualmente così: “lo stipendio sarà commisurato alla reali capacità del candidato”. Ma dai! Non mi dire! Speravo mi pagassi il doppio di quello che valgo!
Nel resto del mondo invece gli annunci recitano puntualmente così: “se sarai valutato idoneo per questo lavoro il tuo stipendio sarà di n euro (dollari, sterline) all’ora, oppure nk euro (dollari, sterline) all’anno”.
Trovate per caso una qualche differenza?
Ma non c’è da meravigliarsi!
Potrebbe mai un’azienda cercare un ingegnere informatico con 5 anni di esperinza su java e offrirgli 10 euro l’ora??? In Germania te ne danno 20; in Inghilerra ti danno 30 sterline l’ora; addirittura in Spagna offrono 15 euro l’ora Lasciamo poi perdere USA e Australia: potremmo sembrare terzo mondo
Ovviamente potete non credere alle mie parole. Posso scrivere quello che mi pare! Fate bene. Dubitate sempre e cercate sempre conferme; in ogni campo.
Ecco perché vi indico qualche luogo dovo potrete verificare quello che vi ho scritto:

• Cerca un lavoro e verifica gli stipendi in UK
• Cerca lavoro in Germania
• Lavorare in Australia
• Stipendi medi per il settore IT in Australia

Ovunque nel mondo occidentale, tranne che in Italia, negli anunci di lavoro trovate il salario che vi spetta per quel lavoro! Ovunque, tranne che in Italia, coloro che studiano all’Università vengono messi al centro del business aziendale (almeno in campo informatico).
Quando questa Nazione, poverina, capirà che senza le competenze universitarie e senza i giovani dai 25 ai 45 anni, senza il loro entusiasmo, senza le loro competenze, senza la loro forza non c’è futuro… sarà troppo tardi… troppo tardi…
Per questi e altri motivi voglio concludere con un consiglio.
Sei laureato in (ingegneria) informatica? Impara questo benedetto inglese (che noi italiani non conosciamo!) e lascia l’Italia nel più breve tempo possibile! Se superi i 35 anni avrai grosse difficoltà ad andare via da questo baraccone di improvvisati!

Innanzitutto distinguiamo tra reference value e object reference.
Un reference value rappresenta un valore (value) e precisamente il valore che viene restituto quando viene creato un particolare oggetto.
Un object reference (o semplicemnte reference) rappresenta invece una variabile che può memorizzare un reference value.
Questa differenza deve essere chiara perché altrimenti niente sarà mai chiaro con i reference in java!
Ora traduciamo questi concetti in codice.
Creiamo 2 object reference di tipo MiaClasse:

Scrivendo questa riga di codice abbiamo comunicato a java di creare due variabili (nella RAM del calcolatore) di tipo MiaClasse e gli abbiamo anche detto che in queste 2 variabili DOVRANNO essere inseriti dei valori che si riferiranno (reference) a 2 oggetti di tipo MiaClasse. Stiamo parlando di “reference”! Questo significa che in queste 2 variabili java NON inserirà MAI gli oggetti veri e propri, ma il rifeimento a tali oggetti!!!
Rileggete bene l’ultimo paragrafo: è molto importante!

Bene. Inseriamo allora tali riferimenti ai 2 oggetti:

A questo punto java assegna un valore a refOggetto1 e un altro valore a refOggetto2. Ribadisco ancora che tale valore NON indica l’oggetto vero e proprio, ma indica la posizione (in RAM) dell’oggetto; il suo “riferimento”.
Si può rappresentare graficamente quanto detto con la seguente figura (scusate la poca eleganza).

In questa figura c’è rappresentato tutto quello che bisogna sapere sui reference!

Perché i reference refOggetto1 e refOggetto2 hanno uno sfondo bicolore?
La risposta a questa domanda svelerà uno dei segreti di java…
Nei reference non viene inserito soltanto l’indirizzo di memoria in cui è memorizzato l’oggetto, ma anche l’intervallo di memoria che sarà occupato dall’oggetto!
Quindi è come se nella parte verde chiaro ci fosse scritto l’indirizzo RAM dove “inizia” l’oggetto che ci interessa, mentre nella parte verde scuro fosse indicato lo spazio da sommare al punto iniziale per contenere l’oggetto.
Vi siete mai chiesti perché scrivere:

procuri un output simile al seguente?

La @ è il separatore tra la parte verde chiaro e quella verde scuro!

Ora comprendere a fondo questo concetto sarà di fondamentale importanza quando parleremo di polimorfismo e di metodi virtuali!

In java NON avremo mai a che fare con gli oggetti veri e propri (indicati con lo sfondo rosa nella figura), ma solo con i loro riferimenti (sfondo verde).
Ecco perché quando noi scriviamo:

NON stiamo rendendo uguali gli oggetti e in realtà non stiamo rendendo uguali neanche i reference, ma solo una parte dei reference, cioè la parte che indica dove inizia l’oggetto in memoria.
Questo significa che dopo tale istruzione refOggetto2 punterà allo stesso indirizzo di memoria a cui punta refOggetto1 e quindi se noi apportiamo una modifica all’oggetto puntato da refOggetto2 la ritroviamo anche sull’oggetto puntato da refOggetto1; per forza! Entrambi puntano allo stesso oggetto!

L’oggetto a cui puntava refOggetto2 rimarrà in memoria fino a quando java, tramite il suo garbage collector, non si accorgerà che nessuno lo “cerca” e lo eliminerà.

Ma tutto quanto detto è valido solo e soltanto se i 2 reference sono stati dichiarati dello stesso tipo (come nel nostro caso)!
Se invece avessimo scritto:

e se non ci fosse legame tra le 2 classi, scrivere:

produrrebbe un errore in compilazione!

Abbiamo già visto che con i dati primitivi le cose funzionano ben diversamente, ma vi rimando ai relativi post.
I dati primitivi
Il passaggio dei parametri
Gli argomenti sono strettamente collegati.
Per “evolvere” il pensiero invece, è bene leggere questo post: java il polomorfismo e i metodi virtuali.
Mal di testa? E’ normale… passerà!