I'm organizing a library project and I have a central manager class named Scenegraph
and 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.Scenegraph
and 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 Scenegraph
in the Scenegraph.cs file and that's just too unwieldy.
我真正喜欢的是场景图是MyLib.Scenegraph,其他类是MyLib.Scenegraph。*,但似乎唯一的方法是将所有其他类的内部类放在Scenegraph.cs文件,这太笨重了。
Instead, I've organized it as Mylib.Scenegraph.Scenegraph
and 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.Scenegraph和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?
是否有一个很好的方法来组织这个包,这样对于用户而言,如果没有在一个难以维护的混乱中将我的所有代码拼凑在一起,这对用户来说很方便?
5 个解决方案
#1
77
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和Bar.Foo之间的“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中的Foo.Foo在Foo.Foo和Bar.Foo之间是不明确的”。我们仍然不知道第一个Foo指的是什么,直到我们能够弄明白,我们甚至懒得试图弄清楚第二个指的是什么。
#2
5
I would suggest that you follow the advice I got on microsoft.public.dotnet.languages.csharp
to use MyLib.ScenegraphUtil.Scenegraph
and MyLib.ScenegraphUtil.*
.
我建议你按照我在microsoft.public.dotnet.languages.csharp上的建议来使用MyLib.ScenegraphUtil.Scenegraph和MyLib.ScenegraphUtil。*。
#3
3
CA1724: Type Names Should Not Match Namespaces
...
CA1724:类型名称不应与命名空间匹配...
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 useful in helping you find potential issues.
基本上,如果您按照代码分析进行正确编码,则此规则表示不执行您要执行的操作。代码分析在帮助您找到潜在问题方面非常有用。
#4
3
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.
如果命名空间只有一个类(因此诱使它赋予它相同的名称),则命名空间ClassNameNS。这就是Microsoft至少命名其命名空间的方式。
#5
2
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
VS 2015运行.Net 4.6展示了这种行为
#1
77
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和Bar.Foo之间的“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中的Foo.Foo在Foo.Foo和Bar.Foo之间是不明确的”。我们仍然不知道第一个Foo指的是什么,直到我们能够弄明白,我们甚至懒得试图弄清楚第二个指的是什么。
#2
5
I would suggest that you follow the advice I got on microsoft.public.dotnet.languages.csharp
to use MyLib.ScenegraphUtil.Scenegraph
and MyLib.ScenegraphUtil.*
.
我建议你按照我在microsoft.public.dotnet.languages.csharp上的建议来使用MyLib.ScenegraphUtil.Scenegraph和MyLib.ScenegraphUtil。*。
#3
3
CA1724: Type Names Should Not Match Namespaces
...
CA1724:类型名称不应与命名空间匹配...
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 useful in helping you find potential issues.
基本上,如果您按照代码分析进行正确编码,则此规则表示不执行您要执行的操作。代码分析在帮助您找到潜在问题方面非常有用。
#4
3
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.
如果命名空间只有一个类(因此诱使它赋予它相同的名称),则命名空间ClassNameNS。这就是Microsoft至少命名其命名空间的方式。
#5
2
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
VS 2015运行.Net 4.6展示了这种行为