reglas de nomenclatura y uso del espacio de nombres C++

Question

En el proyecto, estamos tratando de llegar a un acuerdo sobre el uso del espacio de nombres. Decidimos que el primer nivel será "productName" y el segundo es "moduleName".

productName::moduleName 

Ahora, si el módulo es una especie de módulo de utilidad, no hay ningún problema para agregar un tercer espacio de nombres. Por ejemplo, para agregar "str": productName :: utilityModuleName :: str - para dividir el espacio donde irán todas las cosas relacionadas con "cadenas".

Si el módulo es el módulo principal de negocios, tenemos muchas oportunidades y casi ningún acuerdo.

Por ejemplo

class productName::mainModuleName::DomainObject 

y

class productName::mainModuleName::DomainObjectSomethingElseViewForExample 

puede ser ambas cosas a

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

¿Por qué debemos crear las clases internas no privado y no espacios de nombres? ¿Por qué deberíamos crear una clase donde todos los métodos sean estáticos (excepto en los casos en que esta clase va a ser un parámetro de plantilla)?

Proyecto consiste en 1Gb de código fuente. Entonces, ¿cuál es la mejor práctica para dividir módulos en espacios de nombres en C++?

Answer 1

Qué son espacios de nombres para:

espacios de nombres se pretende establecer el contexto solamente por lo que no tiene confilcts de nombres.

reglas generales:

Especificación demasiada contexto no es necesario y se causan más molestias de lo que vale.

Así que usted quiere utilizar su mejor juicio, pero aún así seguir estas reglas 2:

• No sea demasiado general cuando se utilizan espacios de nombres
• No sea demasiado específica al utilizar espacios de nombres

No sería tan estricto sobre cómo usar nombres de espacios de nombres, y simplemente usar espacios de nombres basados ​​en un grupo de código relacionado.

Por qué espacios de nombres que son demasiado generales no son útiles:

El problema de dividir el espacio de nombres empezando por el nombre del producto, es que a menudo tendrá un componente de código, o alguna biblioteca de la base de que es común a múltiples productos.

Tampoco utilizará los espacios de nombres de Product2 dentro de Product1, por lo que especificarlo explícitamente no tiene sentido. Si incluía los archivos de Product2 dentro de Product1, ¿esta conversión de nomenclatura sigue siendo útil?

Por qué espacios de nombres que son demasiado específicos no son útiles:

Cuando tiene espacios de nombres que son demasiado específicas, la línea que separa estos espacios de nombres distintos comenzar a difuminar. Empiezas a utilizar los espacios de nombres dentro de cada uno de ida y vuelta. En este momento, es mejor generalizar el código común bajo el mismo espacio de nombres.

Las clases con toda estática vs plantillas:

"? ¿Por qué debemos crear no clases particulares y no interiores espacios de nombres ¿Por qué debemos crear clases donde todos métodos son estáticos"

Algunas diferencias:

• espacios de nombres pueden estar implícitas utilizando la palabra clave using
• espacios de nombres puede ser alias, las clases son tipos y pueden ser typedef'ed
• espacios de nombres pueden añadirse a; puede agregar funcionalidad a ella en cualquier momento y agregar a ella directamente
• Las clases no se pueden agregar a sin hacer una nueva clase derivada
• espacios de nombres pueden tener declaraciones adelantadas
• Con las clases que puede tener miembros privados y miembros protegidos
• Las clases pueden ser usados ​​con plantillas

Exactamente cómo dividir:

"Proyecto consiste en 1Gb del código fuente . Así que, ¿cuál es la mejor práctica para módulos dividir en espacios de nombres en el C++?"

Es demasiado subjetiva decir exactamente cómo dividir su código sin el código fuente exacta. División basándose en los módulos embargo sonidos lógicos , simplemente no todo el producto.

Answer 2

Esto es todo subjetivo, pero dudaría en ir más de 3 niveles de profundidad. Simplemente se vuelve muy difícil de manejar en algún momento. Entonces, a menos que su código base sea muy, muy grande, lo mantendría bastante superficial.

Dividimos nuestro código en subsistemas y tenemos un espacio de nombres para cada subsistema. Las cosas de utilidad irían a su propio espacio de nombres si de hecho son reutilizables en subsistemas.

Answer 3

Me parece que está tratando de usar espacios de nombres como herramienta de diseño. No están destinados para eso, están destinados a evitar conflictos de nombres. Si no tiene los enfrentamientos , no necesitas los espacios de nombres.

Answer 4

que dividir espacios de nombres en función de sus usos:

que tienen un espacio de nombres separado, donde he definido todos mis interfases (clases virtuales puras).

Tengo un espacio de nombres separado, donde he definido las clases de mi biblioteca (como la biblioteca db, la biblioteca de procesamiento).

Y tengo un espacio de nombre separado, donde tengo mis objetos principales de negocio (lógica comercial) (como purchase_order, etc.).

Supongo que se trata de definirlo de una manera que no se vuelva difícil de manejar en el futuro. Por lo tanto, puede verificar las dificultades que rodearán su diseño actual.

Y si cree que están bien, debería hacerlo.