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

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

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

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

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

Answer 3

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

Answer 4

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

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