2009-01-10 37 views
7

¿Existe una regla general sobre cuántas clases, interfaces, etc. deberían ir a un espacio de nombre dado antes de que los elementos 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?Regla de espacio de nombres

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 

Respuesta

4

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. Manténgase abierto para reorganizar el espacio de nombres si en algún momento siente que se ha vuelto ilógico o difícil de administrar.
  5. No cree espacios de nombres por el simple hecho de hacerlo.

Happy Coding !!!

+0

Buena respuesta. Otra cosa a tener en cuenta es que el # 4 podría ser problemático si estás trabajando en una biblioteca existente, así que asegúrate de hacerlo bien la primera vez si tienes la oportunidad. ;) –

0

En general se considera mala forma para tener un pequeño número de clases en un espacio de nombres. Siempre he atribuido esto al hecho de que muchos espacios de nombres generan confusión.

Le sugiero que divida 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.

+1

"Generalmente se considera mala forma" - ¿por quién? Esto parece muy controvertido y en absoluto general. Nunca escuché eso. –

+0

Es algo de lo que FxCop siempre se queja, eso es prácticamente todo lo que tengo para respaldarme :) –

+0

Aunque Microsoft no es la generalidad, especialmente no en el campo muy genérico de espacios de nombres; casi todos los lenguajes de programación no son de Microsoft; Además, en mi humilde opinión, el número de clases dentro de un espacio de nombres no es lo que debería justificar su existencia, pero otras razones son –

2

No conozco ninguna regla de oro para la cantidad de artículos, pero ese tipo de reglas suelen ser basura demasiado generalizada. 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.

2

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

+1

+1 para enfatizar el uso real de Namespace – Perpetualcoder

1

Me atrevería a decir 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, vuelva a pensar su diseño.

Al contrario de lo que Andrew dijo, lo haría no se preocupe por los espacios de nombres que contienen algunas clases - aunque es cierto que la jerarquía sólo debe ser tan grano fino 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 tal vez solo un conjunto muy pequeño de tipos, 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.

Cuestiones relacionadas