Cosa sono gli Streams? Non sono altro che sequenze di dati che possono essere accedute (lette/scritte) sequenzialmente o in maniera random.

Vi sono vari tipi di stream e cioè:

- FileStream (System.IO),

- MemoryStream (System.IO),

- CryptoStream (System.Security),

- NetworkStream (System.Net),

- GZipStream (System.Compression),

Tutti questi tipi di stream derivano dalla classe base astratta Stream che ha le seguenti proprietà:

- CanRead/CanSeek/CanTimeout/CanWrite: flag in lettura che indicano se lo stream: supporta la lettura/supporta il posizionamento/può andare in timeout/supporta la scrittura

- Length: ritorna la lunghezza in byte dello stream,

- Position: consente di leggere/impostare la posizione corrente sullo stream. [Position =< Length]

A livello di operazioni:

- Close: chiude lo stream e libera qualsiasi risorsa associata ad esso,

- Read/ReadByte: legge un numero di byte dallo stream partendo dalla posizione corrente, aggiornando la posizione corrente,

- Write/WriteByte: scrive sullo stream partendo dalla posizione corrrente, aggiornando la posizione corrente

- Seek: imposta la posizione corrente all’interno dello Stream

- Flush: garantisce che tutti i dati presenti nei buffer in memoria sia effettivamente scritti sullo stream.

Iniziando a parlare dei FileStream, introduciamo la classe statica File la quale permette di creare e aprire i files per leggere e scrivere. Considerando le operazioni sui file, la classe File è identica a FileInfo (descritta nel precedente post). Questa classe ritorna oggetti di tipo FileStream (una classe che rappresenta un file all’interno del file system) o StreamReader e StreamWriter (classi che wrappano FileStream e consentono operazioni di lettura e scrittura sequenziali). I principali membri:

- AppendText: Apre un file (o lo crea se non esiste) e ritorna uno StreamWriter

- Create/Open: Crea/Apre un file e ritorna un FileStream,

- OpenText: apre un file e ritorna StreamReader

- ReadAllBytes/ReadAllLines/ReadAllText: apre un file, legge il contenuto in un array di bytes/array di string/string e chiude il file in una operazione atomica,

- WriteAllBytes/WriteAllLines/WriteAllText: sono la controparte dei metodi riportati sopra per la scrittura.

Analogamente alla classe File vi è la classe statica Directory che presenta una serie di metodi statici per manipolare e creare le directories, ad esempio:

- CreateDirectory/Delete: crea/cancella directory in un path specificato,

- Exists: determina se una directory esiste o meno,

- GetCurrentDirectory/SetCurrentDirectory: ritorna/imposta un oggetto di tipo DirectoryInfo relativo alla directory corrente,

- GetFiles: ritorna i nomi dei file in una directory,

- GetLogicalDrives: ritorna una lista dei drives del sistema (e.g. “c:\”)

Con i metodi di gestione dei file visti sopra, vengono usati due enumerativi:

FileAccess che specifica i diritti richiesti durante l’apertura di un file (Read, Write, ReadWrite) e FileMode che specifica come un file debba essere creato/aperto (Append, Create, CreateNew, Open, OpenOrCreate, Truncate).

Come già accennato le funzionalità base per aprire un file streams e leggere/scrivere il contenuto sono date dalla classe FileStream la quale dispone dei seguenti proprietà:

- Handle: file handle,

- Name: nome del file,

- più tutte quelle derivate dalla classe base astratta Streams e viste sopra.

e i seguenti metodi:

- Lock/Unlock: mantiene/libera un lock sullo stream in modo che nessun altro processo possa alterarlo,

- più tutti i metodi derivate dalla classe base astratta Streams.

Per facilitare la lettura e la scrittura sequenziale, il framework .NET metta a disposizione due classi StreamReader e StreamWriter.

StreamReader consente di leggere dati come stringhe da una qualsiasi classe derivata da Stream.

Proprietà:

- BaseStream: ritorna lo stream che StreamReader sta leggendo,

- CurrentEncoding: ritorna il tipo di encoding dello stream BaseStream,

- EndOfStream: indica se si è raggiunti la fine dello stream BaseStream.

Metodi:

- Close: chiude lo stream

- Peek: recupera il successivo (rispetto alla posizione corrente) carattere,

- Read/ReadBlock/ReadLine/ReadToEnd: legge i successivi caratteri per insieme/blocco/linea/sino alla fine.

Analogamente StreamWriter consente di scrivere dati di tipo stringa su una qualsiasi classe derivata da Stream.

Proprietà:

- AutoFlush: legge o imposta l’autoflush ad ogni chiamata al metodo Write.

- BaseStream: ritorna lo stream che StreamWriter sta scrivendo,

- NewLine: imposta il carattere di nuova riga,

Metodi:

- Close: chiude lo stream BaseStream

- Write/WriteLine: scrive sullo stream/scrive sullo stream includendo il carattere di NewLine

