Namespace per argomento o per scopo? [chiuso]

Question

Namespace per argomento o per scopo? [chiuso]

#1 da (2 voti)

3

Il progetto a cui sto lavorando ha alcune classi. Queste classi possono essere raggruppate in due modi diversi. Sto cercando di decidere quale gruppo è il migliore come per il namespace. Attualmente sono un insieme di classi che affrontano l'utente che assomigliano a:

JamJar
HoneyJar
PeanutButterJar
ecc ...

Sono tutti simili in quanto tutti ereditano da SpreadableJar , ogni prefisso espandibile potrebbe essere considerato un "argomento" all'interno del progetto.

Ho anche una serie di oggetti relativi a questi argomenti, ogni argomento di solito ha un insieme di definizioni costanti e classi di messaggi ad esso associati quindi mi ritrovo con un fascio di file come:

JamDefinitions
PeanutButterSpreadMessage
HoneyDefinitions
JamRemoveMessage
ecc ...

Posso pensare a due modi per organizzare questi file:

Per argomento Il primo livello è spazio dei nomi, il secondo è classe / nome del file.
- Jam
  - Jar
  - Definizioni
  - removeMessage
  - ecc ...
- Miele
  - Jar
  - Definizioni
  - ecc ...
- PeanutButter
  - Jar
  - Definizioni
  - SpreadMessage
  - ecc ...

Questo sembra ordinato (rimuove i nomi duplicati) ed è utile per l'utente della libreria, ma significa che tutti i file Jar hanno lo stesso aspetto nella struttura del progetto, e ogni classe Jar non ha più un nome descrittivo. Significa anche che gli oggetti correlati sono raggruppati in modo che non abbiano bisogno di spaziare l'uno nell'altro nei namespace

Per scopo
- Vasi
  - JamJar
  - HoneyJar
  - PeanutButterJar
- Definizioni
  - JamDefinitions
  - HoneyDefinitions
  - PeanutButterDefinitions
- Messaggi
  - JamRemoveMessage
  - ecc ...

In questo modo è chiaro all'utente se sa che è necessario utilizzare Jars (il resto degli oggetti non sarà necessario per gli utenti esterni) e separa il gran numero di messaggi e i file di definizioni separati dal principale funzionalità, ma ora i Jars dovranno spostarsi negli altri namespace per le loro definizioni e messaggi e la denominazione dei file diventa più complessa. Il "Jar" di JamJar non può essere rimosso perché la classe non è solo "Jam".

Qual è l'approccio migliore qui? Mi manca qualche ovvia soluzione o errore nella mia struttura?

naming namespace project-structure

posta innova 09.07.2015 - 08:00

fonte

1 risposta

Leggi altre domande sui tag naming namespace project-structure

Guida alla libreria asincrona Progettazione: problema di architettura dell'app Web .NET

score 2 · Answer 1

Quale dei due è più probabile:

Qualcuno sta lavorando con un barattolo di marmellata e, mentre lo fa, vuole vedere una definizione di inceppamento
Qualcuno sta lavorando con un barattolo di marmellata e, mentre lo fanno, vogliono guardare un barattolo di miele?

Sei nella posizione migliore per rispondere a questa domanda, data la tua conoscenza del progetto, ma in generale direi che il primo di questi due sembra molto più comune. Quando si lavora su funzionalità relative alla marmellata, il tuo lavoro può comprendere diverse classi interdipendenti. Sembra molto meno probabile che tu voglia lavorare su molte classi per funzionalità / caratteristiche non correlate solo perché lo scopo che servono è simile (anche se può occasionalmente presentarsi, ad esempio quando si tratta di preoccupazioni trasversali).

Dato questo, direi che lo spazio dei nomi di primo livello dovrebbe essere argomento, consentendo un facile raggruppamento del codice correlato.

Come per

(removes duplicated names) ... but means that all the Jar files look the same in the project structure, and each Jar class no longer has a descriptive name.

Questo è un trade-off che hai scelto di infliggere a te stesso. Per esempio, non c'è nulla che ti impedisca di avere Jam.JamJar .

Mentre posso vedere l'argomento per non voler duplicare nomi del genere, la rimozione complessiva della parte Jam dal nome sembra un compromesso. Non funziona affatto con le importazioni / gli usi dello spazio dei nomi. Se importi un singolo spazio dei nomi, le tue classi finiscono con nomi meno descrittivi. Se importi più domini, ti ritroverai con ambiguità che sono fastidiose da risolvere.

Potresti forse importare lo spazio dei nomi di base, quindi fare Jam.Jar , ecc., ma questo è atipico, le persone non saranno veramente abituate a farlo e potresti trovarti improvvisamente a scrivere una nuova classe che non si adatta bene in questo schema di denominazione più rigido.