DevExperience : C#

Un mio nuovo piccolo progetto su CodePlex : M2Mqtt

Paolo — Thu, 11 Apr 2013 07:16:09 GMT

Ho appena pubblicato su CodePlex un mio piccolo nuovo progetto : M2Mqtt.

Si tratta di un client MQTT (Message Queue Telemetry Transport) che può essere utilizzato su tutte le piattaforme .Net, ovviamente con un occhio particolare al .Net Micro Framework.

Per chi non lo sapesse MQTT è un protocollo per la comunicazione M2M (Machine to Machine) nell’ambito dell’Internet Of Things e per il quale ultimamente è stato avviato un processo di standardizzazione con OASIS. Basti pensare che grazie alla suo notevole “leggerezza”, è stato scelto come protocollo per lo scambio di messaggi attraverso il Facebook Messanger.

Per maggiori informazioni vi rimando al sito ufficiale MQTT ma non mancherò di pubblicare al più presto una serie di articoli dedicati a questo protocollo ed all’utilizzo della libreria che ho appena rilasciato.

Mi raccomando….stay tuned !!

Community Day sul .Net Micro Framework : slide e demo

Paolo — Mon, 30 Jul 2012 20:52:47 GMT

Con parecchio ritardo (e me ne scuso), ho caricato su SkyDrive le slide ed il codice delle demo relativi al Community Day del 2 Marzo 2012 che ho tenuto con i miei amici del DotNetCampania …. argomento ? … ovviamente .Net Micro Framework !

Spero possano tornarvi utili !

ioProgrammo : realizziamo un sistema di allarme temperatura con il Netduino Plus

Paolo — Fri, 20 Jul 2012 08:51:00 GMT

Anche questo mese nella rivista “ioProgrammo” (n. 177, Agosto 2012) c’è un mio articolo sul .Net Micro Framework e la sua applicazione con Netudino Plus.

Sfruttando la funzionalità Ethernet della scheda, viene realizzato un sistema di allarme temperatura configurabile via RESTful APIs che invia una mail quando la soglia impostata viene superata.

Anche questa volta…mi raccomando…non perdetevelo !

ioProgrammo : il mio articolo sul .Net Micro Framework

Paolo — Wed, 20 Jun 2012 22:52:00 GMT

Questo mese, nella nota rivista di programmazione “ioProgrammo” (n. 176, Luglio 2012), c’è un mio articolo sul .Net Micro Framework.

Si parte dalle basi, dall’architettura e dal modello di programmazione sino ad arrivare a realizzare, attraverso l’utilizzo del Netduino, un allarme fatto in casa che sfrutta un sensore di prossimità.

Mi raccomando non perdetevelo e correte in edicola ad acquistarlo !

WP7 : HttpWebRequest e la cache interna

Paolo — Sun, 25 Mar 2012 21:45:22 GMT

Forse non tutti sanno che la classe HttpWebRequest utilizza una propria cache interna per tutte le richieste che via via vengono eseguite durante il suo utilizzo.

Accade che, eseguendo una richiesta sempre al medesimo URL, l’oggetto HttpWebRequest istanziato non esegue effettivamente la richiesta (l’ho rilevato mediante Wireshark) ma bensì ritorna immediatamente il contenuto della richiesta fatta in precedenza allo stesso URL. Questo comportamento è, appunto, dovuto alla cache interna di cui la classe è dotata.

Su Windows Phone 7, non esiste la possibilità di modificare l’utilizzo della cache attraverso le cache policies come accade nel .Net Framework ma è necessario sopperire a questa mancanza attraverso un workaround.

   1: string requestUrl = String.Format(url + "&{0}", DateTime.Now.Ticks);

   2: HttpWebRequest request = HttpWebRequest.CreateHttp(requestUrl);

   3: request.BeginGetResponse(new AsyncCallback(HandleResponse), request);

Attraverso il codice precedente, si evince che il workaround consiste nell’aggiungere un parametro casuale nella query string dell’URL desiderato, in modo da avere di volta in volta un URL risultante diverso e forzare la richiesta. In questo caso, la casualità è determinata dai ticks del sistema ma potrebbe essere utilizzata anche legata alla generazione di un Guid. Tipicamente, questo parametro sarà ignorato dal web server ma servirà dal lato del device per “simulare” la richiesta ad un URL differente.