StreamReader e StreamWriter derivano rispettivamente dalle classi astratte TextReader e TextWriter le quali rappresentano l’interfaccia per leggere e scrivere dati basati su testo.

Analogamente esistono anche le classi per leggere/scrivere dati binari BinaryReader e BinaryWriter.

Tornando ai vari tipi di stream parliamo ora della classe MemoryStream la quale fornisce le funzionalità per creare degli stream in memoria.

Oltre alle proprietà della classe base abbiamo:

- Capacity: legge o setta il numero di bytes allocati per uno stream,

Come metodi:

- GetBuffer: ritorna un array di unsigned bytes usato per creare lo stream,

- ToArray: scrive l’intero stream su un array di bytes.

- WriteTo: scrive il MemoryStream su un altro stream.

I MemoryStream sono utili per lavorare con i dati in memoria e poi consolidarli ad esempio su disco. Per farlo si può usare la seguente procedura:

1) Creazione del MemoryStream,

2) Creazione del StreamWriter associato al MemoryStream,

3) Creazione di un FileStream

4) Uso del metodo WriteTo dello StreamWriter per scrivere sullo FileStream.

Un altro modo per migliorare le performance delle letture e scritture sugli stream e bufferizzarle. A questo scopo si può usare la classe BufferedStream che ingloba lo Stream da cui leggere/scrivere e interpone un buffer invece di leggere/scrivere ogni volta dallo Stream. Ad esempio supponendo di voler scrivere su un file, si può usare la seguente procedura:

1) Si crea un oggetto FileStream associato ad un nuovo file,

2) Si crea un oggetto BufferedStream specificando il FileStream,

3) Si usa uno StreamWriter per scrivere dati sul BufferedStream.

Concludiamo questa panoramica sugli stream con le classi GZipStream e DeflateStream: entrambe si occupano di comprimere o decomprimere sequenze di dati sino a 4Gb di dimensione (GZipStream usa un formato portabile dunque da preferirsi se lo stream generato viene poi inviato ad altre piattaforme).

Le proprietà/metodi di GZipStream/DeflateStream sono tutti ereditati da Stream a parte:

- BaseStream: ritorna lo Stream su cui la classe lavora,

Un’importante differenza rispetto alle altre classi è che GZipStream/DeflateStream ricevono in input uno stream e producono in output un altro stream.

Vediamo come utilizzare queste classi per comprimere:

1) Si apre in lettura lo stream del file sorgente da comprimere,

2) Si apre in scrittura il file destinazione

3) Si crea un oggetto di classe GZipStream/DeflateStream passando nel costruttore lo stream destinazione e specificando CompressionMode.Compress

4) Si leggono i dati dal file sorgente e li si inseriscono nel oggetto GZipStream/DeflateStream

La procedura per decomprimere è un po’ diversa:

1) Si crea un oggetto di classe GZipStream/DeflateStream passando nel costruttore lo stream sorgente (quello compresso) e specificando CompressionMode.Compress,

2) si apre in scrittura il file di destinazione,

3) leggendo dal oggetto GZipStream/DeflateStream si scrive sullo Stream di destinazione.

Nel prossimo post parliamo di Isolated Storage.

“RunAs”, il comando che serve a lanciare gli exe facendo finta di essere un altro utente, mi ha sempre dato problemi. Ultimamente quando cercavo di farlo da UI (cliccando il tasto destro sul exe), mi dava il seguente messaggio:

“the parameter is incorrect”

oggi ho provato a documentarmi meglio.

Avevo bisogno di lanciare Excel impersonificandomi con un altro utente per alcuni test che sto conducendo sul nostro Add-in. Leggendo qualche post in rete ho scoperto che qualcuno aveva risolto usando il comando a riga di comando e posizionandosi direttamente nella directory dell’applicativo da lanciare, nel mio caso “C:\Program Files\MicrosoftOffice\Office12”.

Ho quindi provato con:

runas /env /user:utente_dominio excel

alla richiesta della password mi ha dato un errore diverso e cioé:

1058: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it

Una rapida googlata e ho scoperto che andava lanciato il servizio “Secondary Access”.

Ora “RunAs” ha ripreso a funzionare.

Lascio questo post sperando di essere utile a qualcuno: del resto la soluzione era veramente semplice.

Tanto per cambiare ho iniziato un nuovo libro “Refactoring Workbook” . Userò il blog come una sorta di block notes per prendere qualche appunto sul argomento.

Cos’è il refactoring?

E’ l’arte di migliorare il design del codice esistente e funzionante.

Cosa non è considerato refactoring?

1) Aggiungere funzionalità; sebbene il refactoring possa far parte di alcune tecniche come il TDD che lo usano per aggiungere nuove funzionalità, esso non ha come fine la creazione di nuove funzionalità,

