Metodi di estensione

Nota

Questo contenuto viene ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idiomsn and Patterns for Reusable .NET Libraries, 2nd Edition. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni in questa pagina potrebbero non essere aggiornate.

I metodi di estensione sono una funzionalità del linguaggio che consente di chiamare metodi statici usando la sintassi delle chiamate al metodo di istanza. Questi metodi devono accettare almeno un parametro, che rappresenta l'istanza su cui il metodo deve operare.

La classe che definisce tali metodi di estensione viene definita classe "sponsor" e deve essere dichiarata come statica. Per usare i metodi di estensione, è necessario importare lo spazio dei nomi che definisce la classe sponsor.

❌ EVITARE di definire in modo frivolo i metodi di estensione, soprattutto per i tipi non di proprietà.

Se si è proprietari del codice sorgente di un tipo, è consigliabile usare metodi di istanza regolari. Se non si è proprietari e si vuole aggiungere un metodo, prestare molta attenzione. L'uso liberale dei metodi di estensione ha la possibilità di inglobare API di tipi che non sono stati progettati per avere questi metodi.

✔️ PRENDERE IN CONSIDERAZIONE l'uso di metodi di estensione in uno degli scenari seguenti:

  • Per fornire funzionalità helper rilevanti per ogni implementazione di un'interfaccia, se tale funzionalità può essere scritta in termini di interfaccia principale. Ciò è dovuto al fatto che le implementazioni concrete non possono essere altrimenti assegnate alle interfacce. Ad esempio, gli operatori LINQ to Objects vengono implementati come metodi di estensione per tutti i tipi IEnumerable<T>. Pertanto, qualsiasi implementazione di IEnumerable<> viene automaticamente abilitata per LINQ.

  • Quando un metodo di istanza introduce una dipendenza da un tipo, ma tale dipendenza interrompe le regole di gestione delle dipendenze. Ad esempio, una dipendenza da String a System.Uri non è probabilmente auspicabile e pertanto il metodo di istanza String.ToUri() che restituisce System.Uri sarebbe la progettazione errata dal punto di vista della gestione delle dipendenze. Un metodo di estensione statico Uri.ToUri(this string str) che restituisce System.Uri sarebbe una progettazione molto migliore.

❌ EVITARE di definire metodi di estensione in System.Object.

Gli utenti VB non potranno chiamare tali metodi sui riferimenti agli oggetti usando la sintassi del metodo di estensione. VB non supporta la chiamata di tali metodi perché, in VB, dichiarando un riferimento come Object, tutte le chiamate al metodo su di esso devono essere associate in ritardo (il membro effettivo chiamato viene determinato in fase di esecuzione), mentre le associazioni ai metodi di estensione vengono determinate in fase di compilazione (associazione anticipata).

Si noti che le linee guida si applicano ad altri linguaggi in cui è presente lo stesso comportamento di associazione o in cui i metodi di estensione non sono supportati.

❌ NON inserire i metodi di estensione nello stesso spazio dei nomi del tipo esteso, a meno che non si tratti dell'aggiunta di metodi alle interfacce o per la gestione delle dipendenze.

❌ EVITARE di definire due o più metodi di estensione con la stessa firma, anche se si trovano in spazi dei nomi diversi.

✔️ CONSIDERARE la definizione di metodi di estensione nello stesso spazio dei nomi del tipo esteso se il tipo è un'interfaccia e se i metodi di estensione devono essere usati nella maggior parte o in tutti i casi.

❌ NON definire metodi di estensione che implementano una funzionalità negli spazi dei nomi normalmente associati ad altre funzionalità. Al contrario, definirli nello spazio dei nomi associato alla funzionalità a cui appartengono.

❌ EVITARE la denominazione generica degli spazi dei nomi dedicati ai metodi di estensione, ad esempio "Estensioni". Usare invece un nome descrittivo, ad esempio "Routing".

Parti protette da copyright © 2005, 2009 Microsoft Corporation. Tutti i diritti sono riservati.

Ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2a edizione di Krzysztof Cwalina and Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional nella collana Microsoft Windows Development Series.

Vedi anche