C++ regole di utilizzo dello spazio dei nomi e denominazione

Question

Sul progetto stiamo cercando di raggiungere un accordo sull'utilizzo dello spazio dei nomi. Abbiamo deciso che il primo livello sarà "productName" e il secondo è "moduleName".

productName::moduleName 

Ora, se il modulo è una specie di Modulo d'utenza non c'è nessun problema di aggiungere un terzo dello spazio dei nomi. Ad esempio per aggiungere "str": productName :: utilityModuleName :: str - per dividere lo spazio dove andranno tutte le cose relative alle "stringhe".

Se il modulo è il modulo aziendale principale, abbiamo molte opportunità e quasi nessun accordo.

Per esempio

class productName::mainModuleName::DomainObject 

e

class productName::mainModuleName::DomainObjectSomethingElseViewForExample 

può essere sia a

namespace productName::mainModuleName::domainObject 
class Data 
class ViewForExample 

Perché dovremmo creare classi interne non privato e non gli spazi dei nomi? Perché dovremmo creare una classe in cui tutti i metodi sono statici (eccetto i casi in cui questa classe diventerà un parametro template)?

Il progetto è costituito da 1 Gb di codice sorgente. Quindi, qual è la migliore pratica per dividere i moduli su namespace nel C++?

Answer 1

Quali spazi dei nomi sono per:

namespace hanno lo scopo di stabilire il contesto solo così non si dispone di eventuali conflittualità di denominazione.

Regole generali:

Specifica troppo contesto non è necessario e causerà più disagi che vale la pena.

modo che si desidera utilizzare il vostro giudizio migliore, ma comunque seguire queste 2 regole:

• Non essere troppo generico quando si utilizzano gli spazi dei nomi
• Non essere troppo specifico quando si utilizzano gli spazi dei nomi

Non sarei così rigido su come usare i nomi dei nomi dei nomi e semplicemente utilizzare gli spazi dei nomi basati su un gruppo di codice correlato.

Perché gli spazi dei nomi che sono troppo generali non sono utili:

Il problema che divide lo spazio dei nomi che iniziano con il nome del prodotto, è che si hanno spesso una componente di codice, o qualche libreria di base che è comune a più prodotti.

Inoltre non si useranno gli spazi dei nomi Prodotto2 all'interno di Prodotto1, quindi specificare esplicitamente che non ha senso. Se includessi i file di Product2 all'interno di Product1, la conversione dei nomi è ancora utile?

Perché gli spazi dei nomi che sono troppo specifico non sono utili:

Quando si dispone di spazi dei nomi che sono troppo specifiche, la linea di demarcazione tra questi spazi dei nomi distinti iniziare a confondersi. Inizi a utilizzare i namespace l'uno dentro l'altro avanti e indietro. In questo momento è meglio generalizzare il codice comune insieme sotto lo stesso spazio dei nomi.

Classi con tutto statico vs modelli:

"? Perché dovremmo creare non classi privato e non interne spazi dei nomi Perché dovremmo creare classi in cui tutti i metodi sono statici"

Alcune differenze:

• namespace possono essere implicite utilizzando la parola using
• namespace può essere aliasing, classi sono tipi e possono essere typedef'ed
• namespace possono essere aggiunti; è possibile aggiungere funzionalità ad esso in qualsiasi momento e aggiungere ad essa direttamente
• classi non possono essere aggiunti a senza fare una nuova classe derivata
• namespace possono avere dichiarazioni previsionali
• Con le classi si possono avere membri privati ​​e membri protetti
• Le classi possono essere utilizzati con i modelli

Esattamente come dividere:

"Il progetto è costituito da 1 Gb di codice sorgente . Quindi, qual è la migliore pratica per moduli dividere in spazi dei nomi nel C++?"

E 'troppo soggettivo per dire esattamente come dividere il codice senza il codice sorgente esatto. Divisione in base a moduli anche se sembra logico non solo l'intero prodotto

Answer 2

Questo è tutto soggettivo, ma esiterei ad andare più di 3 livelli in profondità. A un certo punto diventa troppo ingombrante. Quindi, a meno che il tuo codice base sia molto, molto grande, lo terrei piuttosto superficiale.

Dividiamo il nostro codice in sottosistemi e abbiamo uno spazio dei nomi per ogni sottosistema. Le cose utili andrebbero nel loro spazio dei nomi, se davvero sono riutilizzabili nei sottosistemi.

Answer 3

Mi sembra che si stia tentando di utilizzare gli spazi dei nomi come uno strumento di progettazione.Non sono destinati a questo scopo, ma hanno lo scopo di prevenire conflitti di nomi .Se non si hanno conflitti , non hai bisogno degli spazi dei nomi.

Answer 4

ho dividere gli spazi dei nomi a seconda delle sue usanze:

Ho un namespace separato, dove ho definito tutte le mie interfacce (classi virtuali puri).

Ho uno spazio dei nomi separato, in cui ho definito le mie classi di libreria (come la libreria db, la libreria di elaborazione).

E ho uno spazio dei nomi separato, in cui ho gli oggetti della mia attività principale (business logic) (come purchase_order, ecc.).

Immagino, si tratta di definirlo in un modo, che non diventa difficile da gestire in futuro. Quindi, puoi verificare le difficoltà che circonderanno il tuo attuale design.

E se pensi che stiano bene, dovresti seguirlo.