Как вы используете пространства имен?

Question

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

Ну, это и есть намерение, я думаю. Я думаю, что многие люди не используют его так, как его следует использовать ... Каждый день я вижу 95 пространств имен длиной в длину, разбрасывающих код и скрывающих действительно важную информацию.

Вот пример:

BigCorp.FrontOffice.MyApp.MySubDomain.Controllers.MyControllerXYZ xyzController = new 
    BigCorp.FrontOffice.MyApp.MySubDomain.Controllers.MyControllerXYZ( 
        BigCorp.FrontOffice.MyApp.MySubDomain.Const.MyValue1,
        BigCorp.FrontOffice.MyApp.MySubDomain.Const.MyValue2 );

У тебя здесь было намерение? Нет конечно. Было:

MyControllerXYZ xyzController = новый MyControllerXYZ (MyValue1, MyValue2);

Довольно просто без пространств имен, но неразборчиво с ...

Ну, как вы используете пространства имен? Каковы ваши лучшие практики о них? Должны ли мы использовать пространства имен или внутренние классы? Сколько пространств имен использует ваш основной проект? (В настоящее время мой использует 210 интерфейсов (!) И гораздо больше пространств имен - не поддерживается!)

Заранее спасибо за ответы,
Sylvain.

Answer 1

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

это общий вопрос о том, как называть переменные. это декларация

int x;

Лучше всего рассматривать как простую форму подтверждения

intx;?

когда программист уже знает, что это int, пишет что-то вроде

int myint;

тавтологично. хуже, чем это, объявив переменную как

int x;

прекращает писать

double x;

в следующей строке, сохраняя их как одно слово, нет. а также это, вы должны помнить, когда вы кодируете, что x является целым числом или y является двойным. вот почему люди пишут

ByteArrayOutputStream myByteArrayOutputStream = new ByteArrayOutputStream(size);

чтобы они точно знали, что это за переменная. в итоге это очень тавтологично. если вы все равно назовете его myByteArrayOutputStream, почему грамматика языка заставляет вас явно войти в класс?

Answer 2

Предполагая, что вы говорите о пространствах имен в C #, помимо очевидного использования

using Namespace;

Вы также можете иметь псевдонимы:

using ShortCut = Really.Complicated.Namespace.Its.Just.Terrible;

Answer 3

это много вопросов в одном посте!

1) Зачем использовать пространства имен? как вы указали в вопросе, они являются AN-организационным методом для кода. на самом деле не существует «одного способа» для организации кода, поэтому обычно именуемые объекты не вызывают проблем. Создание одной библиотеки классов может использовать совершенно другой механизм, чем другая библиотека.

2) Как мне использовать пространства имен? Я предпочитаю, как Microsoft сгруппировала их пространства имен ( см. Карту пространств имен 3.5! ). Группировка по функциональности, наследованию, что угодно! Пространства имен - это просто еще один организационный инструмент для использования. При этом, я ошибаюсь на стороне меньше, больше. как вы сказали, пространства имен могут скрывать код, а также скрывать функциональный код от других разработчиков (в каком пространстве имен был тот класс gridrow, который мне был нужен? Grid или Row?). Я стараюсь использовать пространства имен только когда возникает необходимость. Называй меня неряшливым, но у меня все получилось!

Резюме: избегайте сложности. не преувеличивайте свой код.

Answer 4

У нас здесь есть люди, которые склонны делать это. Они также склонны продолжать использовать условия «использования», чтобы избавиться от промаха. Глупая часть в том, что они просто возвращаются туда, откуда они начали.

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

foo_

на передней (или задней) группе идентификаторов, вместо этого поместите их все вместе в пространство имен "foo" и вызовите их с помощью

Foo ::

Таким образом, бородавка, которую вы все равно собирались поставить там, теперь имеет некоторое синтаксическое значение. Более того, во внутреннем коде для «foo_» вам больше не нужно использовать ведущий «foo». Понятно, так как вы уже работаете с элементом в пространстве имен "foo". Это значительно облегчает чтение внутреннего кода и облегчает понимание кода клиента.

Answer 5

Это зависит от языка и широты организации и кода. Вы правы в том, что длинный список пространств имен, разбросанных по всему коду, затрудняет чтение. Но у них есть хорошая цель: организация кода. Предоставляет ли ваш язык возможность создавать псевдонимы этих доменов или просто включать имена один раз в начало файла с помощью операторов «using» или «import»? Если это так, то в теле кода вам нужны только пространства имен, в которых они конфликтуют.