2) Riscrivere il codice dall’inizio. Il Refactoring preferisce bilanciare meglio il codice già esistente senza prendersi il rischio di riscrivere codice nuovo potenzialmente non funzionante.

3) Un completo stravolgimento del codice che lo mantiene “non funzionante” oltre una normale sessione di lavoro. Il refactoring viene fatto a piccoli step alla volta, step magari molto frequenti ma che mantengono sempre funzionante il codice risultante.

Se pensiamo che vi sono due tipi di design: l’up-front design, cioè il design che viene deciso ancor prima di scrivere il codice e l’emerging design che è intrinsecamente connesso al codice che scriviamo, il refactoring cerca di abbassare il rischio ed il costo di quest’ultimo.

La metafora dei cattivi odori nel codice (code smells)

Nella vita quotidiana un cattivo odore richiama la nostra attenzione. La causa del cattivo odore può essere un problema oppure una cosa normale. L’intensità stessa dell’odore in alcuni casi ci da la certezza del problema, in altri casi no. Alcuni odori coprono altri odori, alcuni odori se ne vanno risolvendo altri problemi non direttamente collegati. Per ogni smell è importante saper riconoscere i sintomi, le cause, saper cosa fare, payoff e conoscere le controindicazioni (cioè in alcuni casi la medicina potrebbe uccidere il paziente ).

Il code smell dunque descrive un problema localizzato nel codice e come tale non vi è garanzia, una volta fissato quel problema, di aver risolto completamente. Per questo motivo il fixing di uno smell viene fatto in maniera iterativa/incrementale con il seguente ciclo (loop):

Il ciclo di refactoring

1) si considera un programma funzionante,

2) Finché vi è puzza di codice marcio

2.a) Si sceglie il codice con il puzzo peggiore,

2.b) Si seleziona la tecnica di refactoring appropriata e la si usa

3) Si ritorna al punto 2.

La difficoltà di questo processo è quella di riconoscere gli smells nonché riuscire a classificarli in base alla gravità (punto due).

Come approccio si può iniziare a fattorizzare le cose più macroscopiche (es. rinominare variabili/metodi con nomi più chiari o dividere i metodi che hanno più di 30 righe di codice in sotto-metodi).

Sempre il punto due dice “finché”, ma come si capisce che si è finito?

Kent Beck utilizza il concetto di Simple Design: se il codice non rispetta le 4 regole seguenti vi è un problema di sistemare. Il design è semplice quando il codice:

1) Passa tutti i test,

2) Non ha al suo interno logica duplicata,

3) Fa capire chiaramente il proprio intento a chi legge il codice,

4) Ha il minor numero di classi e metodi

Il simple design va constantemente mantenuto. Proprio in questi giorni sto rifattorizzando una serie di classi del nostro prodotto che sono state lasciate crescere a dismisura (metodi di 100+ righe) e la fatica che sto facendo per rifattorizzare tutto, sarebbe stata sicuramente minore se l’avessi fatta man mano che il codice cresceva.

Dove si situa il refactoring all’interno dei metodi di sviluppo agile?

Il refactoring è una tecnica che vive di vita propria, nel senso non è necessario imparare metodi di sviluppo agile per poterla usare. Nonostante questo ad esempio l’eXtreme Programming con il test-driven development (TDD) ne fa uno dei sue tre pilastri (insieme a Simple Design e test-first programming). In questi casi codice creato usando TDD richiede minor attività di refactoring.

Come si pratica il refactoring?

Strumenti: è sufficiente un editor di testi, anche oggi giorno ci si può avvalere di strumenti più sofisticati come l’editor di Visual Studio (o tool come Resharper) che consentono di automatizzare alcuni tipi di refactoring.

Persone: è meglio praticare il refactoring in team (o in coppia). In questo modo le diverse esperienze delle persone del team consentono di generare molte più idee/soluzioni rispetto al singolo.

Tests: una suite di test è indispensabile per avere una rete di salvataggio nel caso alcune modifiche cambino il design del software. Sul mercato vi sono numerosi framework che aiutano a costruire i test.

UML, CRC: il refactoring non sostituisce il design up-front

Configuration management/Version Control: questi strumenti sono importanti per poter confrontare le diverse versioni del codice dopo i diversi passi di refactoring. Grazie ad essi è anche possibile effettuare degli undo dei refactoring che hanno erroneamente cambiato il design o eseguire un refactoring con modalità trying&error.

Bene questa la teoria, ora non rimane che fare un po’ di pratica.

Il capitolo I/O si articola in 5 temi che vedrò di trattare in post specifici:

1) Classi per la gestione/navigazione del file system,

2) Classi per la gestione di flussi (stream) di byte,

3) Classi per leggere e scrivere dati dalle applicazioni .NET,

4) Classi per comprimere streams,

5) Isolated storage,

Le classi per la gestione del file system si trovano nel namespace System.IO, esse si dividono in classi informative e di utilità.

