Полезное правило пространства имен

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

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

Удачного кодирования !!!

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

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

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

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

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

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

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

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

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