Sicuramente la soluzione non appare molto elegante ma a quanto pare è l’unica possibile…nell’attesa di piacevoli smentite !

Codice Nativo vs Gestito : performance

Paolo — Fri, 23 Dec 2011 13:10:32 GMT

Affrontando un problema lavorativo riguardo le perfomance grafiche su un target device con processore ARM e Windows CE 6.0 R3 e facendo delle ricerche di approfondimento in rete, mi sono imbattuto in un interessantissimo articolo di Chris Tacke dell’OpenNETCF Communty intitolato “Native vs. Managed Code : GDI Performance”.

L’articolo, attraverso un’applicazione di test, dimostra quanto il codice nativo non possa essere considerato in assoluto molto più veloce del codice gestito ma soltanto per una percentuale relativa che però può talvolta variare da piattaforma a piattaforma. In particolare, il test viene eseguito utilizzando le GDI di Windows.

Un ulteriore interessante risultato è che l’utilizzo di metodi del .Net Compact Framework che fungono da wrapper di corrispondenti metodi nativi (vedi ad esempio Graphics.FillRectangle che è wrapper dell’API FillRect) riducono le performance rispetto all’invocazione diretta delle API di sistema attraverso le P/Invoke. E’ ovvio che il wrapper al suo interno eseguirà sempre una P/Invoke ma aggiunge un carico di lavoro in più, probabilmente legato a dei check che vengono eseguiti prima della chiamata nativa (vedi anche il marshalling dei parametri).

Swap di due variabili senza la variabile di appoggio ? Si può !

Paolo — Fri, 28 Oct 2011 19:26:19 GMT

Una delle prime funzioni (escludendo il solito Main() che produce il famosissimo “Hello World”) che si scrive quando ci si avvicina al mondo della programmazione, è quella che ci permette lo swap (scambio) di valori tra due variabili.

Tipicamente si è portati a scrivere del codice di questo tipo …

   1: private void Swap(ref int a, ref int b)

   2: {

   3:     if (a != b)

   4:     {

   5:         int tmp;

6:

   7:         tmp = a;

   8:         a = b;

   9:         b = tmp;

  10:     }

  11: }

… ossia siamo portati ad utilizzare una terza variabile (tmp) di appoggio.

Ebbene, tale variabile si può assolutamente evitare, riscrivendo la funzione nel modo seguente …

   1: private void Swap(ref int a, ref int b)

   2: {

   3:     if (a != b)

   4:     {

   5:         a ^= b;

   6:         b ^= a;

   7:         a ^= b;

   8:     }

   9: }

… ed utilizzando solo ed esclusivamente le proprietà dell’operatore logico XOR (commutativa, associativa identità).

Nullable.Equals(object) … comportamento “strano” che ha una spiegazione !

Paolo — Wed, 07 Sep 2011 08:31:20 GMT

Ieri, in ufficio con alcuni miei colleghi, mi sono imbattuto in un comportamento alquanto strano del metodo Equals(object) della struct Nullable<T>.

Consideriamo il seguente frammento di codice :

   1: short? x = 1;

   2: bool b = x.Equals(1);

Secondo voi….quanto vale la variabile b ? Ebbene….magicamente false !

A questo punto consideriamo il seguente frammento di codice :

   1: short? x = 1;

   2: // caso 1

   3: bool b = x.Equals(1);

   4: // caso 2

   5: b = x.Equals((short)1);

   6: // caso 3

   7: short y = 1;

   8: b = x.Equals(y);

Il “caso 1” è ovviamente quello appena visto e ritorna “stranamente” b uguale a false. Il “caso 2” e “caso 3” si comportano correttamente fornendo un valore true.

Cambiamo il “caso 1” nel modo seguente :

   1: int? x = 1;

   2: bool b = x.Equals(1);

In questo caso, abbiamo semplicemente modificato la dichiarazione del nullable type da short? a int? ed il valore di b diventa “magicamente” true !

Ecco che a questo punto, dotandomi di Reflector ho cominciato ad indagare sull’implementazione del metodo Equals(object) della struct Nullable<T> che riporto di seguito.

   1: public override bool Equals(object other)

   2: {

   3:     if (!this.HasValue)

   4:     {

   5:         return (other == null);

   6:     }

   7:     if (other == null)

   8:     {

   9:         return false;

  10:     }

  11:     return this.value.Equals(other);

  12: }

