Le migliori pratiche per la denominazione sottoclassi

Question

Sono spesso in una situazione in cui ho un concetto rappresentato da un'interfaccia o di classe, e poi ho una serie di sottoclassi / subinterfaces che si estendono esso.

Ad esempio: Un generico "DoiGraphNode" A "DoiGraphNode" che rappresenta una risorsa A "DoiGraphNode" che rappresenta una risorsa Java A "DoiGraphNode" con un percorso associato, ecc, ecc.

Mi vengono in mente tre convenzioni di denominazione, e gradirebbe commenti su come scegliere.

---

Opzione 1: iniziano sempre con il nome del concetto

.

Quindi:. DoiGraphNode, DoiGraphNodeResource, DoiGraphNodeJavaResource, DoiGraphNodeWithPath, etc

Pro: E 'molto chiaro che cosa ho a che fare con, è facile vedere tutte le opzioni che ho

Con: Non molto naturale? Tutto sembra lo stesso?

---

Opzione 2: Mettere la roba speciale in principio

.

Quindi: DoiGraphNode, ResourceDoiGraphNode, JavaResourceDoiGraphNode, PathBaseDoiGraphNode, ecc, ecc.

Pro: E 'molto chiaro quando lo vedo nel codice

Con: Trovare potrebbe essere difficile, soprattutto se non ricordo il nome, la mancanza di coerenza visiva

---

Opzione 3: Mettere la roba speciale e rimuovere una parte del testo ridondante

Quindi: DoiGraphNode, ResourceNode, JavaResourceNode, GraphNodeWithPath

Pro: Non è così molto da scrivere e leggere Con: Sembra cr * p, molto incoerente, può entrare in conflitto con altri nomi

Answer 1

li Nome per quello che sono.

Se dar loro un nome è difficile o ambiguo, è spesso un segno che la classe sta facendo troppo (Responsabilità unico principio).

Per evitare conflitti di denominazione, scegliere i vostri spazi dei nomi in modo appropriato.

Personalmente, mi piacerebbe utilizzare 3

Answer 2

Usa ciò che ti piace, è una cosa soggettiva. La cosa importante è quello di rendere chiaro ciò che ogni classe rappresenta, ei nomi deve essere tale che le relazioni di ereditarietà hanno senso. Io in realtà non credo che sia così importante per codificare i rapporti nei nomi, però; questo è ciò che la documentazione è per (e se i vostri nomi sono appropriati per gli oggetti, la gente dovrebbe essere in grado di fare buone congetture su ciò che eredita da ciò).

Per quel che vale, io di solito uso l'opzione 3, e dalla mia esperienza guardando opzione codice di altre persone 2 è probabilmente più diffuso di quanto l'opzione 1.

Answer 3

Si potrebbe trovare una guida in un documento standard di codifica, per esempio c'è il documento Idesign per C # qui .

Personalmente, preferisco l'opzione 2. Questo è generalmente il modo in cui i nomi di .NET Framework suoi oggetti. Ad esempio guardate classi di attributi. Tutti finiscono in Attribute (TestMethodAttribute). Lo stesso vale per EventHandlers:. OnClickEventHandler è un nome consigliato per un gestore di eventi che gestisce l'evento Click

Di solito cerco di seguire questa nel progettare il mio proprio codice e interfacce. Così un IUnitWriter produce uno StringUnitWriter e DataTableUnitWriter. In questo modo ho sempre sapere quale sia il loro classe di base è e si legge in modo più naturale. Codice di auto-documentazione è l'obiettivo finale per tutti gli sviluppatori agili così sembra funzionare bene per me!

Answer 4

Io di solito nome simile all'opzione 1, in particolare quando le classi verranno utilizzati polymophically. Il mio ragionamento è che il bit più importante di informazioni è nominata per prima. (Vale a dire il fatto che la sottoclasse è fondamentalmente ciò che l'antenato è, con (di solito) le estensioni 'aggiunto'). Mi piace questa opzione anche perché durante l'ordinamento gli elenchi dei nomi di classi, le classi relative verranno elencati insieme. Cioè Io di solito il nome della unità di traduzione (nome del file) lo stesso di Il nome della classe file di classe in modo correlati saranno naturalmente essere incluso insieme. Allo stesso modo questo è utile con la ricerca incrementale.

Anche se ho la tendenza ad utilizzare l'opzione 2 in precedenza nella mia carriera di programmazione, evito ora perché, come si dice che è 'incoerente' e non sembrano molto ortogonale.

Io uso spesso l'opzione 3 quando la sottoclasse fornisce estensione o specifica sostanziale, o se i nomi sarebbe piuttosto lungo. Ad esempio, il mio file classi nome di sistema sono derivate dalla stringa ma di estendere notevolmente la classe String e hanno un significativamente differente uso / significato:

Directory_entry_name derivato da String aggiunge funzionalità estese. File_name derivato da Directory_entry_name ha funzioni piuttosto specializzate. Directory_name derivato da Directory_entry_name ha anche funzioni piuttosto specializzate.

Anche lungo con l'opzione 1, io di solito uso un nome non qualificato per una classe di interfaccia. Per esempio potrei avere una catena di classe interence:

• Testo (interfaccia)
• Text_abstract (abstract (di base) di classe generalizzazione)
• Text_ASCII (classe concreta specifica per la codifica ASCII)
• Text_unicode (classe concreta specifica per la codifica unicode)

I po 'come che l'interfaccia e la classe astratta di base compaiono automaticamente prima nella lista ordinata.

Answer 5

Opzione tre segue più logicamente dal concetto di ereditarietà. Dal momento che stai specializzata l'interfaccia o classe, il nome dovrebbe dimostrare che non è più con l'implementazione di base (se ne esiste uno).

Ci sono una moltitudine di strumenti per vedere ciò che una classe eredita da, quindi un nome conciso che indica la vera funzione della classe andrà più lontano di cercare di mettere in valigia le informazioni sul tipo troppo nel nome.