Эмпирическое правило пространства имен

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

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
7
задан leonheess 10 July 2019 в 15:38
поделиться

5 ответов

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

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

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

4
ответ дан 7 December 2019 в 01:28
поделиться

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

3
ответ дан 7 December 2019 в 01:28
поделиться

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

2
ответ дан 7 December 2019 в 01:28
поделиться

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

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

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

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

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

1
ответ дан 7 December 2019 в 01:28
поделиться

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

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

0
ответ дан 7 December 2019 в 01:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: