Uso de espacio de nombres c ++ y reglas de nomenclatura

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 problema para agregar un tercer espacio de nombres. Por ejemplo, para agregar '' str '': productName :: utilityModuleName :: str - para dividir el espacio donde todas las '' cadenas '' las cosas relacionadas irán.

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

Por ejemplo

class productName::mainModuleName::DomainObject

y

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

puede ser ambos en

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

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

El 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

Para qué son los espacios de nombres:

Los espacios de nombres están destinados a establecer el contexto solo para que no tenga conflictos de nombres.

Reglas generales:

No es necesario especificar demasiado contexto y causará más inconvenientes de lo que vale.

Por lo tanto, desea utilizar su mejor criterio, pero aún así seguir estas 2 reglas:

• No sea demasiado general cuando use espacios de nombres
• No sea demasiado específico cuando use espacios de nombres

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

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

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

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

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

Cuando tiene espacios de nombres que son demasiado específicos, la línea entre estos espacios de nombres distintos comienza a desdibujarse. Empiezas a usar los espacios de nombres uno dentro del otro de un lado a otro. En este momento, es mejor generalizar el código común en el mismo espacio de nombres.

Clases con todas las plantillas estáticas vs:

  

" ¿Por qué deberíamos crear interior no   clases privadas y no espacios de nombres?   ¿Por qué deberíamos crear clases donde todos   los métodos son estáticos "

Algunas diferencias:

• Los espacios de nombres pueden estar implícitos usando la palabra clave using
• Los espacios de nombres pueden tener un alias, las clases son tipos y se pueden tipificar
• Se pueden agregar espacios de nombres a; puede agregarle funcionalidad en cualquier momento y agregarle directamente
• No se pueden agregar clases sin crear una nueva clase derivada
• Los espacios de nombres pueden tener declaraciones directas
• Con las clases puedes tener miembros privados y miembros protegidos
• Las clases se pueden usar con plantillas

Exactamente cómo dividir:

  

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

Es demasiado subjetivo decir exactamente cómo dividir su código sin el código fuente exacto. La división basada en los módulos suena lógica, pero no todo el producto.

Answer 2

Todo esto es subjetivo, pero dudaría en ir a más de 3 niveles de profundidad. Simplemente se vuelve demasiado 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 todos los subsistemas.

Answer 3

Me parece que está intentando utilizar espacios de nombres como herramienta de diseño. No están destinados a eso, están destinados a evitar conflictos de nombres. Si no tiene los enfrentamientos, no necesita los espacios de nombres.

Answer 4

Divido los espacios de nombres en función de sus usos:

Tengo un espacio de nombres separado, donde he definido todas mis interfaces (clases virtuales puras).

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

Y tengo un espacio de nombres separado, donde tengo mis objetos de negocio centrales (lógica de negocios) (como el orden de compra, 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 crees que están bien, deberías ir con él.