Ho da poco trovato lavoro presso il Centro Cardiologico Monzino di San Donato, Milano, alle dipendenze della Anemos S.r.l., fornitore di software sanitario a norma internazionale per questo e altri ospedali in tutta Italia. Un ottimo risultato, considerando che mi sono laureato da poco.

San Donato è a più di 50 Km da casa mia. Devo prendere treno, metropolitana, bus, in quest’ordine. Non ho orari proibitivi per fortuna, ma lo stesso sono in viaggio per non meno di due ore, con uno scarto di 5 minuti, per andare e tornare; in tutto, perdo 4 ore al giorno su una giornata lavorativa di 8 ore (includendo la pausa, il contratto a progetto mi permette una certa flessibilità negli orari, nei limiti della decenza ovviamente).

Quattro ore sono tante. Potrei usarne anche una parte (la metà, ad esempio) per rilassarmi, dedicarmi ai miei hobby, cominciare prima la mattina e uscire prima il pomeriggio, ponderare altri progetti, ad esempio un sistema di gestione delle caselle dei fumetti che il gestore della maggiore fumetteria lecchese mi ha chiesto di elaborare.

Il linguaggio Java, con gli strumenti giusti, permette di essere veloci come un treno (o una metropolitana) anche se, come un treno, va solo sui suoi binari. A confronto, un linguaggio come C è un fuoristrada, che però a volte è costretto a procedere più lentamente su terreno insidioso (rogue pointers, vale a dire puntatori “ribelli”, gestione dinamica della memoria). E’ più facile, diciamo. Java mi accompagnerà in questi tempi di pendolarismo, sia al lavoro che fuori; anche se per ora mi “limito” allo studio di infinite specifiche sul protocollo HL7 e sull’integrazione di un sistema sanitario con il SISS Lombardia.

Qual è la ricompensa che chiedo dalla vita per il periodo in cui sono appena entrato? Una conoscenza più approfondita e pratica della programmazione a oggetti, delle fasi dello sviluppo in generale, nonché delle tecnologie particolari che userò. Solo allora sarà un periodo speso bene.

Ricordate sempre, quando sentite di entrare in una fase impegnativa della vostra vita, di stabilire bene qual è la parte che alla fine vi spetta: una specie di contratto con la vostra stessa vita. E via col treno.

Da quando mi sono avvicinato alla programmazione ad oggetti, anni fa, durante il corso di Programmazione da 12 crediti, mi è sempre parso un metodo piuttosto comodo per programmare, secondo certe esigenze. Non dico di non aver trovato di meglio, ma quasi.

Un oggetto non è altro che un insieme vivente e coerente di caratteristiche e comportamenti. Vivente perchè può nascere, morire, figliare (e i figli ne ereditano qualsiasi tratto)… ma anche perdersi, impazzire, esplodere trascinando nella tomba altri oggetti (e il programma stesso, se non si sta attenti).

Al tempo dell’esame di Programmazione, sapevo cos’è un oggetto solo secondo la patriarcale concezione Java in cui “tutto deriva da Object”, dunque qualsiasi programma si compone di oggetti, qualsiasi struttura dati è un oggetto e così via: ammirevole, perchè permette di poter richiedere, ad esempio, il campo length su qualsiasi array, ma questo l’ho scoperto solo più tardi.

La vera bellezza degli oggetti mi è stata svelata anni dopo, quando ho imparato parte di C# per poter programmare nel framework XNA. Là, potevo definire una classe “Renderable”, che definisce qualsiasi oggetto visualizzabile sullo schermo; definire una classe “Ball” figlia di Renderable, e le classi RedBall, BlueBall, BlackBall tutte figlie di Ball. Un oggetto rappresenta, quindi, numerosi livelli di astrazione prima della definizione vera e propria di un’entità. E l’approccio, se usato bene, funziona anche quando si ha bisogno (ancora) di pochi oggetti, perchè saranno comunque brevi, ben definiti e riutilizzabili: modulari.

Fin qui, tutto rose e fiori. Ma se il paradigma ad oggetti va fuori controllo, se si tenta di usare oggetti contro natura, ci si trova con un’orribile zuppa di codice piena di oggetti qua e là, magari usati una sola volta, variabili singleton, enti statici. Un ibrido di paradigma imperativo e ad oggetti, realmente nessuno dei due. Se poi non è commentata, peggio ancora: diventa inutilizzabile; ma questo vale per qualsiasi codice.

Il mio assegnamento di stage è la creazione di uno strumento interattivo per la realizzazione del metodo del simplesso. L’ho chiamato Simply. Sto creando l’interfaccia a mano, il che è già un conseguimento non da poco; ma meglio ancora, sto cercando di applicare il paradigma ad oggetti dove possibile. Ad esempio, ma finora sono solo prototipi di idee, l’algoritmo del simplesso è un oggetto, ogni variabile è un oggetto (in grado di dirmi se è una variabile di base, se è originale o slack e di rispondere con il proprio numero se interrogata), ogni parte dell’interfaccia è un oggetto in cui non avviene nessuna computazione: l’interfaccia deve preoccuparsi di fare l’interfaccia. Fare altrimenti, complicherebbe solo le cose e snaturerebbe il paradigma ad oggetti. Un cane non è anche un gatto che è un canarino, è semplicemente un cane. (Tutti sono animali, però).

Auguratemi buon lavoro e buona voglia, ne ho bisogno!

P.s.: A tutti gli amanti del Gibber Italicus, in foto: Non volevo offendere voi né il nobile animale, ma solo porre un esempio di forme non propriamente definibili con forme “standard”.