La maggior parte delle classi informative derivano da FileSystemInfo (FileInfo, DirectoryInfo) che contiene metodi e proprietà tramite le quali è possibile: sapere se un file o directory esiste, conoscere l’estensione, conoscere gli attributi (read only, archive, ecc), conoscere le date dell’ultimo accesso.

La classe FileInfo ha i seguenti membri (elenco i principali):

- Directory: ottenere l’oggetto di tipo DirectoryInfo che rappresenta la directory che contiene il file,

- Length: La lunghezza del file,

- IsReadOnly: se il file è in readonly,

- CreateText/OpenText/AppendText: crea/apre/aggiunge testo al file usando uno StreamWriter,

- CopyTo/MoveTo: copia/muove il file in una nuova locazione,

- Create/Open/OpenWrite/OpenRead: crea/apre/”apre in scrittura”/”apre in sola lettura” un file,

- Decrypt/Encrypt: beh si capisce

- Replace: sostituisce un file con le info presenti nell’oggetto FileInfo corrente,

La classe DirectoryInfo manipola e gestisce le diretory, i suoi membri sono:

- Parent/Root: per conoscere la directory padre/root,

- Create/CreateSubdirectiry: per creare una directory/sottodirectory

- GetDirectories/GetFiles: restituisce un array di DirectoryInfo/FileInfo che rappresenta le sottodirectory/files del DirectoryInfo corrente,

- GetFileSystemInfos: è simile ai metodi GetDirectory/GetFiles ma restituisce un array di FileSystemInfo che contiene entrambi files e directory contenuti dal DirectoryInfo corrente,

- MoveTo: per spostare tutto il contenuto di una directory

Il seguente frammento di codice enumera tutti i files contenuti nella directory “D:\Test”.

Vi è poi la classe DriveInfo per accedere alle informazioni riguardanti i drives. I principali membri sono:

- AvailableFreeSpace/TotalFreeSpace/TotalSize: ritorna lo spazio disponibile tenendo conto della quota utente/spazio disponibile NON tenendo conto della quota utente/spazio totale.

- DriveFormat: Format del file system (NTFS, FAT, ecc);

- DriveType: Enumerativo DriveType (CDROM, Fixed, Network, NoRootDirectory, Ram, Removable, Unknown)

- RootDirectory: ritorna l’oggetto DirectoryInfo che rappresenta la directory root

- IsReady: importante questa proprietà soprattutto per i CD-ROM e le unità removibili; prima infatti di usare proprietà come DriveFormat, RootDirectory, ecc bisogna controllare che il drive sia pronto (Name e DriveFormat invece possono essere sempre lette).

Vi inoltre il metodo statico GetDrives() che ritorna un array DriveInfo di tutti i drives del sistema.

Continuiamo la carellata con la classe Path. Da notare che si tratta di una classe statica, dunque potremmo definirla come un insieme di metodi per manipolare i path (i percorsi: stringhe usate per indicare la posizione di file e directory all’interno del file system).

- ChangeExtension: dato un path viene ritornato un nuovo path con la nuova estensione di file indicata,

- Combine: combinazione di due path

- GetDirectoryName/GetFileName/GetFileNameWithoutExtension/

GetExtension/GetFullPath/GetPathRoot: il nome dei metodi è autoesplicativo

- GetRandomFileName: per generare un nome di file a caso (es. “y5pj1wjl.u40”). Di primo avviso l’ho pensato utile per i file temporanei ma forse meglio usare il metodo seguente.

- GetTempFileName: simile al precedente genera un path completo nella locazione “Local Settings” dell’utente (es. “C:\Documents and Settings\<<nome utente>>a\Local Settings\Temp\tmp38C.tmp”);

- GetTempPath: ritorna la posizione della directory temp per l’utente.

Per concludere la classe FileSystemWatcher con la quale è possibile monitorare i cambiamenti al file system.

- EnableRaisingEvents: consente di abilitare/disabilitare il “watching”,

- Filter: consente di impostare quali tipi di file devono essere monitorati (non impostanto niente, tutti i files vengono monitorati),

- IncludeSubdirectories: specifica se monitorare le subdirectory o solo la directory specificata nella proprietà Path,

- NotifyFilter: consente di specificare quale evento riportare (cancellazione, aggiunta, modifica, rinomina),

- Path: specifica quale directory monitorare,

- WaitForChanged: è un metodo che consente di monitorare la directory in maniera sincrona; una volta che l’esecuzione del metodo è finita, esso ritorna una struttura contenente i cambiamenti riscontrati.

Gli eventi riportati sono:

- Changed: directory o file modificati

- Created: directory o file creati

- Deleted: directory o file cancellati

- Renamed: directory o file rinominati

Questo un piccolo esempio che monitora il path C:\ e che riporta ogni file/directory creata e ogni file/directory rinominata.