Dopo aver eseguito un paio di controlli preliminari sul fatto che la struct abbia un valore e che l’oggetto passato per il confronto non sia null, viene invocato il metodo Equals(object) del tipo T del campo value (interno alla struct Nullable<T>).

Considerando il caso in cui avevamo la dichiarazione short?, ossia Nullable<short>, il metodo che viene invocato sarà ovviamente Int16.Equals(object) la cui implementazione è la seguente :

   1: public override bool Equals(object obj)

   2: {

   3:     return ((obj is short) && (this == ((short) obj)));

   4: }

L’utilizzo dell’operatore is, per la verifica del tipo del parametro, svela l’arcano !

Come sappiamo, tutti i numeric literals (il numero “1” nel nostro caso) sono trattati implicitamente come Int32, per cui la chiamata x.Equals(1) (dove x è di tipo short?) restituisce “correttamente” false, in quanto obj non sarà short ma int !

In tutti gli altri casi, dichiarando esplicitamente una variabile di tipo short (si veda short y = 1) oppure eseguendo il cast esplicito a short del numeric literal (si veda x.Equals((short)1)), forziamo il tipo (coincidente con short? x) ed il confronto ritorna un valore corretto.

Questo spiega anche il perchè del fatto che modificando la dichiarazione da short? x a int? x, otteniamo un valore corretto per x.Equals(1)….in quanto il numeri literal “1” come già detto è implicitamente un Int32 !

In conclusione…..attenzione all’uso del metodo Equals(object) e dei numeric literals nei confronti !!

Da byte[] a String con il .Net Micro Framework

Paolo — Sun, 04 Sep 2011 16:32:10 GMT

Spesso, dato un array di byte con codifica UTF8, si rende necessaria la relativa conversione in una stringa. Purtroppo, il .Net Micro Framework non mette a disposizione il metodo Encoding.UTF8.GetString(byte[] bytes) utile per questo scopo.

Il metodo più veloce per ottenere il medesimo risultato è il seguente :

   1: byte[] bytes;

   2: ...

   3: ...

   4: string s = new String(Encoding.UTF8.GetChars(bytes));

E’, in pratica, necessario ricavere prima l’array di char corrispondenti e poi instanziare un oggetto String inizializzandolo con tale array.

WPF Dispatcher.CheckAccess() vs Windows Forms Control.InvokeRequired

Paolo — Fri, 19 Aug 2011 18:35:24 GMT

Coloro che utilizzano quotidianamente le Windows Forms conosceranno il significato della property InvokeRequired nell’ambito della classe Windows.Forms.Control. Sappiamo infatti che i controlli di una Windows Forms sono legati ad uno specifico thread (generalmente il main thread) e non sono thread safe. Per questo motivo, se intendiamo invocare un qualsiasi metodo su un controllo oppure modificare una sua property (es. modificare il testo di una label o di una textbox) da un thread differente, è necessario invocare uno dei metodi che permettono di eseguire il marshal nel thread giusto. Questi ultimi sono : Invoke() per l’invocazione sincrona, BeginInvoke() e EndInvoke() per un’invocazione asincrona.

La property InvokeRequired ci permette di capire se è necessario eseguire questa operazione di marshal in un altro thread o meno. Per questo motivo, quando bisogna intervenire tipicamente sulla UI, all’interno del nostro metodo adottiamo un codice di questo tipo :

   1: if (this.myControl.InvokeRequired)

   2: {

   3:     // accesso indiretto attraverso Invoke() o BeginInvoke()

   4:     this.myControl.Invoke(.....);

   5: }

   6: else

   7: {

   8:     // accesso diretto a myControl

   9:     this.myControl.SomeMethod();

  10:     this.myControl.SomeProperty = value;

  11: }

Ma esiste in WPF una controparte della InvokeRequired ?

