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

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

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

namespaces organization

11.01.2009 01:52

В PHP

В большой кодовой базе с множеством различных компонентов классы, функции и константы могут иметь одинаковые имена. Это может привести к путанице и...

978

Перейти к ответу Данный вопрос помечен как решенный

Ответы 5

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

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

«Обычно считается дурным тоном» - кем? Это кажется весьма спорным и отнюдь не общим. Я никогда об этом не слышал.

— 11.01.2009 02:23

Это то, на что FxCop всегда жалуется - это почти все, что мне нужно, чтобы поддержать меня :)

— 11.01.2009 02:40

Хотя Microsoft не является универсальным, особенно в очень общей области пространств имен; почти все языки программирования не принадлежат Microsoft; Кроме того, IMHO, количество классов внутри пространства имен - это не то, что должно оправдывать его существование, но есть другие причины

— 20.06.2011 11:33

11.01.2009 02:04

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

11.01.2009 02:07

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

11.01.2009 02:15

Ответ принят как подходящий

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

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

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

Хороший ответ. Еще одна вещь, о которой следует помнить, - это то, что №4 может быть проблематичным, если вы работаете с существующей библиотекой, поэтому убедитесь, что вы сделали все правильно с первого раза, если у вас есть возможность. ;)

— 11.01.2009 03:00

11.01.2009 02:21

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

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

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

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

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

11.01.2009 02:28