.NET Framework e i parametri opzionali
Con la versione 4.0 del .NET Framework anche C# in Visual Studio 2010 può utilizzare i parametri opzionali, a riguardo si veda Named and Optional Arguments (C# Programming Guide).
Questa novità di fatto rappresenta una convergenza verso VB.NET, infatti i parametri opzionali sono sempre stati presenti in VB.NET, a riguardo si veda Optional Parameters (Visual Basic).
In realtà con la versione 4.0 del .NET Framework si è deciso di uniformare i due linguaggi C# e VB.NET per allineare le features. Quindi grazie alla cooperazione dei team di sviluppo dei due linguaggi VB.NET ha ora ad esempio l’auto implemented property e la collection initializer, mentre C# sono stati introdotti gli optional parameters.
A mio avviso questa funzionalità può risultare utile solo quando si deve scrivere codice che fa uso di COM e occorre utilizzare via interop componenti che utilizzano parametri opzionali come ad esempio le PIA di Office.
In tutti gli altri casi a mio avviso conviene utilizzare overloading dei metodi dal momento che i parametri opzionali possono nascondere alcune insidie dal momento che dietro le quindi il compilatore non fa altro che convertire un metodo con parametri opzionali in una invocazione dello stesso dove i parametri opzionali sono specificati passando il default value.
// Definizione metodo
public void DoSomething([Optional, DefaultParameterValue(“”)] string s)
{
}// Invocazione metodo
DoSomething();// Invocazione risultante nell’Assembly
DoSomething(“”);
Questo significa che se la definizione e l’invocazione stanno in due assemby diversi (una library e un application ad esempio) modificando il valore di default se non si compila anche l’applicazione quest’ultima continuerà ad utilizzare il valore di default precedente. Inoltre se nell’applicazione fosse invece necessario mantenere il vecchio valore di default come parametro da passare alla funzione occorrerebbe cercare ogni invocazione del metodo e specificare il parametro.
Questo genere di issue non si verifica invece quando viene implementato l’overloading dei metodi (questo issue è di fatto lo stesso che che si può riscontrare con le costanti nei confronti dei membri statici).
Per maggiori info si vedano:
Gli optional parameters sono CLS Compliant, al contrario ad esempio del tipo UInteger. Il modo più rapido per verificare che il codice è CLS Compliant è applicare l’attributo <Assembly: CLSCompliant(True)> alla classe e verificare che non vengano riportati warning:
Ovviamente un parametro opzionale non sarà CLS Compliant se fa uso di un tipo non CLS Complinat come specificato in Type of optional value for optional parameter <parametername> is not CLS-compliant.
L’importanza di scrivere codice CLS Compliant sta nel fatto che questo può essere consumato da applicazioni e librerie scritte anche i linguaggi diversi, a riguardo si vedano:
Conclusioni
Per quanto mi riguarda i parametri opzionali, come detto prima, sono utili quando si è obbligati a invocare tramite COM metodi che hanno parametri opzionali (PIA di Office).
In tutti gli atri casi ovvero implementare nelle proprie librerie metodi con parametri opzionali è a mio avviso una brutta pratica di programmazione il cui fine può essere solo quello di scrivere meno codice rispetto a quello necessario per l’implementazione degli overloads, ma andando poi inevitabilmente a complicare il codice all’interno del metodo e a ridurre la leggibilità creando una struttura monolitica.
A riguardo si vedano anche: