Quando avremo qualche utilità pratica per gli spazi dei nomi gerarchici in c ++?

StackOverflow https://stackoverflow.com/questions/117110

  •  02-07-2019
  •  | 
  •  

Domanda

Posso capire l'uso per un livello di spazi dei nomi. Ma 3 livelli di spazi dei nomi. Sembra folle. C'è qualche uso pratico per quello? O è solo un malinteso?

È stato utile?

Soluzione

Gli spazi dei nomi gerarchici sono utili in quanto consentono definizioni progressivamente più raffinate. Certamente un singolo fornitore può produrre due classi con lo stesso nome. Spesso il primo livello è occupato dal nome dell'azienda, il secondo specifica il prodotto, il terzo (e forse più) il mio fornisce il dominio.

Ci sono anche altri usi della segregazione dello spazio dei nomi. Una situazione popolare è quella di posizionare le classi base per un modello di fabbrica nel proprio spazio dei nomi e quindi derivare le fabbriche nei propri spazi dei nomi dal provider. Per esempio. System.Data , System.Data.SqlClient e System.Data.OleDbClient .

Altri suggerimenti

Ovviamente è una questione di opinione. Ma si riduce davvero all'organizzazione. Ad esempio, ho un progetto che ha un API api che ha funzioni / oggetti che assomigliano a questo:

plugins::v1::function

Quando viene lanciato 2.0 verranno inseriti nello spazio dei nomi secondari v2. Ho in programma di deprecare solo ma non rimuovere mai i membri v1 che dovrebbero supportare la compatibilità con le versioni precedenti in futuro. Questo è solo un esempio di " sane " utilizzo. Immagino che alcune persone differiranno, ma come ho detto, è una questione di opinione.

Ne serviranno grandi codebase. Guarda boost per un esempio. Non credo che qualcuno chiamerebbe il codice boost "folle".

Se consideri il fatto che a qualsiasi livello di una gerarchia, le persone possono comprendere solo da qualche parte all'incirca nell'ordine di 10 elementi, allora due livelli ti danno solo 100 al massimo. Un progetto sufficientemente grande avrà bisogno di più, quindi può facilmente finire con 3 livelli di profondità.

Lavoro sull'applicazione XXX nella mia azienda yyy e sto scrivendo un sottosistema GUI. Quindi uso yyy :: xxx :: gui come mio spazio dei nomi.

Puoi trovarti facilmente in una situazione in cui hai bisogno di più di un livello. Ad esempio, la tua azienda ha un gigantesco spazio dei nomi per tutto il suo codice per separarlo dal codice di terze parti e stai scrivendo una libreria che vuoi mettere nel suo stesso spazio dei nomi. In genere, ogni volta che si dispone di un sistema molto grande e complesso, suddiviso gerarchicamente, è ragionevole utilizzare diversi livelli di spazio dei nomi.

Dipende dalle tue esigenze e dallo stile di programmazione. Ma uno dei vantaggi di namespace è di aiutare lo spazio dei nomi delle partizioni (da qui il nome). Con un singolo spazio dei nomi, poiché il tuo progetto aumenta di dimensioni e complessità, aumenta anche la probabilità di collisione dei nomi.

Se stai scrivendo codice che deve essere condiviso o riutilizzato, questo diventa ancora più importante.

Accetto le domande. La maggior parte delle persone che usano più livelli di spazi dei nomi (nella mia esperienza) provengono da uno sfondo Java o .NET in cui il rumore è significativamente inferiore. Trovo che buoni prefissi di classe possano prendere il posto di più livelli di spazi dei nomi.

Ma ho visto un buon uso di più livelli di spazio dei nomi in boost (e altre librerie). Tutto è nello spazio dei nomi boost, ma alle librerie è consentito (incoraggiato?) Di essere nel proprio spazio dei nomi. Ad esempio - boost :: this_thread namespace. Permette cose come ...

boost::this_thread::get_id()
boost::this_thread::interruption_requested()

" this_thread " è solo uno spazio dei nomi per una raccolta di funzioni gratuite. Potresti fare la stessa cosa con una classe e funzioni statiche (cioè il modo Java di definire una funzione libera), ma perché fare qualcosa di innaturale quando il linguaggio ha un modo naturale di farlo?

Basta guardare la libreria di classi base .Net per vedere una gerarchia dello spazio dei nomi messa a frutto. Raggiunge quattro o cinque livelli di profondità in alcuni punti, ma per lo più sono solo due o tre e l'organizzazione è molto piacevole per trovare le cose.

Maggiore è la base di codice, maggiore è la necessità di spazi dei nomi gerarchici. Man mano che il tuo progetto diventa sempre più grande, scopri che devi dividerlo in modo da trovare più facilmente le cose.

Ad esempio, attualmente utilizziamo una gerarchia di 2 livelli. Tuttavia, alcune delle porzioni più grandi di cui stiamo parlando ora sono suddivise in 3 livelli.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top