这是常识(和约定),其命名空间用来唯一标识代码,避免名称冲突,这就是为什么你应该始终把自己的代码中唯一的命名空间成为可能.
但是,......
命名空间还用于将逻辑相关的类组合在一起.我的个人库只是在Framework类库(FCL)上扩展,并实现了我在FCL中找不到的所有功能.它主要包含扩展和辅助类,以及其他高度可重用的类.我发现遵循与FCL中相同的命名空间结构非常有用.
我更进了一步,并开始使用FCL的命名空间将我的代码"注入"我真正期望它们的命名空间.
一个优点是您不必定义尽可能多的使用.例如,通过简单地引用库,可以立即使用扩展方法,而无需添加额外的使用.作为一个很好的例子(对于那些喜欢保持其使用列表清洁的人),您经常希望扩展方法有效,只是意识到您没有添加"使用System.Linq;" 然而？
更新:
所以我相信的主要优势(如评论中所述)是您可以更轻松地访问更多实用程序,而无需查找特定的命名空间.例如,如果您正在使用System.Collections.Generic,可立即使用扩展方法IList<T>.
我认为这种优势实际上可以超过劣势.我不会为将来可能发生名称冲突而烦恼,因为这表明FCL的新版本实际上包含了我想要的类似内容.它实际上更容易注意到FCL中的更改,无论如何我想在我的命名空间中反映出来.
当然,我知道如果每个人都开始为公共图书馆做这件事,那将会出现根本错误,但对于我个人的项目,我觉得它真的很有用.
我忽略了其他任何缺点吗？我已经考虑过如果我想让库公开,我需要找到一种方法来允许使用System命名空间,或者根据用户的需要使用不同的命名空间.我知道在.NET环境中执行此操作的唯一方法是使用预定义.
更新2:
所以,就像我说的那样,我确实意识到有些人可能会发现它不方便,并且需要一个不同的命名空间.对于我自己的项目,我觉得不方便做到如下:
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media
using System.Windows.Media.Media3D;
using MyNamespace.Windows;
using MyNamespace.Windows.Controls;
using MyNamespace.Windows.Media;
using MyNamespace.Windows.Media.Media3D;
更不用说这个问题,例如using MyNamespace.System.Windows;不可能.
要想出一个有希望产生更有用答案的问题:
有没有一种解决方案可以比将代码放在System命名空间中更好地解决这个问题？除了使用预定义之外,还有一种方法可以在需要时轻松编译到不同的命名空间,或者这是一个坏主意吗？
忽略命名冲突,因为你已经链接到...
这有一个主要优点,您无需定义任意数量的使用.
我实际上认为这是一个缺点.强制您添加using语句或完全限定类型使您的代码更易于维护,因为它使得在定义特定代码的位置更加明显.
虽然在System.***命名空间中查看实用程序可能没什么问题,但大多数开发人员都希望定义的类型System.***.SomeType是基类库的一部分.在我看来,用你自己的类型"扩展"基础库会引起混淆,并导致可维护性降低.