Подпространства для организации плохой практики?

Question

Было бы плохой практикой использовать пространства под-имен для чисто организационных целей? Например:

namespace vehicles 
{ 
    namespace cars 
    { 
     // Stuff here 
    } 

    namespace boats 
    { 
     // More stuff here 
    } 
} 

Я могу видеть, как это будет проблемой на больших проектах, потому что это было бы неудобно набирать vehicles::cars::function много. А как же небольшие проекты?

Answer 1

Почему было бы неудобно вводить vehicles::cars::function в небольшом проекте?

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

Если вы изобретаете такую ​​сложную структуру пространства имен, что у меня возникает соблазн просто поместить несколько using namespace ... в верхнюю часть каждого файла, то это победит цель пространства имен.

Это также на самом деле не говорит мне, что я уже не знал. Что вы собираетесь вставить в пространство имен boats, которое я не знал бы из названия, было лодкой? Мне понадобится разъяснение, что «это принадлежит лодкам» на чем-либо в пространстве имен? Скорее всего, нет, и тогда нет смысла иметь пространство имен.

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

Если это не решит настоящую актуальную проблему, тогда это плохая идея, независимо от чего-либо еще.

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

.NET использует глубоко вложенные пространства имен с длинными именами. Полное имя для простого динамического массива - System.Collections.Generic.List<T>.

В результате никто не использует пространство имен. Все просто помещают using System.Collections.Generic в начало каждого файла, который должен использовать Список.

И в связи с этим у вас возникли проблемы в тот момент, когда вы столкнулись с List класс. Вы хотите сделать то же самое с этим, и вуаля, у вас есть два List классов.

C++ использует очень плоскую структуру namespcae, где пространства имен также имеют очень короткие имена.

Эквивалентный класс на C++ - это просто std::vector. В результате люди обычно печатают префикс пространства имен, поэтому, когда я добавляю в свой проект еще один векторный класс, * он работает '. Нет конфликтов имен, потому что я использую префикс std::, когда хочу ссылаться на стандартный вектор библиотеки.

Answer 2

ИМХО это не плохая практика! Также рассмотрите возможность использования псевдонимов для того, чтобы каждый раз набирать полное имя и не вводить полное пространство имен, где это необходимо ...

Answer 3

Одна из причин пространств имен - это организационные цели, насколько мелкозернистые вы делаете их по личным предпочтениям - я сохраняю их довольно общие лично, например, у меня есть TransferObjects. Транспортные средства, но не идут ни с чем мелкозернистым. Если у вас много разных типов, я не вижу смысла в этом разбираться. Но это зависит от вас.

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

Answer 4

Ну, для чего это стоит, я пытался использовать глубоко вложенные пространства имен в проекте среднего размера пару лет назад, и это был абсолютный ад - я все время писал typedefs :) В Java пакеты работайте очень хорошо, потому что вы можете просто импортировать вещи вверху каждого .java-файла и не иметь серьезных проблем. В C++ это боль в прикладе, потому что это плохая практика поместить с помощью директив/деклараций в заголовочные файлы. В результате вы получаете либо (a) полное отбор всех в заголовках (bleurgh), либо (b) используя много typedefs (также bleurgh). Не круто - мой совет будет избегать, как чумы, если вы не любите писать такие вещи, как:

centipede::autoseg::hierarchygeneration::ragbuilders::RAGBuilder<...> 

Это не типа, это предложение ...