Namespace Regola del pollice

Question

Esiste una regola empirica generale su quante classi, interfacce ecc. dovrebbero entrare in un determinato spazio dei nomi prima che gli elementi vengano ulteriormente classificati in un nuovo spazio dei nomi? Ti piace una best practice o una preferenza della community? O è tutta una preferenza personale?

namespace: MyExample.Namespace
 interface1
 interface2
 interface3
 interface4
 interface5
 interface6
 interface7
 interface8
 interface9

o

namespace: MyExample.Namespace.Group1
 interface1
 interface2
 interface3
namespace: MyExample.Namespace.Group2
 interface4
 interface5
 interface6
namespace: MyExample.Namespace.Group3
 interface7
 interface8
 interface9

Answer 1

Non ho visto alcuna regola empirica su alcuna fonte affidabile, ma ci sono alcune preferenze comuni che non ho visto lavorando con la maggior parte degli sviluppatori. Ci sono alcune cose che ti aiutano a creare gli spazi dei nomi.

1. Dominio della classe
2. È una classe o un'interfaccia (ho visto alcuni sviluppatori preferire spazi dei nomi come ShopApp.Model.Interfaces). Funziona davvero bene se le tue interfacce sono un servizio o un contratto dati.
3. Non hai spazi dei nomi troppo profondi, 3 (.) è sufficiente. Più di questo può diventare fastidioso.
4. Sii aperto a riorganizzare lo spazio dei nomi se in qualsiasi momento ritieni che sia diventato illogico o difficile da gestire.
5. Non creare spazi dei nomi solo per il gusto di farlo.

Happy Coding !!!

Answer 2

Se si crea una libreria o un modulo, è generalmente meglio usare solo uno spazio dei nomi, poiché la funzione principale di uno spazio dei nomi è evitare collisioni di nomi e si ha il controllo su quali nomi vengono assegnati a classi e interfacce.

Answer 3

Non conosco alcuna regola empirica per il numero di articoli, ma questi tipi di regole tendono comunque ad essere spazzatura troppo generalizzata. Assicurarsi che sia presente una connessione logica tra gli elementi nello stesso spazio dei nomi. Se uno spazio dei nomi sta diventando troppo affollato (improbabile, spero), o le cose nello spazio dei nomi sono solo vagamente correlate nella migliore delle ipotesi, considera di dividerlo in più spazi dei nomi.

Answer 4

Direi che la gerarchia dello spazio dei nomi dovrebbe essere influenzata solo da considerazioni di progettazione e gerarchia del modello / API.

Se uno spazio dei nomi presenta un numero enorme di classi non correlate, ripensare il proprio progetto.

Contrariamente a quanto Andrew ha detto, non preoccuparsi degli spazi dei nomi che contengono poche classi & # 8211; anche se è ovviamente vero che la gerarchia dovrebbe essere solo granulosa quanto basta per esprimere il disegno.

D'altra parte, trovo del tutto ragionevole che uno spazio dei nomi contenga solo una classe altamente speciale, o forse solo un set molto piccolo di tipi, di cui uno codifica l'attività e gli altri forniscono un'API (eccezioni, enum per argomenti & # 8230;).

Ad esempio, prendi System.Text.RegularExpressions (in .NET). Concesso, leggermente più di una classe, ma solo.

Answer 5

In genere si ritiene che la forma errata abbia un piccolo numero di classi in uno spazio dei nomi. Ho sempre attribuito questo al fatto che molti spazi dei nomi portano alla confusione.

Suggerirei di dividere le classi in spazi dei nomi logici il più ragionevole e pratico possibile. Tuttavia, se finisci con solo una o due classi per spazio dei nomi, potresti fratturarti troppo e pensare al consolidamento.