tutorial online learncpp for cpp beginners namespaces organization rules-of-thumb

namespaces - online - Espacio de nombres Regla de oro



learncpp (5)

¿Existe una regla general sobre cuántas clases, interfaces, etc. deberían entrar en un espacio de nombre dado antes de que los artículos se clasifiquen en un nuevo espacio de nombre? ¿Como una mejor práctica o una preferencia de la comunidad? ¿O es esto una preferencia personal?

namespace: MyExample.Namespace interface1 interface2 interface3 interface4 interface5 interface6 interface7 interface8 interface9

O

namespace: MyExample.Namespace.Group1 interface1 interface2 interface3 namespace: MyExample.Namespace.Group2 interface4 interface5 interface6 namespace: MyExample.Namespace.Group3 interface7 interface8 interface9

Generalmente se considera mala forma tener una pequeña cantidad de clases en un espacio de nombres. Siempre he atribuido esto al hecho de que muchos espacios de nombres generan confusión.

Sugeriría que dividas las clases en espacios de nombres lógicos siendo lo más razonable y práctico posible. Sin embargo, si termina con solo una o dos clases por espacio de nombres, es posible que se esté fracturando demasiado y deba pensar en consolidar.

No conozco ninguna regla general para la cantidad de artículos, pero ese tipo de reglas tienden a ser basura demasiado generalizada de todos modos. Asegúrese de que haya una conexión lógica entre los elementos en el mismo espacio de nombres. Si un espacio de nombres se está llenando demasiado (es poco probable, espero), o las cosas en el espacio de nombres están apenas relacionadas en el mejor de los casos, considere dividirlo en varios espacios de nombres.

No he visto ninguna regla general en ninguna fuente confiable, pero hay algunas preferencias comunes que he visto al trabajar con la mayoría de los desarrolladores. Hay algunas cosas que lo ayudan a crear los espacios de nombres.

  1. Dominio de la clase
  2. ¿Es una clase o una interfaz (he visto algunos desarrolladores prefieren espacios de nombres como ShopApp.Model.Interfaces). Funciona muy bien si sus interfaces son algún servicio o contrato de datos.
  3. No tiene espacios de nombres demasiado profundos, 3 (.) Es suficiente. Más de eso puede ser molesto.
  4. Esté abierto a reorganizar el espacio de nombres si en algún momento siente que se ha vuelto ilógico o difícil de administrar.
  5. No crees espacios de nombres por el simple hecho de hacerlo.

Happy Coding !!!

Si construye una biblioteca o un módulo, generalmente es mejor usar solo un espacio de nombres, ya que la función principal de un espacio de nombres es evitar las colisiones de nombres y usted tiene el control sobre qué nombres se asignan a las clases y las interfaces.

Yo argumentaría que la jerarquía del espacio de nombres solo debería ser modificada por consideraciones de diseño y la jerarquía del modelo / API.

Si un espacio de nombres tiene un gran número de clases no relacionadas, reconsidere su diseño.

Al contrario de lo que dijo Andrew, no me preocuparía el espacio de nombres que contiene pocas clases, aunque es cierto, por supuesto, que la jerarquía debería ser tan precisa como sea necesario para expresar el diseño.

Por otro lado, me parece completamente razonable que un espacio de nombres contenga solo una clase altamente especial, o quizás solo un conjunto muy pequeño de tipos, de los cuales uno codifica la tarea y los otros proporcionan una API (excepciones, enumeraciones para argumentos ... )

Como ejemplo, tome System.Text.RegularExpressions (en .NET). De acuerdo, un poco más de una clase, pero solo justa.