Prefisso basato sul progetto per i nomi delle classi [chiuso]

5

Il mio capo progetto usa prefissi basati su progetto per nomi di classi, diciamo che il nome del progetto ABC, crea il nome della classe User come ABCUser. e dice che lo fa perché può voler far confondere gli utenti di User.aspx. così gli ho detto perché non usare namespace (Entity.User ie.) per renderlo specifico ma lui contro di esso. Mi piacerebbe sentire l'opinione di voi ragazzi su questo argomento.

Codifichiamo c # .net e utilizziamo Visual Studio per i progetti.

    
posta Mert 24.06.2014 - 08:56
fonte

2 risposte

12

Modifica : questa risposta non è specificamente orientata alla denominazione specifica del progetto, ma credo che il principio possa essere applicato anche. In una delle mie applicazioni, ho tre progetti VS separati che non separo con i namespace né con i prefissi di classe come convenzione di denominazione. Gli spazi dei nomi sarebbero un modo possibile per separare le entità per progetto e sarebbe il mio metodo preferito di separazione se ne avessi effettivamente bisogno.

Nella mia esperienza in C #, gli spazi dei nomi esistono proprio per questo motivo .

Se definisci una classe Dog e la classe Cat , è logica per inserirli in uno spazio dei nomi chiamato Animals o Housepets (a seconda dello scopo del tuo programma).

È non , tuttavia, logico anteporre le classi a ciò che normalmente useresti per uno spazio dei nomi: ad es. AnimalCat come nome di classe.

Il fatto che gli spazi dei nomi possano essere definiti dentro altri namespace significa che hai una grande capacità di creare un'organizzazione gerarchica. Se si utilizzano i prefissi per i nomi delle classi, tale prospettiva scompare immediatamente. Considera i seguenti due esempi:

Prefissi del nome classe

public class LanguageExtendedDictionary
{
    public SortedDictionary<string> wordList { get; set; } // quick spell-check
    public SortedDictionary<string, LanguageWord> dictionary { get; set; } // full entries
}

public class LanguageWord
{
    public string word { get; set; }
    public string definition { get; set; }
}

Con questo, gli schemi di denominazione si riempiono velocemente. In qualsiasi applicazione di grandi dimensioni, potresti avere più di 50 classi. Riesci a immaginare di provare a passare tipi di dati come SortedDictionary<LanguageWord> ? Nella mia esperienza, i nomi di classi lunghe sono difficili da leggere e più difficili da codificare. I nomi delle classi dovrebbero (a mio parere) essere il più brevi possibile per rappresentare con precisione l'entità che sta modellando.

Immagina se avessimo supporto nella nostra applicazione per molte lingue. Vorresti creare una classe con il nome LanguageFrenchWord per dinstinguish tra quella e l'inglese? Io di certo non lo farei.

Questo metodo non lascia spazio a organizzazione della classe , che è estremamente importante, specialmente in linguaggi come C #, Java, ecc.

namespace

namespace Language
{
    public class ExtendedDictionary
    {
        public SortedDictionary<string> wordList { get; set; } // quick spell-check
        public SortedDictionary<string, Word> dictionary { get; set; } // full entries
    }

    public class Word
    {
        public string word { get; set; }
        public string definition { get; set; }
    }
}

Potresti inizializzare le istanze come:

var word = new Language.Word(); // if declared outside of namespace

o anche semplicemente

var word = new Word(); // if declared inside namespace

Questo ti permette di separare quali entità sono in quale relazione e di distinguerle. Queste entità sono raggruppate in modo logico perché devono gestire lingue (s) . Questo ha senso quando la complessità aumenta. Forse avrei uno spazio dei nomi per cose che riguardano French , e aggiungerei French come spazio dei nomi annidato sotto Language ; per esempio. Language.French .

Con un'istruzione using , come using Language o using Language.French , puoi eliminare la necessità di chiamare Language.Word() e chiamare invece Word() .

Citerò anche che, come vedi nell'esempio precedente, non ho bisogno di usare il prefisso Language. all'interno di quello spazio dei nomi. Quindi in ExtendedDictionary , non ho bisogno di usare Language.Word come tipo nella variabile dictionary , perché entrambe le entità si trovano nello stesso spazio dei nomi. Questo riduce un lotto di clutter di nome. Con il metodo del prefisso di classe, non puoi evitare la confusione. Con gli spazi dei nomi, fa parte della funzionalità del linguaggio e rende le cose intrinsecamente più leggibili.

Man mano che la complessità aumenta, l'uso dei prefissi causa un sacco di confusione nel nome e un'enorme mancanza di organizzazione . Probabilmente ci sono molte cose buone che puoi fare con gli spazi dei nomi in C #, di cui sono semplicemente inconsapevole. Sono stati creati per una ragione, e questo è il mio caso d'uso principale per loro. Sembra che questo sia ciò che il tuo capo sta cercando di emulare (il comportamento), quindi perché non utilizzare gli strumenti forniti nella lingua per farlo?

Una nota a margine: per quanto ne so, l'intera libreria .NET utilizza gli spazi dei nomi per separare le classi; per esempio. System.Text , System.Threading , ecc. Sembrano la struttura appropriata da usare!

    
risposta data 24.06.2014 - 09:35
fonte
0

Attualmente lavoro su un grande progetto in cui ogni classe è preceduta dal nome del progetto. Stranamente aiuta parecchio, se hai un file, puoi trovare la classe molto facilmente.

Ora immagino che questo non aiuti molto se hai una dozzina o due file, ma quando ne hai molte centinaia ... le cose sono diverse. Quindi non è una cattiva idea per se, e non ti farà male avere un tale standard.

Detto questo, ci sono altri modi per pelare i gatti. quindi uno spazio dei nomi per ogni progetto e mantenere i file organizzati in un altro modo per essere sicuri di poter determinare rapidamente da quale parte del progetto proviene un determinato file.

Non mi lamenterei particolarmente. Un nome è buono come un altro, quindi cosa succede se si chiama ABCUser o ABC.User. A volte norme banali come questo non valgono la pena di preoccuparsi. Salva la tua polvere per il posizionamento delle staffe e l'utilizzo #region.

    
risposta data 24.06.2014 - 09:25
fonte

Leggi altre domande sui tag