Пространство имен Правило большого пальца - PullRequest
Новая
       15

Пространство имен Правило большого пальца

7 голосов
/ 11 января 2009

Существует ли общее практическое правило относительно того, сколько классов, интерфейсов и т. Д. Должно войти в данное пространство имен, прежде чем элементы будут в дальнейшем классифицированы в новом пространстве имен? Как лучшая практика или предпочтения сообщества? Или это все личные предпочтения? 

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

Или 

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

Ответы [ 5 ]

4 голосов
/ 11 января 2009

Я не видел никакого практического правила ни в одном надежном источнике, но есть несколько общих предпочтений, которые я видел при работе с большинством разработчиков. Есть несколько вещей, которые помогут вам создать пространства имен.

  1. Домен класса
  2. Это класс или интерфейс (я видел, что некоторые разработчики предпочитают пространства имен, такие как ShopApp.Model.Interfaces). Работает очень хорошо, если ваши интерфейсы - это какой-то сервис или контракт данных.
  3. Нет слишком глубоких пространств имен, достаточно 3 (.). Больше, чем это может раздражать.
  4. Будьте открыты для реорганизации пространства имен, если в любой момент вы чувствуете, что им стало нелогично или трудно управлять.
  5. Не создавайте пространства имен только ради него.

Счастливое кодирование !!!

3 голосов
/ 11 января 2009

При создании библиотеки или модуля, как правило, лучше использовать только одно пространство имен, поскольку основная функция пространства имен заключается в том, чтобы избежать конфликтов имен, и вы можете контролировать, какие имена присваиваются классам и интерфейсам. *

2 голосов
/ 11 января 2009

Я не знаю ни одного эмпирического правила для количества предметов, но такие правила в любом случае имеют тенденцию быть чрезмерно обобщенным мусором. Убедитесь, что между элементами в одном пространстве имен существует логическая связь. Если пространство имен становится слишком тесным (маловероятно, я надеюсь), или вещи в пространстве имен в лучшем случае слабо связаны, рассмотрите возможность разбиения его на несколько пространств имен.

1 голос
/ 11 января 2009

Я бы сказал, что иерархия пространства имен должна определяться только соображениями дизайна и иерархии модели / API.

Если в одном пространстве имен огромное количество не связанных между собой классов, переосмыслите свой дизайн.

Вопреки сказанному Эндрю, я бы не беспокоился о пространствах имен, содержащих несколько классов - хотя, конечно, верно, что иерархия должна быть настолько детализированной, насколько это необходимо для выражения замысла.

С другой стороны, я считаю совершенно разумным, чтобы пространство имен содержало только один очень специальный класс или, возможно, очень маленький набор типов, один из которых кодирует задачу, а другие предоставляют API (исключения, перечисления). за аргументы…).

В качестве примера возьмем System.Text.RegularExpressions (в .NET). Конечно, немного больше, чем один класс, но только один раз.

0 голосов
/ 11 января 2009

Обычно считается плохим иметь небольшое количество классов в пространстве имен. Я всегда объяснял это тем, что многие пространства имен приводят к путанице.

Я бы посоветовал вам разбить классы на логические пространства имен, как можно более разумно и практично. Однако, если у вас останется только один или два класса в каждом пространстве имен, возможно, вы слишком сильно разбиты и должны подумать о консолидации.

...