In WPF, ogni controllo ha la property Dispatcher sulla quale è possibile invocare i medesimi metodi Invoke() e BeginInvoke() per eseguire il marshal nel thread giusto. Sempre Dispatcher fornisce la controparte della InvokeRequired, ossia il metodo CheckAccess() che ritorna true se l’invocazione avviene già nel thread giusto. Per questo motivo il codice suddetto diventa :

   1: if (this.myControl.Dispatcher.CheckAccess())

   2: {

   3:     // accesso diretto a myControl

   4:     this.myControl.SomeMethod();

   5:     this.myControl.SomeProperty = value;

   6: }

   7: else

   8: {

   9:     // accesso indiretto attraverso Invoke() o BeginInvoke()

  10:     this.myControl.Dispatcher.Invoke(.....);

  11: }

E’ importante sottolineare che se in Visual Studio provate a farvi aiutare dall’Intellisense, il metodo CheckAccess() non vi verrà mostrato ma se lo scrivete senza alcun aiuto e compilate, tutto funzionerà correttamente. La sua invisibilità è dovuta alla sua dichiarazione :

   1: [EditorBrowsable(EditorBrowsableState.Never)]

   2: public bool CheckAccess();

Il gate per salire a bordo del Kinect : la classe Runtime

Paolo — Thu, 18 Aug 2011 17:20:18 GMT

Tra tutte le classi messe a disposizione dal Kinect SDK, quella sicuramente più importante è la classe Runtime. Attraverso quest’ultima è possibile gestire tutti i sottosistemi, quali la video camera, il sensore di profondità ed il riconoscitore della figura umana. Di seguito riporto il relativo class diagram :

Inizializzazione e deinizializzazione

Per poter utilizzare il Kinect, la prima cosa da fare è istanziare la classe Runtime.

   1: nui = new Runtime();

Oltre al costruttore di default, senza alcun parametro, è previsto un suo overload che ha in ingresso un index che rappresenta l’identificativo del Kinect da inizializzare nel caso in cui al PC ve ne fosse collegato più di uno. Tale indice è inoltre accessibile successivamente attraverso la property InstanceIndex di sola lettura.

Successivamente, è necessario eseguirne l’inizializzazione, in modo che vengano allocate tutte le risorse unmanaged che sono necessarie per utilizzare i sottosistemi del dispositivo stesso. Per fare ciò, è necessario invocare il metodo Initialize().

   1: nui.Initialize(RuntimeOptions.UseColor | RuntimeOptions.UseDepth);

Tale metodo prevede in ingresso un parametro di tipo RuntimeOptions, ossia un enumerativo attraverso il quale specificare quali sensori vogliamo utilizzare. Ovviamente, i valori possibili possono essere messi in OR tra loro in modo da utilizzare più sensori contemporaneamente. Più precisamente, sono i seguenti :

UseDepthAndPlayerIndex : utilizzo del sensore di profondità con riconoscimento del giocatore (ciascuna giocatore viene individuato attraverso un index diverso);
UseColor : utilizzo della video camera;
UseSkeletalTracking : riconoscimento della figura umana di ciascun giocatore;
UseDepth : utilizzo del sensore di profondità;

Una volta inizializzato ed utilizzato, l’istanza della Runtime va deinizializzata attraverso l’utilizzo del metodo Uninitialize() per poter permettere la deallocazione di tutte le risorse unmanaged.

   1: nui.Uninitialize();

Gli stream, lo skeleton e la video camera

La classe Runtime dispone di alcune proprietà attraverso le quali è possibile accedere a tutte le funzionalità del Kinect.

In primo luogo, vi sono i due seguenti stream :

VideoStream : rappresenta lo stream della video camera, fornendo allo sviluppatore i fotogrammi ripresi da quest’ultima;
DepthStream : rappresenta lo stream del sensore di profondità, in cui ciascun pixel non esprime un punto di un’immagine (in termini RGB, come nel caso del VideoStream) ma fornisce l’informazione della distanza di quel punto rispetto al Kinect;

Entrambe le property rappresentano un riferimento alla classe ImageStream.

Per poter utilizzare tali stream, è necessario la loro apertura invocando su ciascuno di essi il relativo metodo Open() della classe ImageStream. Tale metodo prevede i seguenti parametri :

