Хорошие ответы, уже

Я прочитал много хороших ответов (изображение папки диска является хорошим, например, как разделение/организация объекта/понятия).

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

Аргумент полномочиями

Каждый C#, VB.NET, Java, C++, безотносительно достойного разработчика на этой планете подтверждают, что пространства имен/пакеты являются хорошей вещью. Эй, они даже рассматривают это в JavaScript Mozilla.

Я предполагаю, что Ваш вопрос на Переполнении стека имеет касание "Аргумента авторизации"... ^_^

Привычка - вторая натура

Я полагаю, что Вы падаете в случае "Старых привычек".

В то время как у меня нет прямого опыта о VB.NET против старых привычек VB6, я делаю для C++ против упрощенного подобного C, C++.

Половина работы...

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

Например (это является самым верным для C++ devs сталкивающийся со "старомодным", подобным C кодом, но это жизнеспособно везде, я предполагаю), сделайте они используют префиксы для своих символов.

Сделайте они имеют:

• AccountUser
• AccountPrice
• AccountId
• LoginUser
• LoginPassword

классы/символы, и объясняют, что "Пользователь" Учетной записи не является тем же, чем "Пользователь" входа в систему, и таким образом, префикс для дифференциации их?

"Шаблон" идет прямо через потолок, когда они снабжают префиксом свои символы модулем (который, конечно, имеет место для Вашего кода, если это является достаточно большим):

У Вас есть MyUtil DLL, а также MyKernel DLL и MyGui DLL? Таким образом сделайте Вы имеете:

• MyUtil_Something
• MyUtil_SomethingElse
• MyKernel_YetAnotherObject
• MyKernel_AnotherThing
• MyGui_SomeGui

классы/символы?

Если да, то они должны подтвердить, что уже используют пространства имен.

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

Другая половина...

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

Снова, можно ли использовать Аргумент вещью полномочий (Что? Вы действительно верите, знают лучше, чем инженеры Лучшего стрелка от Microsoft?), но в этом случае, необходимо дать примеры того, почему.NET (или безотносительно) пространства имен лучше, чем то, которое они используют (или не используйте).

Для VB.NET/.NET, там уже более чем достаточно хороших аргументов, и я не пойду на тех позади пространств имен C++, потому что это было бы вне темы.

Но по крайней мере, использование встроенных пространств имен делает префикс упомянутым выше дополнительный. Заключение в кавычки примера из Интернета (я не очень хорошо осведомлен относительно VB.NET):

Imports MyWholeProject

Class HelloWorld

   Public Sub Main()
      Dim o As MyModuleAAA_MyObject = New MyModuleAAA_MyObject
      Dim t As MyModuleBBB_MyThing = New MyModuleBBB_MyThing
      Dim g As MyModuleCCC_MyGizmo = New MyModuleCCC_MyGizmo
      REM etc.
   End Sub

End Class

Является вполне более подробным, чем пространство имен включило:

Imports MyWholeProject.MyModuleAAA
Imports MyWholeProject.MyModuleBBB
Imports MyWholeProject.MyModuleCCC

Class HelloWorld

   Public Sub Main()
      Dim o As MyObject = New MyObject
      Dim t As MyThing = New MyThing
      Dim g As MyGizmo = New MyGizmo
      REM etc.
   End Sub

End Class

И многословие приводит к более неясному коду и таким образом ошибкам. Конечно, Вы могли заменить MyModuleAAA чем-то менее длинным, как MMAAA... Но затем, это приводит к более неясному коду и т.д. и т.д.

Больше использования пространств имен на.NET может быть найдено путем поиска с помощью Google, как: http://www.vbdotnetheaven.com/UploadFile/ggaganesh/NamespacesInVbDotNet04202005005133AM/NamespacesInVbDotNet.aspx

Связанные с проектом/карьерой причины

Теми причинами является больше relatived для проектирования/мчаний управления...

Обслуживание не является дополнительным

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

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

Держание в курсе себя не является дополнительным

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

И это означает, что устаревший разработчик, при применении к другому заданию, проиграет, также. Поскольку, эй, кто хочет заплатить за кого-то, кто просто не получает что-то столь же простое как пространства имен?

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

Держание в курсе себя не является дополнительным (сторона менеджера)

Отказываясь адаптироваться к новым возможностям языка (обычно, потому что "мы знаем лучше, Вы знаете?"), инженеры просто обуваются, в то время как конкуренция, вероятно, помещает кроссовки. Это означает, что приложение, произведенное устаревшей командой, в конечном счете проиграет. Период.

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

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