Da notare che se il path non è corretto non viene riportato nessun errore e niente succede (io ad esempio invece di “C:\” avevo messo “C:”).

Nel prossimo post vedremo come trattare il contenuto dei files e i flussi dati in generale. A presto.

Purtroppo i miei post riguardanti la preparazione per l’esame 70-536 si sono molto diradati, complice il crescente interesse sulla parte Unit Testing e Mocking che consuma la maggior parte del mio tempo, per non parlare del lavoro . Ma non desisto, ho intenzione di prendere una certificazione Microsoft, anzi la butto lì….. voglio diventare MCT (di questo passo verso i 45 anni dovrei farcela )

Parliamo di conversione tra i tipi.

Una conversione tra tipi può essere necessaria quando ad esempio si vogliono comparare due oggetti di tipo diverso. La conversione può essere:

Conversione implicita: il sistema effettua la conversione “senza bisogno di aiuto”; questo tipo di conversione è possibile quando il tipo di destinazione può accomodare tutti i possibili valori del tipo sorgente (Widening conversion). Il C# proibisce la conversione implicita da un tipo ad un altro quando essa causa perdita di precisione (narrowing conversion). In questo caso è necessaria la conversione esplicita.

Conversione esplicita: il sistema non è capace di effettuare la conversione e richiede che sia il programmatore a specificare la regola di conversione usando uno dei meccanismi seguenti:

- (type): il buon vecchio e caro cast è utilizzabile tra tipi che definiscono gli operatori di conversione specifici,

- System.Convert: consente la conversione tra tipi che implementano IConvertible,

- type.ToString: converte da tipo base a stringa (solleva eccezione se la conversione non è possibile),

- type.Parse: converte da stringa a tipo base (solleva eccezione se la conversione non è possibile),

- type.TryParse: come type.Parse converte da stringa a tipo base ma in questo caso se la conversione non è definita ritorna false,

Boxing e Unboxing:

Abbiamo già parlato di tipi Value e di tipi Reference. Il boxing non è altro che la conversione di un tipo Value in un tipo Reference (ad esempio la conversione di un int in un object). Tale conversione avviene anche quando si chiamano metodi virtuali di struct che derivano da System.Object.

L’unboxing è chiaramente l’operazione contraria.

Queste due operazioni se usate all’interno di cicli (loop) possono causare rallentamenti nelle performance. Ecco allora alcuni consigli per evitare il boxing/unboxing:

1) Usare i generics dove possibile invece di Object,

2) Fare l’override di ToString, Equals, GetHash per le strutture,

3) Per metodi che possono accettare diversi tipi value, fare sempre una versione del metodo specifica per il tipo (si legaal punto 1: evitare l’object).

Da ultimo vediamo quali tecniche si possono usare per implementare la conversioni tra tipi custom e tipi base:

A) Definire gli operatori di conversione, permette di specificare come convertire da tipo base a tipo custom e viceversa.

implicit operator da usare per le conversioni Widening.

explicit operator da usare per le conversioni Narrowing.

Da notare che gli operatori vanno definit static e pubblici.

B) Fare l’override di ToString per consentire le conversioni verso string e l’override di Parse per le conversioni da string,

C) Implementare l’interfaccia System.IConvertible. Si tratta del overloading di una serie di metodi. Meglio far generare i metodi da Visual Studio ed implementare solo quelli che servono, lasciando gli altri generare l’eccezione NotImplementedException.

D) Implementare una classe TypeConverter che è utile per fare conversioni in design-time all’interno dell’ambiente di sviluppo Visual Studio per le Properties Window. Quest’ultimo metodo non è materia di esame.

Prossimo post: nuovo capitolo che parla dell’ I/O (Aiò!! Galapagos!)

Anno nuovo, vita nuova! Beh non esageriamo. Vi sono però alcuni propositi "professionali" che annoto qui in modo che il post mi faccia da "memento".

Nel 2009 mi piacerebbe:

- Approfondire uso Unit Test soprattutto su codice Legacy,

- Structure Map (Inversion of Control)

- RhinoMock

- Approfondire "Domain Driven Design"

- NHibernate

Poca roba vero? e tutta Alternativa (si veda ALT.NET)

I primi tre punti devo assolutamente dominarli per poterli poi proporre all’interno del mio team, il 2009 deve essere l’anno dello "unit test" quindi mi do come scadenza Aprile 2009. Già qualche mese fa ho comprato la versione MEAP (Mannings Early Access Program) di "The Art of Unit Testing" e l’ho quasi finita. Ora però devo riassumere bene tutti i concetti e soprattutto cercare di applicarli. Non sarà facile.

Per NHibernate invece ho solo un interesse personale, essendo molto legato al discorso DDD. A questo non metto date.

Vedremo vedremo

Sempre dal libro “C# in depth” trovo interessante vedere come la sintassi per l’uso dei delegates sia variata dalla versione 1.0 sino alla version 3.0 di C#.

