Хороших ответов, уже
Я прочитал много хороших ответов (например, образ папки на диске - хороший, как и разделение / организация объектов / концепций).
Тем не менее, некоторые другие, менее «технические» аргументы могут помочь не для объяснения того, почему пространства имен лучше альтернативы, а для выявления дурных причин, пространства имен не используются.
Каждый C #, VB.NET, Java, C ++, любой разработчик, достойный своей соли на этой планете, признает, что пространства / пакеты имен - это хорошая вещь. Эй, они даже рассматривают это в JavaScript Mozilla .
Я полагаю, что ваш вопрос о переполнении стека имеет отношение к "Аргументу авторитета" ...
^ _ ^
Старые привычки умирают усердно
Я полагаю, что вы попали в случай "старых привычек".
Хотя у меня нет прямого опыта использования VB.NET против старых привычек VB6, я делаю это для C ++ против урезанного C-like, C ++.
Половина работы ...
При работе с унаследованными привычками половина работы обнаруживает, что они уже используют пространства имен, не признавая этого.
Например (это наиболее верно для разработчиков C ++, сталкивающихся со "старым способом", кодом, подобным C, но, я думаю, это жизнеспособно везде), используют ли они префиксы для своих символов.
Есть ли у них:
- Счет Пользователь
- Счет Цена
- Счет Id
- Логин Пользователь
- Логин Пароль
классов / символов и объясните, что «Пользователь» Учетной записи не совпадает с «Пользователем» при входе в систему, и, следовательно, префикс для их дифференциации?
«Шаблон» идет прямо сквозь потолок, когда они префиксируют свои символы модулем (что, безусловно, относится к вашему коду, если он достаточно большой):
У вас есть MyUtil DLL, а также MyKernel DLL и MyGui DLL?
Таким образом, у вас есть:
- MyUtil_ Что-то
- MyUtil_ SomethingElse
- MyKernel_ YetAnotherObject
- MyKernel_ AnotherThing
- MyGui_ SomeGui
классы / символы
Если да, то они должны подтвердить, что они уже используют пространства имен.
Если нет, то либо ваша кодовая база слишком мала (но ваши «9 проектов» говорят мне, что это не так), либо они регулярно являются проблемами конфликта имен ... Что может быть решено либо с помощью префикса, описанного выше, либо даже лучше по пространствам имен.
Другая половина ...
Другая половина работы заставляет их объяснять, почему их «пространства имен» лучше, чем встроенные в язык (, это тот момент, когда вам не следует биться головой о стены в отчаянии, потому что о смертельном воздействии умственной отсталости ).
Опять же, вы можете использовать аргумент от власти ( Что? Вы уверены, что знаете лучше, чем инженеры Top Gun из 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 ... Но тогда это приведет к более неясному коду и т. Д. И т. Д.
Googling может найти более широкое использование пространств имен в .NET, например: http://www.vbdotnetheaven.com/UploadFile/ggaganesh/NamespacesInVbDotNet04202005005133AM/NamespacesInVbDotNet.aspx
Проект / Карьера
Эти причины больше связаны с управлением проектами / карьерой ...
Техническое обслуживание не является обязательным
Если ваше приложение - старая умирающая корова, где смена метки или содержимого комбо стоит 2 дня работы (это действительно происходит), тогда, возможно, нет никакого смысла в дополнительной работа рефакторинга. С другой стороны, если рефакторинг автоматизирован, то вы все равно должны это сделать.
Но если ваше приложение предполагается использовать в будущем, саботировать его, чтобы оставить в прошлом, - плохая идея. Вы заплатите за это, когда-нибудь. Каждый час, который должен быть выигран за счет отказа от обслуживания, будет оплачен дважды или в десять раз в день, когда это станет неизбежным (вы знаете, день, когда у вас не будет времени сделать это должным образом, потому что это срочно ...)
Поддерживать себя в курсе не является обязательным
Этот аргумент предназначен для инженеров, которые имеют карьеру и должны продолжать свою работу: как и приложения, инженеры-программисты могут устареть.
А это значит, что устаревший разработчик при подаче заявки на другую работу тоже проиграет. Потому что, эй, кто хочет платить за того, кто просто не может получить что-то такое простое, как пространства имен?
Опыт - это хорошая вещь, когда он сочетается со знанием современного уровня техники. Если нет, то это всего лишь динозавр, старый циничный и бесполезный бродячий о " как это было лучше (читай: проще) , в мое время, когда нам не нужны были все эти штуковины, подобные объектам ».
Поддерживать себя в курсе не является обязательным (со стороны менеджера)
Отказываясь адаптироваться к новым возможностям языка (обычно потому, что « мы знаем лучше, вы знаете? »), инженеры просто надевают бетонные ботинки, в то время как конкуренты, вероятно, ставят кроссовки. Это означает, что приложение, созданное устаревшей командой, в конечном итоге потеряет. Период.
Аналогичным образом, команда наймет новых инженеров, которые, вероятно, знают о функциях и которые удивятся, а затем расстроятся из-за того, что они просто программируют, как это делали их бабушки десятилетия назад. Устаревшая команда не будет долго держать новых инженеров (по крайней мере, тех, кто стоит их платить).
Обратите внимание, что работа с устаревшим продуктом позволяет менеджерам высшего уровня решить, что будет проще переписать его с нуля ... И, возможно, где-то еще, с менее оплачиваемыми инженерами и менеджерами ...