命名空间非常酷:有了它们,你可以组织你的库,你可以避免名称冲突。
嗯,我想是这个意图。我认为很多人不会像使用它那样使用它...每天,我看到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 = new MyControllerXYZ(MyValue1,MyValue2);
非常简单,没有命名空间,但却无法理解......
那么,你如何使用命名空间?你对他们的最佳做法是什么?我们应该使用命名空间还是内部类?您的主项目使用了多少个名称空间? (目前,我的使用210接口(!)和更多名称空间 - 不可维护!)
提前,谢谢你的回答,
西尔。
答案 0 :(得分:2)
假设您正在讨论C#中的命名空间,除了
的明显用法using Namespace;
你也可以有别名:
using ShortCut = Really.Complicated.Namespace.Its.Just.Terrible;
答案 1 :(得分:2)
在一个问题帖子中提出了很多问题!
1)为什么要使用命名空间? 正如你在问题中所说,它们是代码的一种组织方法。确实没有“单向”方法来编写代码,因此通常命名的对象不会导致问题。创建一个类库可能会使用与另一个库完全不同的机械。
2)我应该如何使用命名空间? 我更喜欢Microsoft如何对其命名空间进行分组(see 3.5 name space map!)。按功能分组,继承,无论如何!名称空间只是另一种使用的组织工具。话虽如此,我错误的是更少。如你所说,命名空间可以隐藏代码,以及隐藏其他开发人员的功能代码(哪个命名空间具有我需要的gridrow类?Grid或Row?)。我尝试只在需要时才使用名称空间。叫我马虎,但到目前为止它对我有用了!
总结:避免复杂性。不要对你的代码进行过度分类。
答案 2 :(得分:2)
从理论上考虑这个问题(我自己很少使用名称空间),我不确定名称空间有多少帮助。为了保持代码的可读性,您将尝试为函数和变量选择明确的名称。除此之外,大多数语言都支持范围设置,以某种方式限制函数或变量的可见性。函数本身在大多数语言中为变量提供了一个自然的命名空间。
这是关于如何命名变量的一般问题。是宣言
int x;
最好被视为一种易于验证的
形式 intx;
?
当程序员已经知道它是一个int时,写一些类似
的东西 int myint;
是同义反复的。比这更糟糕的是,将变量声明为
int x;
停止写作
double x;
在下一行中,同时将它们保持为一个单词不会。除此之外,您必须记住编码时x是int还是y是double。这就是人们写的原因
ByteArrayOutputStream myByteArrayOutputStream = new ByteArrayOutputStream(size);
,
这样他们就可以准确地知道变量是什么。这最终是非常重复的。如果您打算将其称为myByteArrayOutputStream,为什么语言的语法会强制您明确地进入类?
答案 3 :(得分:1)
这取决于组织和代码的语言和广度。你是对的,因为在代码中散布了一长串命名空间,这使得它更难阅读。但他们确实有一个很好的目的:代码组织。您的语言是否能够通过“使用”或“导入”语句为这些域添加别名,或者只是在文件开头包含一次名称?如果是这种情况,那么在代码体中,您只需要与它们发生冲突的命名空间。
答案 4 :(得分:1)
我们这里的民众往往会这样做。他们也倾向于使用“使用”条款来摆脱残余。愚蠢的部分就是将它们放回原处。
一般来说,我喜欢看的是一个,在极少数情况下是两个级别的命名空间。你应该做的是:每当你想要坚持
FOO _
在一堆标识符的前面(或后面),而不是将它们全部放在命名空间“foo”中并用
调用它们FOO ::
那样你现在要放在那里的疣现在有一些语法上的意义。更好的是,在“foo_”内容的内部代码中,你不再需要使用领先的“foo”。据了解,因为您已经在“foo”命名空间中处理项目。这使内部代码更容易阅读,客户端代码更容易理解。