streamType : di tipo ImageStreamType che permette di dichiarare il tipo di stream al quale siamo interessati (Invalid, Depth o Video);
poolSize : dimensione del buffer (espresso in numero di frame) che il runtime dovrà utilizzare. Tipico valore è 2;
resolution : di tipo ImageResolution che indica la risoluzione da adottare per lo stream;
image : di tipo ImageType che indica il tipo di contenuto nell’immagine. Alcuni possibili valori sono ad esempio Depth per indicare un’immagine che contiene informazioni sulla distanza, Color per indicare un’immagine ripresa dalla video camera in formato RGB oppure ColorYuv per indicare un’immagine ripresa dalla video camera in formato YUV;

   1: nui.VideoStream.Open(ImageStreamType.Video, 2,

   2:     ImageResolution.Resolution640x480, ImageType.Color);

   3: nui.DepthStream.Open(ImageStreamType.Depth, 2,

   4:     ImageResolution.Resolution640x480, ImageType.Depth);

Per accedere al motore per il riconoscimento della figura umana, è disponibile la property SkeletonEngine che rappresenta un riferimento alla classe SkeletonEngine.

Infine, attraverso la property NuiCamera si ottiene un riferimento alla classe Camera, con la quale poter accedere alla video camera e modificarne per esempio l’inclinazione.

Intercettazione delle frame : gli eventi

Per evitare un utilizzo in modalità polling del Kinect, la classe Runtime mette a disposizione alcuni eventi che vengono sollevati quando sono disponibili nuove frame dalla video camera, dal sensore di profondità e dal riconoscitore della figura umana.

       1: nui.VideoFrameReady += new EventHandler<ImageFrameReadyEventArgs>(nui_VideoFrameReady);

       2: nui.DepthFrameReady += new EventHandler<ImageFrameReadyEventArgs>(nui_DepthFrameReady);

       3: nui.SkeletonFrameReady += new EventHandler<SkeletonFrameReadyEventArgs>(nui_SkeletonFrameReady);

Essi rappresentano :

VideoFrameReady : sollevato quando è disponibile, nel buffer, una frame dello stream video (VideoStream);
DepthFrameReady : sollevato quando è disponibile, nel buffer, una frame dello stream di profondità (DepthStream);
SkeletonFrameReady : sollevato quando è disponibile un’immagine della figura umana rilevata dallo skeleton engine;

Kinect : il dispositivo, l’installazione dell’SDK ed i primi passi

Paolo — Wed, 17 Aug 2011 17:36:49 GMT

Tutti i possessori o meno di una console XBOX sono a conoscenza dell’esistenza del Kinect, un fantastico dispositivo attraverso il quale la Microsoft ha iniziato a fare concorrenza alla Nintendo Wii, relativamente ai giochi che non prevedono l’utilizzo di un normale gamepad ma che si basano sui movimenti del corpo del giocatore.

Va sottolineato, però, che nel caso del Kinect il solo uso con la XBOX è piuttosto riduttivo ed infatti la Microsoft ha rilasciato ultimamente un SDK attraverso il quale poter sviluppare delle applicazioni che prevedono l’utilizzo del dispositivo collegandolo al PC.

Prima di poter iniziare ad esplorare gli strumenti messi a disposizione nell’SDK, è utile comprendere le funzionalità del dispositivo e preparare il nostro PC con il relativo ambiente di sviluppo.

Il Kinect visto da vicino

Il Kinect è costituito dai quattro seguenti dispositivi principali :

Videocamera RGB (RGB camera) : una normale video camera con una risoluzione di 640 x 480 a 30 fps (frames per second);
Sensore di profondità (3D Depth Sensors) : costituito da una trasmettitore ad infrarossi ed il corrispondente ricevitore attraverso i quali è possibile calcolare le distanze degli oggetti;
Un motore per l’inclinazione (Motorized Tilt) : un piccolo motore che permette di variare l’inclinazione della video camera fino ad un massimo di 27 gradi (in alto o in basso);
Una serie di microfoni (Multi-Array Mic) : una serie di quattro microfoni per l’audio;

Installazione : SDK e driver Kinect

L’ambiente necessario per lo sviluppo è Visual Studio 2010, almeno nella sua versione Express (nel mio caso è la Ultimate che uso quotidianamente).

Ad esso vanno aggiunti ed installati :

Kinect SDK (ovviamente ancora in versione Beta) che possiamo scaricare al seguente link (in entrambe le versioni 32 o 64 bit);
DirectX Software Development Kit che possiamo scaricare al seguente link:

Al termine dell’installazione, per verificare che il tutto sia avvenuto correttamente, possiamo collegare il Kinect al nostro PC attraverso il cavo USB e verificarne la sua presenza attraverso Gestione Dispositivi nel Pannello di Controllo.

