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.
- Dominio de la clase
- ¿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.
- No tiene espacios de nombres demasiado profundos, 3 (.) Es suficiente. Más de eso puede ser molesto.
- 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.
- 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.