Número de clases en un espacio de nombres - ¿Olor de código?


11

Tengo una biblioteca de C # que utilizan varios ejecutables. Solo hay un par de espacios de nombres en la biblioteca, y acabo de notar que uno de los espacios de nombres tiene bastantes clases. Siempre he evitado tener demasiadas clases en un solo espacio de nombres debido a la categorización, y porque inconscientemente, creo que parece "más bonito" tener una jerarquía más profunda de espacios de nombres.

Mi pregunta es: ¿alguien más lo considera un "olor a código" cuando un espacio de nombres tiene muchas clases, incluso si las clases se relacionan entre sí? ¿Te esforzarías mucho por encontrar matices en las clases que permitan la subcategorización?


8
Si las clases pertenecen a dicho espacio de nombres no. El diseño es subjetivo por su propia naturaleza, por lo que es difícil de decir realmente y es más una cuestión de preferencia como ya lo ha identificado.
Chris

Whatecer StyleCop dice que es la ley. Apuesto a que no le gustará.
Trabajo

2
Definir "bastantes". 10? 100? 1000?
Eric King

Respuestas:


7

No necesariamente. Si todas las clases pertenecen a la categoría definida por el espacio de nombres, entonces está bien.

Lo que puede hacer es mirar las clases y reflexionar sobre la posibilidad de fusionar algunas de ellas. Bien podría ser que pequeños grupos de esas clases admitan la funcionalidad "familiar" pero se implementaron por separado por algunas razones históricas. Ahora, cuando ha transcurrido el tiempo suficiente, podría ser posible una mejor composición.


6

Debe evitar tener demasiados espacios de nombres, ya que esto hace que una biblioteca sea mucho más difícil de usar y navegar para el programador. Además, con muchos espacios de nombres, puede convertirse en un desafío para el diseñador proporcionar nombres precisos para cada espacio de nombres y también decidir en qué espacio de nombres debe pertenecer una clase en particular.

La forma más sencilla de avanzar es colocar todas las clases primarias en un solo espacio de nombres, colocando cualquier clase de escenario avanzado en subespacios de nombres; .NET Framework hace esto todo el tiempo, vea System.Collectionsy System.Collections.Specializedpara obtener buenos ejemplos de esta práctica.

Con solo uno o dos espacios de nombres de primer nivel, su código será mucho más fácil de navegar, con sus clases avanzadas o especializadas ocultas hasta que el programador esté listo para descubrirlas.


3

Siempre y cuando se unan y se relacionen entre sí, no hay problema en tener demasiadas clases en un espacio de nombres.

Si una clase pertenece o no en su propio espacio de nombres separado es una cuestión de preferencia personal.

¿Qué aspecto más natural?

Parsers.XML.XmlParser.cs
Parsers.XmlParser.cs

Depende completamente de cómo le guste ver e invocar su código.

Personalmente, prefiero espacios de nombres separados solo cuando sé que habrá más de una clase perteneciente a él.


0

Esto esta bien. La razón principal para tener espacios de nombres es evitar las colisiones de nombres y solo después de esto debemos pensar en el alcance lógico, que es más una cuestión de elección personal que de regla. Por supuesto, algunas reglas sensatas son bienvenidas. Nadie quiere desplazarse a través de 3k ~ 4k clases en un espacio de nombres.

Un buen ejemplo es el espacio de nombres estándar en la Biblioteca estándar de C ++ que le permite separar sus propios algoritmos de los estándares.


-1. La colisión de nombres es importante, pero la agrupación conceptual de clases también es importante.
umlcat
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.