Inoltre, il gruppo dei microfoni dovrebbe essere visibile nella scheda dei Dispositivi di Registrazione.

Per quanto riguarda il cavo di collegamento del Kinect al PC, va sottolineato che quest’ultimo non ha nativamente un connettore USB ma è necessario acquistare un adattatore con relativo alimentatore. Sul Microsoft Store, al seguente link, è riportata la versione per gli Stati Uniti ma è ovviamente possibile acquistare anche la versione Italiana.

Sviluppo : i primi passi

Affrontiamo adesso i primi passi per poter iniziare a sviluppare con il Kinect SDK, introducendo la classe principale di quest’ultimo : la Runtime.

Creiamo un nuovo progetto WPF (ovviamente possiamo utilizzare anche le Windows Forms) e per prima cosa aggiungiamo il riferimento al seguente assembly : Microsot.Research.Kinect.

Inoltre, per poter utilizzare tutte le classi disponibili nell’SDK è necessario aggiungere lo using dei seguenti namespace.

   1: using Microsoft.Research.Kinect.Audio;

   2: using Microsoft.Research.Kinect.Nui;

Definiamo un campo privato nella classe MainWindow di tipo Runtime ed istanziamolo.

   1: public partial class MainWindow : Window

   2: {

   3:     private Runtime nui = new Runtime();

4:

   5:     public MainWindow()

   6:     {

   7: ...

   8: ...

Infine, utilizzando i due eventi di Loaded ed Unloaded della Window, aggiungiamo nei corrispondenti event handlers le istruzioni per poter inizializzare e deinizializzare l’instanza della Runtime.

   1: private void Window_Loaded(object sender, RoutedEventArgs e)

   2: {

   3:     this.nui.Initialize(RuntimeOptions.UseColor | RuntimeOptions.UseDepth);

   4: }

5:

   6: private void Window_Unloaded(object sender, RoutedEventArgs e)

   7: {

   8:     this.nui.Uninitialize();

   9: }

Attraverso il metodo Initialize() vengono specificate quale features vogliamo utilizzare del Kinect (in questo caso la video camera ed il sensore di profondità). Il metodo Uninitialize() è invece necessario per rilasciare tutte le risorse unmanaged che il sistema ha allocato per l’utilizzo del Kinect.

Eseguendo questa banalissima applicazione, che non fa assolutamente nulla, noteremo solamente che all’esecuzione del metodo Initialize(), il dispositivo accenderà il trasmettitore ad infrarossi del sensore di profondità; già questo indica che l’inizializzazione è andata a buon fine. Viceversa, chiudendo la finestra dell’applicazione, il trasmettitore verrà spento (in quanto viene eseguito il metodo Uninitialize()); la deallocazione delle risorse è avvenuta correttamente.

Sito MSDN : una nuova veste grafica

Paolo — Tue, 19 Jul 2011 17:27:06 GMT

Il sito MSDN ha una nuovissima veste grafica e sinceramente ben fatta e molto più accessibile e navigabile della precedente.

In alto, in evidenza le quattro aree principali di sviluppo : desktop, web, cloud e phone.

Nella parte bassa, oltre ai link diretti alle quattro aree suddette, anche le sezioni dedicate ai tools disponibili da Visual Studio a Microsoft Expression.

StringBuilder : tre modi per ripulirla

Paolo — Fri, 15 Jul 2011 09:03:50 GMT

Quando utilizziamo un oggetto StringBuilder e lo costruiamo in maniera incrementale attraverso i metodi Append() ed AppendFormat(), arriva talvolta il momento di doverlo ripulire per poterlo riutilizzare. Ovviamente, non ha senso istanziare un nuovo oggetto facendolo puntare dal medesimo riferimento che stavamo usando sino a quel momento e stranamente la classe StringBuilder non fornisce un metodo Clear().

Esistono, però, tre modi per ripulire un oggetto StringBuilder.

Impostare la lunghezza a zero

La property Length non è readonly, per cui è lecito eseguire la seguente operazione..

myStringBuilder.Length = 0;

Rimuoverne il contenuto

Utilizzare il metodo Remove() per tutta la lunghezza della stringa…

myStringBuilder.Remove(0, myStringBuilder.Length);

Replace del contenuto con la stringa vuota

Sostituire la stringa interna allo StringBuilder con una stringa “vuota”, utilizzando il metodo Replace()…

string content = myStringBuilder.ToString();

myStringBuilder.Replace(content, string.Empty);

Pattern Singleton con parametri

Paolo — Wed, 06 Jul 2011 08:34:10 GMT

Attraverso il pattern Singleton, siamo in grado di rendere disponibile un’unica istanza di una classe in un qualunque punto di un’applicazione essa venga referenziata, in quanto l’allocazione dell’oggetto avviene una sola volta in corrispondenza del primo accesso.

L’implementazione più semplice del pattern, senza considerare le problematiche di thread-safety (per le quali vi rimando a questo link), prevede all’interno della classe stessa :

un campo privato statico “instance” che rappresenterà l’unica istanza della classe a cui appartiene;
un costruttore privato, quindi non invocabile dall’esterno, che istanzia la classe assegnando il riferimento al campo suddetto;
un metodo o una proprietà che ritorna il riferimento al campo privato in maniera intelligente, creando l’istanza della classe se non esiste oppure ritornando il suo riferimento se la stessa è stata già allocata;

Poiché poche righe di codice riescono ad esprimersi più di mille parole, riporto di seguito la versione base di implementazione del pattern :

   1: public class MyClass

   2: {

   3:     private MyClass instance = null;

   4:     ...

   5:     ...

   6:     private MyClass()

   7:     {

   8:         // costruzione oggetto

   9:     }

  10:     ...

  11:     ...

  12:     public MyClass Instance

  13:     {

  14:         get

  15:         {

  16:             if (instance == null)

  17:                 instance = new MyClass();

  18:             return instance;

  19:         }

  20:     }

  21: }

Nel caso in cui abbiamo necessità di passare dei parametri in fase di allocazione dell’oggetto, come possiamo comportarci ?

Una possibilità potrebbe essere quella di implementare un metodo GetInstance() in luogo della property Instance e predisporlo con dei parametri in ingresso.

Ad esempio, nel caso di due parametri :

   1: private MyClass(int param1, int param2)

   2: {

   3:     // costruzione oggetto

   4: }

5:

   6: public MyClass GetInstance(int param1, int param2)

   7: {

   8:     if (instance == null)

   9:         instance = new MyClass(param1, param2);

  10:     return instance;

  11: }

Con questa soluzione, si può dar luogo ad un’ambiguità. Basta considerare il seguente esempio :

   1: MyClass a = MyClass.GetInstance(1,2);

   2: MyClass b = MyClass.GetInstance(3,4);

Chi lavora con l’oggetto a, si aspetta di aver inizializzato correttamente l’oggetto con i valori 1 e 2. Chi lavora con l’oggetto b, invece, si aspetta di avere un oggetto il cui stato interno ha valori 3 e 4. Ovviamente, la prima inizializzazione prevarrà sulla successiva e quindi sia il riferimento a che b punteranno al medesimo oggetto avente stato con valori 1 e 2 (positivo per a ma non per b).

Una soluzione a questo problema può essere quello di implementare il pattern nel modo seguente :

       1: public class MyClass

       2: {

       3:     private MyClass instance = null;

       4:     ...

       5:     ...

       6:     private MyClass(int param1, int param2)

       7:     {

       8:         // costruzione oggetto

       9:     }

      10:  

      11:     public MyClass GetInstance()

      12:     {

      13:         if (instance == null)

      14:             throw new InvalidOperationException("MyClass instance not created !");

      15:         return instance;

      16:     }

      17:  

      18:     public static MyClass Create(int param1, int param2)

      19:     {

      20:         if (instance != null)

      21:             throw new InvalidOperationException("MyClass instance already created !");

      22:  

      23:         instance = new MyClass(param1, param2);

      24:         return instance;

      25:     }

      26: }

In pratica, viene fornito all’esterno un metodo statico di Create() per la prima allocazione dell’oggetto ed il metodo GetInstance() per ricavarne l’istanza corrente. Una doppia chiamate al metodo Create() solleverebbe l’eccezione “oggetto già creato” così come una chiamata alla GetInstance() senza aver prima creato l’oggetto, solleverebbe l’eccezione “oggetto non creato”.