Prendiamo come esempio il classico ambito di utilizzo dei delegates: la gestione degli eventi.

Supponiamo di avere un applicativo Winform con un pulsante “Button” e di voler tracciare, scrivendo sulla console, i tre eventi: Key Press, Mouse Click e Click.

In C# 1.0 avremmo così fatto:

 </p>  <p>static void LogClickEvent (object sender, EventArgs e)</p>  <p>{</p>  <blockquote>   <p>Console.WriteLine (“Log Click Event”);</p> </blockquote>  <p>}</p>  <p>static void LogMouseClickEvent (object sender, MouseEventArgs e)</p>  <p>{</p>  <blockquote>   <p>Console.WriteLine (“Log Mouse Click Event”);</p> </blockquote>  <p>}</p>  <p>static void LogKeyboardPresEvent (object sender, KeyPressEventArgs e)</p>  <p>{</p>  <blockquote>   <p>Console.WriteLine (“Log Keyboard Press Event”);</p> </blockquote>  <p>}</p>  <p>&#160;</p>  <p>…</p>  <p>Button button = new Button();</p>  <p>button.Text = “Click me”;</p>  <p>button.Click += new EventHandler(LogClickEvent);</p>  <p>button.KeyPress += new KeyPressEventHandler(LogKeyboardPresEvent);</p>  <p>button.MouseClick += new MouseEventHandler(LogMouseClickEvent);</p>  <p>…</p>  <p>

Cioè in pratica per associare l’handler dell’evento: si crea una nuova istanza specificando il tipo di delegate e passando la action (cioè il metodo da chiamare).

Vediamo come avremmo potuto migliorare la scrittura del codice sopra, usando tre features che sono state introdotte nei delegates C# 2.0 e cioè:

1) conversione implicita da un method group ad un tipo di delegate compatibile.

2) supporto per i delegates di “return type covariance” e “parameter type contravariance”.

3) anonymous methpds

Vediamo in dettaglio:

Per prima cosa sarebbe bello che il compilatore si occupasse di capire da solo il tipo del delegate, risparmiandoci il fatto di doverlo esplicitare nella clausola new.

Questo è possibile in C# 2.0 grazie ad una conversione implicita da un method group ad un tipo di delegate compatibile. Un method group è semplicemente il nome del metodo; viene chiamato method group in quanto ad un singolo nome di metodo possono essere associati diversi metodi con lo stesso nome ma che differiscono per i parametri (overloading). Grazie a questa conversione è possibile scrivere:

 </p>  <p>…</p>  <p>button.Click += LogClickEvent;</p>  <p>button.KeyPress += LogKeyboardPresEvent;</p>  <p>button.MouseClick += LogMouseClickEvent;</p>  <p>…</p>  <p>

Più leggibile no?

Questa conversione implicita non funziona in tutti i casi. Proprio perchè si passa da un method group che può essere un insieme di metodi diversi, in alcuni casi il compilatore non è in grado di capire quale tipo di delegate si richiede. In questi casi si può effettuare un cast al tipo corretto.

Lo stesso libro invece che dare una regola suggerisce di usare la modalità “just try it”: cioè sperimentare con il codice, se il compilatore non si lamenta allora tutto ok. Io spesso e volentieri lo faccio, poi a posteriori cerco di capirne il motivo ma almeno ho passato l’ostacolo ed evito di scoraggiarmi.

Un’altra feature introdotta in C# 2.0 è il supporto per i delegates di “return type covariance” e “parameter type contravariance”. Vediamo una semplice definizione:

"Return type Covariance” significa che un tipo ritornato può essere trattato come fosse un super-tipo.

“Parameter type Contravariance” significa che un parametro di un certo tipo può essere trattato come un sotto-tipo

Se guardiamo la definizione dei tre delegati usati per intercettare gli eventi, abbiamo:

 </p>  <p>void EventHandler (object sender, EventArgs e)    <br />void KeyPressEventHandler (object sender, KeyPressEventArgs e)     <br />void MouseEventHandler (object sender, MouseEventArgs e)</p>  <p>

MouseEventArgs e KeyPressEventArgs derivano da EventArgs. Dal fatto che i delegate supportano “parameter type contravariance” possiamo usare oggetti di tipo MouseEventArgs e KeyPressEventArgs a metodi che si aspettano il tipo EventArgs, essendo sicuri che tali oggetti verranno trattati come i corrispondenti sotto tipi.

Se quindi prendiamo l’esempio originario ed immaginiamo di non dover distinguere tra gli eventi accaduti, ma solo tracciare il firing, possiamo scrivere il seguente codice:

 </p>  <p>…</p>  <p>button.Click += LogClickEvent;</p>  <p>button.KeyPress += LogClickEvent;</p>  <p>button.MouseClick += LogClickEvent;</p>  <p>…</p>  <p>

