.net - 如何说服怀疑的同事了解.Net中的正确 namespace ？

Question

我的团队正在研究一个转换项目，以将一种产品(但具有很多方面)从VB6转换为.Net(我们的LOC超过30万)。在我上任之前，已做出决定，无论程序集或文件夹结构的位置如何，所有类/结构都将位于一个命名空间中:

。

他们甚至可以更改自动生成的应用程序设置设计器代码，资源设计器代码等，以提高一致性。我如何说服他们使用命名空间是好的？命名空间的正确用法是什么，优缺点是什么？我想我很难理解我的同事们为什么会经历这么麻烦，以节省一些使用线路。任何支持您的论点的外部信誉良好的引用文献将不胜感激。请帮忙!

Answer 1

很好的答案，已经

我读了很多很好的答案(例如，驱动器文件夹的图像很不错，对象/概念的分离/组织也很不错)。

但是，还有一些其他的，“技术性”较弱的论点可能会有所帮助，而不是解释为什么 namespace 比替代名称更好，而是找出不使用 namespace 的不良原因。

Argument by Authority

每个C#，VB.NET，Java，C++，无论在这个星球上值得付出什么代价的开发人员，都承认 namespace /包是一件好事。嘿they are even considering it in Mozilla's JavaScript。

我想您对Stack Overflow的疑问具有“权威性争论”的含义...
^ _ ^

旧习难改

我相信您会陷入“旧习惯”。

虽然我没有直接的经验来了解VB.NET反对VB6的旧习惯，但是我还是针对C++来对抗像C一样精简的C++。

一半的工作...

在处理传统习惯时，一半的工作是发现他们已经在使用 namespace ，而没有对其进行确认。

例如(对于C++开发人员来说，与“老式”，类似C的代码碰撞最正确，但我猜它在任何地方都是可行的)，他们是否使用前缀作为符号。

他们有没有:

帐户用户

帐户价格

AccountId

LoginUser

登录密码

类/符号，并说明Account的“User”与登录名的“User”不同，因此，要区分它们的前缀是什么？

当它们通过模块为符号添加前缀时，“模式”会直通天花板(如果足够大的话，代码肯定是这种情况):

您是否有MyUtil DLL，MyKernel DLL和MyGui DLL？
因此，您是否有:

MyUtil_Something

MyUtil_Something其他

MyKernel_YetAnotherObject

MyKernel_AnotherThing

MyGui_SomeGui

类/符号？

如果是，那么他们应该确认他们已经在使用命名空间。

如果不是，那么您的代码库太小(但是您的“9个项目”告诉我不是)，或者它们经常是名称冲突的问题……可以通过上述前缀解决，或者甚至可以通过以下方式解决:命名空间。

另一半...

另一半的工作是让他们解释为什么它们的“命名空间”比该语言内置的命名空间更好(这是您应该避免因致命的暴露性大脑死因推理而沮丧地撞到墙上的那一刻) 。

同样，您可以使用“按授权进行争论”(什么？您相信比Microsoft的Top Gun工程师更了解吗？)，但是在这种情况下，您应该提供示例说明.NET(或任何其他方式)命名空间为何优于他们使用(或不使用)的那个。

对于VB.NET/.NET，已经有足够多的好参数了，我不会在C++ namespace 的后面继续讨论，因为这将超出主题范围。

但是至少，使用内置 namespace 会使上述前缀成为可选的。从互联网引用一个示例(我对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

比启用的 namespace 更为冗长:

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上使用更多 namespace ，例如: http://www.vbdotnetheaven.com/UploadFile/ggaganesh/NamespacesInVbDotNet04202005005133AM/NamespacesInVbDotNet.aspx

与项目/职业相关的原因

这些原因更多地与项目/职业管理有关。

维护不是可选的

如果您的应用程序是一头濒临灭绝的老牛，那么更改标签或组合内容值得2天的工作时间(确实发生了)，那么可能就没有多余的重构工作了。另一方面，如果重构是自动化的，那么无论如何您都应该这样做。

但是，如果应该在将来使用您的应用程序，那么破坏它以使其保留在过去是个坏主意。您有一天会为此付费。避免维护本来可以赢得的每个小时，将在不可避免的那一天支付两倍或十倍的报酬(您知道，由于紧急情况，您将没有时间做适当的事情……)

保持最新状态不是可选的

这种观点适用于有职业并且必须保留其工作的工程师:与应用程序一样，软件工程师可能会过时。

这意味着过时的开发人员在申请其他工作时也会失去工作。因为，嘿，谁愿意为某人付钱，而他们却没有得到像 namespace 那么简单的东西？

经验与当前的最新知识相结合是一件好事。如果不是的话，那只是恐龙时代的愤世嫉俗而无聊的争论，“在我那个时代，当我们不需要像物体那样的所有小玩意儿时，情况会更好(阅读:更简单)”。

保持最新状态不是可选的(经理方面)

通过拒绝适应该语言的新功能(通常是因为“我们知道得更好，您知道吗？”)，工程师只是穿着混凝土鞋，而竞争对手则可能穿着跑鞋。这意味着过时的团队产生的应用程序最终将丢失。时期。

团队将以类似的方式雇用新的工程师，他们可能了解这些功能，并且会感到惊讶，然后对他们像几十年前的祖母一样编程的事实感到沮丧。过时的团队不会让新工程师任职很久(至少，值得他们付钱的工程师)。

请注意，使用过时的产品会使高层管理人员更容易地决定从头开始重写它会变得更容易...以及可能在其他地方，薪水较低的工程师和经理...