Come gestisci gli spazi dei nomi dei tuoi metodi di estensione?

Question

Usi uno spazio dei nomi globale, catchall per tutti i tuoi metodi di estensione o metti i metodi di estensione nello stesso spazio dei nomi delle classi che estendono?

Oppure usi qualche altro metodo, come un'applicazione o uno spazio dei nomi specifico della libreria?

Chiedo perché ho bisogno di estendere System.Security.Principal.IIdentity e mettere il metodo di estensione nello spazio dei nomi System.Security.Principal sembra avere senso, ma non l'ho mai visto fare in questo modo.

Answer 1

Si consiglia di inserire tutti i metodi di estensione in un singolo spazio dei nomi (incidentalmente è anche ciò che Microsoft ha fatto con Linq inserendoli in una singola classe "Estensioni" all'interno dello spazio dei nomi "System.Linq").

Poiché Visual Studio non fornisce alcun indizio su come individuare un metodo di estensione che si desidera utilizzare, riduce la confusione semplicemente ricordando uno spazio dei nomi.

Answer 2

Se si tratta di metodi di estensione utilizzati in tutta la soluzione (ad esempio oltre il 60% delle classi), li inserisco nello spazio dei nomi di base della soluzione (poiché verranno importati automaticamente in uno spazio dei nomi padre, senza importare il roba comune ogni volta).

In questa categoria, le cose come:
.IsNullOrEmpty(this string value) e .HasValue(this string value)

Tuttavia, se sono molto specifici e raramente utilizzato, Li ho messi in uno spazio dei nomi BaseNamepace.Extensions quindi devono essere importati manualmente e non mostrano nell'intelligenza che ingombra le cose dappertutto.

Answer 3

Inserisci le estensioni nello stesso spazio dei nomi delle classi che estendono. In questo modo, quando utilizzi la classe, le estensioni sono disponibili per te.

• Se si sta scrivendo un'estensione per Uri, inserire l'estensione in Sistema.
• Se è un'estensione per DataSet, inserirla in System.Data.

Inoltre, Microsoft dice questo circa i metodi di estensione:

In generale, si consiglia di implementare metodi di estensione con parsimonia e solo quando si deve. Ogni volta che è possibile, il codice client che deve estendere un tipo esistente dovrebbe farlo da creando un nuovo tipo derivato dal tipo esistente .

Per ulteriori informazioni sui metodi di estensione, vedere the MSDN page sui metodi di estensione.

Answer 4

Ho svettato la risposta da user276695 che sembrava la soluzione più semplice. Tuttavia ho trovato una soluzione ancora migliore: niente spazio dei nomi. È possibile inserire una classe statica con i metodi di estensione nella stessa radice di un file, senza avvolgere alcuna dichiarazione dello spazio dei nomi attorno ad esso. Quindi i metodi di estensione saranno disponibili senza dover importare/utilizzare alcun namespace. †

Sono un po 'preoccupato di essere stato sottomesso dai nazisti dello spazio dei nomi. Ma mi sento in dovere di sostenere una posizione poco ortodossa.Almeno nella mia linea di lavoro (IT) trovo che la maggior parte dei miei strumenti personalizzati sono più facili da mantenere senza spazi dei nomi e che colloca tutto in un gigantesco spazio dei nomi anonimo. Sono sicuro che ci sono altri universi di programmazione in cui ciò non funzionerebbe altrettanto bene. Ma le perferenze delle circostanze & sono diverse, volevo solo sottolineare che in realtà è possibile dichiarare classi senza spazi dei nomi, anche classi con metodi di estensione - per coloro che trovano anche un gigantesco namespace anonimo.

† È inoltre possibile salvare un livello di indentazione. :-) E anche con 3 monitor giganti sono sempre alla ricerca di modi per salvare lo schermo immobiliare.

Answer 5

La mia pratica consiste nel mettere le estensioni in uno spazio dei nomi diverso da quello che identifica chiaramente lo spazio dei nomi di origine che sto estendendo.

In generale, ho creare uno spazio dei nomi anteponendo la mia parte "ragione sociale" del percorso dello spazio dei nomi davanti al namespace sto estendendo, e poi il suffisso con ".Extensions"

Ad esempio, se io Sto estendendo (senza una buona ragione) ::System.Text.StringBuilder perché è sigillato, quindi inserirò le mie estensioni nello spazio nomi ::CodeCharm.System.Text.Extensions.

Questa è una regola empirica per quando faccio estensioni che sospetto di poter riutilizzare quelle estensioni in altre soluzioni.

Answer 6

Se li metti in uno spazio dei nomi più alto del tuo attuale, saranno visibili automaticamente.

Quindi, se si dispone di spazi dei nomi per progetti come:

AdventureWorksInc.Web 
AdventureWorksInc.Logic 
AdventureWorksInc.DataAccess 

quindi dichiarare la propria estensione direttamente in:

namespace AdventureWorksInc 
{ 
    public static class HtmlHelpers 
    { 
     public static string AutoCloseHtmlTags(this string html) 
     { 
      //... 
     } 

    } 
} 

Questo metodo di estensione verrà visualizzato ogni volta che si sta scrivendo codice in qualsiasi spazio nome sub di AdventureWorksInc senza la necessità di utilizzare una dichiarazione.

Tuttavia, l'estensione di cui sopra dimostra un possibile svantaggio. A causa del fatto che funziona su stringhe, verrà ora visualizzato come un metodo di estensione per tutte le stringhe, incluse quelle che non sono realmente HTML. Questo non è in realtà un problema con lo scope dei nomi, ma semplicemente un uso improprio di un metodo di estensione. Questa dovrebbe essere una statica regolare che richiede un parametro standard, quindi la chiamata è esplicita.

Generalmente, i metodi di estensione ben progettati con parametri tipizzati correttamente non verranno visualizzati in tipi che non si applicherebbero mai.