Far vedere il supporto di “return type covariance” è un po’ più difficile in quanto quasi tutti i delegate di .NET sono dichiarati con un return type void. Il libro ne definisce uno ad-hoc

 </p>  <p>delegate Stream StreamFactory();</p>  <p>static MemoryStream GenerateRandomData()</p>  <p>{</p>  <blockquote>   <p>…</p> </blockquote>  <blockquote>   <p>return new MemoryStream(buffer);</p> </blockquote>  <p>}</p>  <p>…</p>  <p>StreamFactory factory = GenerateRandomData();</p>  <p>Stream returnedStream = factory();</p>  <p>

In pratica nonostante il delegate StreamFactory ritorni un tipo Stream, abbiamo associato una action (metodo GenerateRandomData) che ritorna un MemoryStream. L’invocazione all’ultima riga è possibile proprio grazie al supporto per “return type covariance”. Se nell’ultima riga cambiamo il tipo della variabile returnedStream a MemoryStream il compilatore darà errore poichè non sarà più possibile trovare un delegate corrispondente alla signature.

Il prossimo post invece sulla terza feature introdotta con C# 2.0, quella ritenuta la più importante: anonymous methods.

Tra i numerosi libri che sto leggendo in questo momento vi è anche “C# in depth” di Jon Skeet pubblicato da Manning (da cui ho comprato anche l’ottimo “The art of unit testing” in versione pre-printed).

Sono ancora alle prime pagine ma il libro mi sta “prendendo assai”. Fa sorridere dire una cosa del genere per un libro tecnico nel quale non si narra una storia ma bensì la struttura di un linguaggio di programmazione. Eppure i linguaggi di programmazione hanno, almeno per me, un fascino particolare: un po’ come i linguaggi “umani” essi nascono magari riprendendo altri linguaggi e pian piano si evolvono, nel caso dei linguaggi di programmazione naturalmente grazie alle estensioni fatte dai loro creatori, ma quasi sempre su suggerimento degli utilizzatori. Come la possibilità di usare nuovi costrutti sintattici (denominati syntatic sugar) per rendere il codice sempre più leggibile e sempre più dichiarativo a scapito dell’imperativo (specificare cosa e non come).

C# è arrivato alla terza major release (anzi alla conferenza Microsoft PDC si è parlato già della versione 4.0).

“C# in depth” è diverso dagli altri libri che insegnano ad usare C#, esso si focalizza “solo” sui miglioramenti tra una versione e l’altra.

Il primo capitolo con un semplice esempio fa vedere come il codice scritto nella versione 1.0 venga via via semplificato e reso migliore (nel senso di più snello e leggibile) passando dalla 2.0 alla 3.0. Il codice viene man mano trasformato con i seguenti passaggi che mi annoto a futura memoria:

C# 1.0: Read only properties –> C# 2.0: Private property “setters” –> C# 3.0: Automatically implemented properties

C#1.0: Weakly typed collections (ArrayList) –> C# 2.0: Strongly typed collections (generics) –> C# 3.0: Enhanced collection and object initialization.

C#1.0: Weakly typed comparator –> C# 2.0: Strongly Typed comparator –> C# 3.0: Lambda Expressions

C#1.0: No delegate sorting option –> C# 2.0: Delegate comparisons + anonymous methods –> C# 3.0: Extension methods + Option of leaving list unsorted

C#1.0: extra work to cope with null in value type variables –> C#2.0/3.0: Use of Nullable types

Se vi interessa l’argomento è sicuramente un ottimo libro, scritto in un inglese chiaro, con pochi esempi ma quelli giusti.

Beh il 2008 è agli sgoccioli, non mi rimane che augurare a tutti i miei lettori (2) un Buon 2009 ricco di belle novità.

Chissà se nel 2009 riuscirò a scrivere un po’ di più su questo blog.

Nell’ultimo post mi sono occupato di ereditarietà, interfacce, partial class e generics. Per completare gli strumenti che ci aiutano nella costruzione delle nostre classi, vediamo ora Attribute, Event e Type Forwarding:

Attribute: un attributo consente di contraddistinguere (taggare) un metodo, una proprietà, un tipo con informazioni che possono essere lette ed utilizzate programmaticamente. Ad esempio il runtime leggendo questi attributi può: conoscere quali privilegi sono richiesti da una classe, quali capacità ha la classe, descrivere l’autore, ecc.

Tutti i tipi di attributi derivano dalla classe System.Attribute e la sintassi prevede che siano inseriti all’interno delle parentesi quadre.

Esempio:

  [assembly: AssemblyCompany("Microsoft Learning")]  [assembly: AssemblyProduct("ch01cs")]  [assembly: AssemblyCopyright("Copyright © 2006")]  [assembly: AssemblyTrademark("")][assembly:FileIOPermissionAttribute(SecurityAction.RequestMinimum, Read=@"C:\boot.ini")] 

