Quando non è giusto aggiungere tipi a uno spazio dei nomi ben noto?

Lasciami rispondere alla domanda effettiva che è:

When it isn't right to add types to a well known namespace?

La domanda dovrebbe piuttosto essere la seguente: quando è giusto farlo perché di solito non è mai giusto aggiungere qualcosa per conoscere gli spazi dei nomi. Lo fai solo quando vuoi utilizzare un meccanismo molto specifico.

Con questo cambiamento in mente ...

Vuoi farlo quando vuoi che il compilatore scelga l'estensione anziché quella fornita dal framework.

Esempio

Potresti voler utilizzare l'estensione ToList migliorata che ha esattamente la stessa firma di quella in System.Linq spazio dei nomi. Quindi la prima cosa che devi fare è creare questo:

namespace Company.Linq
{
    public static class MyCustomExtensions
    {
        public static List<TSource> ToList<TSource>(this IEnumerable<TSource> source)
        {
            ...
        }
    }
}

Ma è molto probabile che il compilatore rifiuterà di costruire il tuo progetto ora perché non è sicuro di quale ToList debba usare.

The call is ambiguous between the following methods or properties: 'System.Linq.Enumerable.ToList(System.Collections.Generic.IEnumerable)' and 'Company.Linq.Custom.ext.ToList(System.Collections.Generic.IEnumerable)'

Questo significa che non puoi usare System.Linq e Company.Linq (o qualsiasi altro spazio dei nomi che contiene questa estensione) allo stesso tempo. Questo potrebbe essere un grosso problema in caso di Linq.

Puoi risolverlo inserendo le estensioni in un namesapce più specifico, quindi System.Linq , ad esempio System.Linq.Custom .

Ora il compilatore sceglierà la tua estensione su quella predefinita perché il tuo spazio dei nomi è più specifico.

When there are many of them, it starts to get confusing between what are 'official' types and 'in-house' types.

No, non lo farò, come ho detto. Non potrai creare il tuo progetto se importa estensioni con le stesse firme da due due diversi spazi dei nomi.

Devi decidere se le tue estensioni dovrebbero sostituire quelle originali o devi usare una firma diversa. Othewirse ci saranno conflitti.

Se hai abbastanza codice da riutilizzare, crea uno spazio dei nomi di società. Puoi organizzare il codice diffrente in diverse librerie, in modo da non dover includere il codice condiviso di tutte le società in ogni app.

Un esempio di come lo faccio è una libreria di classi di database che include i pacchetti di accesso ai dati gestiti da Oracle e dapper nuget e ha un paio di classi con semplici interfacce per recuperare dati da qualsiasi database di Oracle. Questa libreria è completamente separata dalla nostra libreria di logging, che fondamentalmente è solo NLog creata e avvolta per le nostre esigenze. Queste librerie vivono in compagnia. Rispettivamente gli spazi dei nomi Oracle e Company.Logger.

Penso che mettere i metodi di estensione in uno spazio dei nomi separato sia un approccio migliore. L'argomento menzionato può rendere difficile determinare quale sia la versione personalizzata rispetto alla libreria fornita. Alla fine potresti avere firme in conflitto (nome del metodo e parametri), ecc. A seconda delle dimensioni della tua applicazione.

Uso uno spazio dei nomi basato su società personalizzato e prefisso il nome del metodo di estensione con un carattere di sottolineatura, ad esempio:

public static Boolean _IsNullOrEmpty(this ICollection target)
{ 
    // ...
}

Così facendo

• risolve l'ambiguità
• migliora la rilevabilità, poiché la maggior parte delle volte si desidera questo metodo, soprattutto se migliora quello predefinito.
• chiarisce che si tratta di un metodo di estensione personalizzato semplicemente guardando il codice, senza bisogno di ispezionare o controllare dove è definito.

Alcuni lo odiano, altri lo trovano un'idea intelligente ...