Continuiamo con le speculazioni estive intorno all'argomento del boxing/unboxing e perfomance.

Nel post precedente abbiamo parlato di cosa vogliano dire i termini in oggetto, e abbiamo evidenziate le motivazioni che stanno dietro alle penalità di perfomance proposte per queste attività.

Qui ora acceneremo qualcosa riguardo ai generics.

 Uno dei grossi vantaggi introdotti dal mondo "generics" è legato alle perfomance, oltre che la "type safety".

L'abbiamo già accennato, ma è meglio rispecificare. Con quest'ultimo termine si intendono le attività atte a evitare gli errori derivanti da lavorare con variabili di tipo incerto: la definizione è abbastanza generica, ma sono certo che rende bene l'idea.

Per vedere bene i vantaggi e gli svantaggi vediamo l’utilizzo della classe ArrayList fornita da .Net framework, e che è una delle poche classi che permette l’utilizzo di object come argomento.

Per i pochi che non lo sanno la classe ArrayList rappresenta un semplice array di object la cui dimensione autonomamente e dinamicamente si adatta ai valori inseriti senza dover fare alcunchè.

Essendo che tutte le variabili in .Net derivano da System.Object, sia direttamente che indirettamente, ecci che quindi object è in grado di ospitare qualisiasi tipo di dato.

Può sembrare una stranezza, ma è proprio così: usando ArrayList è possibile aggiungere a questa un intero, una stringa, un oggetto, o comunque una variabile di qualsiasi tipo ci passi per la testa.

Questa "libertà", però, ha conseguenze nefaste, se non è ben gestita.

In C# è possibile identificare due tipi di variabili: i value types e i reference types: una qualsiasi variabile che dichiariamo all'interno del codice è mutuamente appartenente a uno dei due tipi citati.

Alla maggior parte dei programmatori questa affermazione non provoca particolare interesse: al massimo può provocare un fragoroso: .... e chi se frega ?? Oppure più mestamente provocare confusi ricordi legati alla prima formazione ricevuta su C#.

Infatti usualmente quando si studia il C# questa differenza viene ben spiegata e approfondita, ma poi avendo implicazioni pratiche molto limitate usualmente "si perde il concetto".

In effetti il programmatore mediamente può assolutamente disinteressarsi di questa differenza, e considerala micragnosa e petulante, ma quando si hanno esigenze di perfomance..... allora proprio lì si va a finire !

Inoltre...... non è interessante capire come "funziona il giocattolo" ??

Dunque: torniamo ai value types e i reference types.

Quando il programma viene eseguito viene allocato un certo spazio di RAM delegato a contenere i dati necessari per l'esecuzione: all'interno di questo spazio  vengono riservate alcune zone che hanno compiti ben precisi e stabiliti.

Le zone delegate a contenere il valore delle variabili dichiarate all'interno del programma sono due, e sono chiamate managed heap e lo stack.

Facendola breve il managed heap contiene il valore di tutte le viariabili reference type, mentre lo stack contiene il valore delle variabili value type.

In questi giorni di vacanza mi sono ritrovato a leggere alcuni articoli che riguardavano i vari metodi per implementare l'hiding e l'override dei metodi di una classe in C#.

La questione personalmente mi è sempre sembrata pedante e assolutamente poco interessate, ma da contraltare spesso mi sono accorto che questa parte nasconde diverse insidie: per tale motivo ho pensato di scriverne un post sopratutto per averne un memento.

Inizierà il post espondendo alcune note iniziali al fine di inquadrare meglio il problema.

La questione in analisi riguarda la situazione in cui si scrive un metodo in una classe base, e in una classe da questa derivata, si riscrive un metodo con stessa firma (cioè con stesso, lista parametri e valore di ritorno).

Oss.: Qui si parlerà di metodi, ma tutto quanto esposto vale anche per le proprietà esposte dalla classe.

Occorre dire che in situazione "normali" il metodo implementato all'interno della classe derivata “sovrascrive” il metodo della classe base: detto in altri termini se instanzia la classe derivata il metodo sovrasrcitto della classe base verrà ignorato, e verrà eseguito, come ci si aspetta (?) , il codice implementato all'interno del metodo della classe derivata.

Per quanto ci si impegni a farcire il nostro software di report statistiche, estrazioni dati, analisi aggregate, è matematico che a un certo punto salta sempre fuori il rompiscatole (ehm... volevo dire l'esperto) di turno che ci farà la solita lanconica richiesta: avere un'estrazione automatica di alcuni dati.

Ovviamente detta analisi deve avvenire periodicamente e inviare il risultato finale via excel, per poter eseguire poi delle post-elaborazioni.

Siccome questa statistica è importantississimissssssssssssssima deve giungere tassativamente entro la mattina, e pertanto l'elaborazione deve avvenire la notte precedente.

Sono certo che chi fa il lavoro di (tentativo di) programmatore si sarà sentito rivolgere questa richiesta centinaia di volte, magari con declinazioni e variazioni varie, ma con la medesima sostanza.

Siccome il cliente committente ha sempre ragione, sopratutto se paga, occorre trovare il modo di soddisfare detta richiesta.

Il primo problema classico che occorre risolvere è che generalmente sul server dove deve avvenire l'elaborazione NON è installato office, per cui non possiamo usare l'office automation (Microsft Office Object Library).

Attenzione: Esiste un'ampia letteratura in merito. Installare office o altri software desktop-centrici sul server è cattiva prassi, e deve essere evitato.

Pertanto non ci si può rivolgere a office: come fare ?!

Esistono alcune soluzioni.

1) Creare il file in formato csv, che può essere importato da excel e per la cui generazione non è necessario alcun ausilio particolare.

2) Usare una qualche libreria per creare file excel o formati compatibili che non necessitino della presenza di excel.

3) Convincere il cliente che non ha bisogno di alcun estrazione.