Event : il concetto di evento non è certamente nuovo per chi, come me, ha iniziato a programmare su Windows 3.1. Ho ancora da qualche parte i due libri di Charles Petzold, quanti ricordi

Un evento è un segnale che avvisa che una certa azione è accaduta.

L’evento viene inviato da una classe (event sender) che non conosce chi sarà la classe che gestirà l’evento (event receiver). Vi è invece un meccanismo posto tra i due che veicola gli eventi dal sender al receiver. Tale meccanismo in .NET è costituito dai delegate.

Piccola parentesi:

Cos’è un delegate? Un delegate è una classe che mantiene un puntatore ad un metodo con una specifica signature. 

La dichiarazione del metodo delegate è sufficiente a specificare la classe delegate.

I delegate sono usati in molti ambiti tra cui la gestione degli eventi.

La signature standard di un delegate che gestisce gli eventi, è un metodo che:

1) non ritorna valori,

2) ha come primo parametro un’istanza di tipo object, che rappresenta l’event sender

3) ha come secondo parametro un’istanza di un tipo derivato da EventArgs che contiene dettagli specifici del tipo di evento. A seconda dell’evento infatti diversi sono i dettagli e diverse sono le classi usate tutte derivate da EventArgs.

Il delegate EventHandler è predefinito e può essere usato per quando il metodo che risponde ad un evento non genera dati. Se invece l’evento genera dati allora bisogna creare un nuovo delegate che abbia come secondo parametro un proprio tipo custom, o usare la versione generica del delegate EventHandler usando il tipo corretto.

Per associare un evento al metodo di gestione, è sufficiente aggiungere un’istanza del delegate all’evento.

Esempio:

1) Creiamo il metodo di gestione dell’evento in modo che segua la signature del delegate EventHandler

  private void button1_Click(object sender, EventArgs e)  {    // Method code  } 

2) Aggiungiamo il metodo all’evento “Click” di un ipotetico “button1”

  this.button1.Click += new System.EventHandler(this.button1_Click); 

Type Forwarding

Type forwarding consente di “muovere” un tipo da un assembly A in un altro assembly B facendolo a runtime, cioè senza modificare nessuna riga del codice sorgente.

Lo si fa per esempio con le seguenti righe di codice:

   using System.Runtime.CompilerServices;  [assembly:TypeForwardedTo(typeof(DestLib.TypeA))] 

Ma quando la userò mai questa feature?

Seguendo la tabella di marcia, il prossimo post cercherà di riassumere il capitolo “Conversione dei tipi”.

Scrivere un programma è come scrivere un testo (un libro): lo si fa per comunicare qualcosa e lo si fa usando la grammatica e la sintassi del linguaggio.

Questo significa che per dire la medesima cosa si possono usare parole, espressioni, idiomi differenti. Solitamente un autore ha il suo stile, esso può anche cambiare intenzionalmente da libro a libro, ma difficilmente cambia all’interno dello stesso libro.

Idem con il codice, ognuno di noi ha il proprio stile di programmazione dato dall’esperienza e dal diverso modo di pensare/di approciare il problema. Se questo, riferendosi ad un libro è un bene, avere programmi o peggio parti del medesimo programma scritte da autori diversi con stili diversi, può diventare un problema. E’ come avere un libro scritto da diversi autori ciascuno con il proprio stile: anche se particolare, sarebbe sicuramente di difficile lettura. La situazione è ancor più tragica in un software, dove l’analisi e la correzione di possibili errori obbliga a rileggere e modificare parti scritte da altri (e quindi con stili diversi).

Insomma senza dover uniformare completamente il modo di scrivere software, che sarebbe un po’ snaturare la bellezza di questa attività che molti paragonano ad un arte, si può cercare di condividere alcune scelte di stile. Queste scelte denominate anche convenzioni o “coding convention” sono, come detto, dettate da necessità sicuramente diverse da chi scrive un libro. Wikipedia elenca le seguenti:

Code conventions are important to programmers for a number of reasons:

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
• If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Noi nel nostro team abbiamo una serie di naming convention, che sono un sottoinsieme delle coding convention relativamente a come chiamare gli identificatori (variabili, procedure, ecc).

Io sto cercando di andare più in là e mi sono dotato di un tool che la stessa Microsoft usa per identificare le parti di codice che non aderiscono alle convenzioni stabilite negli anni. Tale tool si chiama guardacaso StyleCop.

Si tratta di un progetto open-source e lo si può trovare qui. Esso si integra in Visual Studio e lo si può eseguire e configurare facendo click-destro sulla finestre del Solution Explorer. Per ogni violazione di stile viene riportato un warning con la descrizione del problema.

Per coloro che usano ReSharper, un ottimo tool che aiuta nella stesura del codice, vi è anche un add-in che consente di eseguire l’analisi dello stile man mano che si scrive il codice.

Davvero degli utili tool per cercare di migliorare il “nostro” stile di bravi artisti scrittori di codice