C# 命名空间和类同名？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18731415/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Namespace and class with the same name?
提问by user430788
I'm organizing a library project and I have a central manager class named Scenegraphand a whole bunch of other classes that live in the Scenegraph namespace.
我正在组织一个库项目，我有一个名为的中央管理器类Scenegraph和一大堆位于 Scenegraph 命名空间中的其他类。
What I'd really like is for the scenegraph to be MyLib.Scenegraphand the other classes to be MyLib.Scenegraph.*, but it seems the only way to do that would be to make all the other classes inner classes of Scenegraphin the Scenegraph.cs file and that's just too unwieldy.
我真正想要的是场景图MyLib.Scenegraph和其他类MyLib.Scenegraph.*，但似乎唯一的方法是Scenegraph在 Scenegraph.cs 文件中创建所有其他类的内部类，这太笨拙了.
Instead, I've organized it as Mylib.Scenegraph.Scenegraphand MyLib.Scenegraph.*, which sort of works but I find Visual Studio gets confused under some conditions as to whether I am referring to the class or the namespace.
相反，我将它组织为Mylib.Scenegraph.Scenegraphand MyLib.Scenegraph.*，哪种工作方式有效，但我发现 Visual Studio 在某些情况下会混淆我是指类还是命名空间。
Is there a good way to organize this package so it's convenient for users without glomming all my code together in an unmaintainable mess?
有没有一种好方法来组织这个包，这样用户就可以方便了，而不会将我的所有代码放在一个无法维护的混乱中？
采纳答案by pinckerman
I don't recommend you to name a class like its namespace, see this.
我不建议您像命名空间一样命名类，请参阅此.
The Framework Design Guidelines say in section 3.4 “do not use the same name for a namespace and a type in that namespace”. That is:
框架设计指南在 3.4 节中说“不要对命名空间和该命名空间中的类型使用相同的名称”。那是：
namespace MyContainers.List
{
public class List { … }
}
Why is this badness? Oh, let me count the ways.
You can get yourself into situations where you think you are referring to one thing but in fact are referring to something else. Suppose you end up in this unfortunate situation: you are writing Blah.DLL and importing Foo.DLL and Bar.DLL, which, unfortunately, both have a type called Foo:
为什么这是坏事？哦，让我数一数。
您可能会陷入这样的境地：您认为自己指的是一件事，但实际上指的是另一件事。假设您最终遇到了这种不幸的情况：您正在编写 Blah.DLL 并导入 Foo.DLL 和 Bar.DLL，不幸的是，它们都有一个名为 Foo 的类型：
// Foo.DLL:
namespace Foo { public class Foo { } }
// Bar.DLL:
namespace Bar { public class Foo { } }
// Blah.DLL:
namespace Blah
{
using Foo;
using Bar;
class C { Foo foo; }
}
The compiler gives an error. “Foo” is ambiguous between Foo.Foo and Bar.Foo.Bummer. I guess I'll fix that by fully qualifying the name:
编译器给出错误。“Foo”在 Foo.Foo 和 Bar.Foo 之间有歧义。无赖。我想我会通过完全限定名称来解决这个问题：
class C { Foo.Foo foo; }
This now gives the ambiguity error “Foo in Foo.Foo is ambiguous between Foo.Foo and Bar.Foo”. We still don't know what the first Foo refers to, and until we can figure that out, we don't even bother to try to figure out what the second one refers to.
这现在给出了歧义错误“ Foo in Foo.Foo is ambiguous between Foo.Foo and Bar.Foo”。我们仍然不知道第一个 Foo 指的是什么，在我们弄清楚之前，我们甚至不会费心去弄清楚第二个指的是什么。
回答by m-y
CA1724: Type Names Should Not Match Namespaces...
CA1724: Type Names Should Not Match Namespaces...
Basically, if you follow Code Analysis for proper coding this rule says to not do what you are trying to do. Code Analysis is very usefulin helping you find potentialissues.
基本上，如果您遵循代码分析进行正确编码，则此规则表示不要做您想做的事情。代码分析对于帮助您发现潜在问题非常有用。
回答by Ant_222
I would suggest that you follow the advice I got on microsoft.public.dotnet.languages.csharpto use MyLib.ScenegraphUtil.Scenegraphand MyLib.ScenegraphUtil.*.
我建议您遵循我microsoft.public.dotnet.languages.csharp使用MyLib.ScenegraphUtil.Scenegraph和的建议MyLib.ScenegraphUtil.*。
回答by Steve
Just Adding my 2 cents:
只需添加我的 2 美分：
I had the following class:
我有以下课程：
namespace Foo {
public struct Bar {
}
public class Foo {
//no method or member named "Bar"
}
}
The client was written like this:
客户端是这样写的：
using Foo;
public class Blah {
public void GetFoo( out Foo.Bar[] barArray ) {
}
}
Forgiving the error GetFoo not returning the output instead of using the out parameter, the compiler could not resolve the data type Foo.Bar[] . It was returning the error: could not find type or namespace Foo.Bar .
原谅错误 GetFoo 不返回输出而不是使用 out 参数，编译器无法解析数据类型 Foo.Bar[] 。它返回错误：找不到类型或命名空间 Foo.Bar 。
It appears that when it tries to compile it resolved Foo as the class and did not find an embedded class Bar in the class Foo. It also could not find a namespace called Foo.Bar . It failed to look for a class Bar in the namespace Foo. The dots in a name space are NOT syntactic. The whole string is a token, not the words delimited by the dots.
似乎当它尝试编译时将 Foo 解析为类，并且在类 Foo 中没有找到嵌入的类 Bar。它也找不到名为 Foo.Bar 的命名空间。它未能在命名空间 Foo 中查找类 Bar。名称空间中的点不是句法上的。整个字符串是一个标记，而不是由点分隔的单词。
This behaviour was exhibited by VS 2015 running .Net 4.6
运行 .Net 4.6 的 VS 2015 表现出这种行为
回答by GoTo
Giving the same name to the namespace and the class can confuse the compiler as others have said.
为命名空间和类提供相同的名称可能会像其他人所说的那样混淆编译器。
How to name it then?
那怎么命名呢？
If the namespace has multiple classes then find a name that defines all those classes.
如果命名空间有多个类，则找到定义所有这些类的名称。
If the namespace has just one class(and hence the temptation to give it the same name) name the namespace ClassNameNS. This is how Microsoft names their namespaces at least.
如果命名空间只有一个类（因此很想给它同一个名字）命名命名空间ClassName NS。这至少是微软命名他们的命名空间的方式。
回答by Marcelo Myara
Old post, but here I go with another idea that may help someone:
旧帖子，但在这里我提出了另一个可能对某人有所帮助的想法：
"...but it seems the only way to do that would be to make all the other classes inner classes of Scenegraph in the Scenegraph.cs file and that's just too unwieldy."
“...但似乎唯一的方法是在 Scenegraph.cs 文件中使所有其他类成为 Scenegraph 的内部类，这太笨拙了。”
This is really the better implementation for a bunch of scenarios. But, I do agree that having all that code on the same .cs file is annoying (to say the least).
对于许多场景来说，这确实是更好的实现。但是，我确实同意将所有代码放在同一个 .cs 文件中很烦人（至少可以这么说）。
You could solve it by making the base class a "partial class" and then, go on creating the inner classes on their own files (just remember that they'll have to declare the base class complement and then go on with the specific inner class for that file).
您可以通过使基类成为“部分类”来解决它，然后继续在自己的文件上创建内部类（请记住，他们必须声明基类补充，然后继续使用特定的内部类对于那个文件）。
Something like...
就像是...
Scenegraph.cs:
场景图.cs：
namespace MyLib
{
public partial class Scenegraph
{
//Scenegraph specific implementations
}
}
DependentClass.cs:
依赖类.cs：
namespace MyLib
{
public partial class Scenegraph
{
public class DependentClass
{
//DependentClass specific implementations
}
}
}
I do think that this is the closer that you can get to having the clean implementation of inner classes while not having to clutter everything inside one huge and messy file.
我确实认为这更接近于拥有内部类的干净实现，而不必将所有内容都放在一个庞大而凌乱的文件中。
回答by sonny
As others have said, it's a good practice to avoid naming a class the same as its namespace.
正如其他人所说，避免将类命名为其命名空间是一种很好的做法。
Here are some additional naming suggestionsfrom an answer by svickto a related question "Same class and namespace name" on the Software Engineering Stack Exchange:
这里有一些额外的命名建议从由svick回答一个相关问题上的软件工程堆栈交易所“相同的类和命名空间名称”：
You're right that you shouldn't name the namespace the same as a type it contains. I think there are several approaches you can use:
- Pluralize: Model.DataSources.DataSource
This works especially well if the primary purpose of the namespace is to contain types that inherit from the same base type or implement the same interface.
- Shorten: Model.QueryStorage
If a namespace contains only a small number of types, maybe you don't need that namespace at all.
- Make enterprisey: Model.ProjectSystem.Project
This can work especially for features that are important part of your product, so they deserve their own name.
您不应该将命名空间命名为与其包含的类型相同的名称，这是对的。我认为您可以使用几种方法：
- 复数：Model.DataSources.DataSource
如果命名空间的主要目的是包含从相同的基类型继承或实现相同的接口的类型，则这种方法特别有效。
- 缩短：Model.QueryStorage
如果命名空间仅包含少量类型，则您可能根本不需要该命名空间。
- 使企业化：Model.ProjectSystem.Project
这尤其适用于作为产品重要组成部分的功能，因此它们值得拥有自己的名字。
(Note that the above answer uses Model.DataSource.DataSource, Model.QueryStorage.QueryStorage., and Model.Project.Projectas examples rather than MyLib.Scenegraph.Scenegraph.)
（注意的是，上述答案的用途Model.DataSource.DataSource，Model.QueryStorage.QueryStorage.和Model.Project.Project作为例子，而不是MyLib.Scenegraph.Scenegraph。）
(I also found the other naming suggestions in the other answers here helpful.)
（我还发现此处其他答案中的其他命名建议很有帮助。）
回答by Paul Sumpner
It happens when it's the main class of the namespace. So it's one motivation to put the namespace in a library, then the issue goes away if you add 'Lib' to the namespace name...
当它是命名空间的主类时会发生这种情况。因此，将命名空间放在库中是一种动机，如果将“Lib”添加到命名空间名称中，问题就会消失......
namespace SocketLib
{
class Socket
{
回答by Jonathan Alfaro
Even though I agree with other answers in that you should not name your class the same as your namespacethere are times in which you cannot comply with such requirements.
尽管我同意其他答案，因为您不应将类命名为与命名空间相同的名称，但有时您无法遵守此类要求。
In my case for example I was not the person making such a decision therefore I needed to find a way to make it work.
例如，在我的情况下，我不是做出这样决定的人，因此我需要找到一种方法来让它发挥作用。
So for those who cannot change namespace name nor class name here is a way in which you can make your code work.
因此，对于那些无法更改命名空间名称或类名称的人来说，这里是一种让您的代码工作的方法。
// Foo.DLL:
namespace Foo { public class Foo { } }
// Bar.DLL:
namespace Bar { public class Foo { } }
// Blah.DLL:
namespace Blah
{
using FooNSAlias = Foo;//alias
using BarNSAlias = Bar;//alias
class C { FooNSAlias.Foo foo; }//use alias to fully qualify class name
}
Basically I created namespace "aliases" and that allowed me to fully qualify the class and the Visual Studio "confusion" went away.
基本上我创建了命名空间“别名”，这使我能够完全限定类，并且 Visual Studio 的“混淆”消失了。
NOTE:You should avoid this naming conflict if it in your control to do so. You should only use the mentioned technique when you are not in control of the classes and namespaces in question.
注意：如果在您的控制范围内，您应该避免这种命名冲突。仅当您无法控制相关类和命名空间时，才应使用上述技术。
