Linee guida nella scrittura di codice #06: L'Overload

Quando si decide di mettere in overload un membro, tutti i membri in overload dovrebbero fornire variazioni della stessa funzionalità , ad esempio due membri WriteToLog in overload dovrebbero entrambi scrivere sempre su file e non invece uno su file e l'altro su DB (o viceversa).

àˆ buona norma fornire overload che accettano un numero di parametri via via crescente per fornire un overload "semplificato" a fronte di altri overload più "complessi". Ad esempio, la classe File espone il metodo Open che nella sua forma più semplice accetta solo il percorso su disco del file da aprire e un metodo di apertura, mentre nelle sue forme più evolute accetta ulteriori e più specifici parametri.

Nel caso di overload a cascata come citato precedentemente, è preferibile che gli overload più semplici chiamino gli overload più complessi e non implementino autonomamente la funzionalità  richiesta in quanto in questo modo si duplicherebbe codice inutilmente.

Utilizzare sempre negli overload più complessi, nomi di parametro descrittivi che facciano capire il valore di default utilizzato dagli overload più semplici. Ad esempio tra gli overload della classe String troviamo:

public static int Compare( string strA, string strB);
public static int Compare( string strA, string strB, bool ignoreCase);

Il secondo overload contiene il parametro ignoreCase che ci fa subito capire che l'overload più semplice considera la distinzione delle maiuscole / minuscole ed è quindi necessario utilizzare l'overload più complesso (il secondo) quando si vuole che questa distinzione non venga considerata (cioè ignoreCase = true).

I parametri negli overload devono avere sempre lo stesso nome. Evitare quindi assolutamente di denominare un parametro ad esempio Message in un overload e Text in un altro se Message e Text sono in realtà  lo stesso parametro.

Stessa raccomandazione per la posizione dei parametri. Tutti i parametri dovrebbero sempre mantenere la stessa posizione reciproca tra un overload e l'altro. In particolare nel caso dei parametri variabili e dei parametri in out questi andrebbero sempre posizionati in coda agli altri.

Se è necessario rendere virtual (Overridable) il metodo in overload, definire virtual solo il metodo più complesso (con tutti i parametri) e lasciare che quelli più semplici semplicemente chiamino il più complesso.

Non utilizzare quale discriminante per l'overload le chiavi out o ref.

Nel caso di parametri facoltativi, ammettere il passaggio del valore null. Si assume che se un parametro è null, viene considerato il suo valore di default.