이름이 같은 네임 스페이스와 클래스?

이름이 같은 네임 스페이스와 클래스?

---

저는 도서관 프로젝트를 구성하고 있으며 중앙 관리자 클래스라는 이름 Scenegraph과 Scenegraph 네임 스페이스에있는 다른 클래스가 있습니다.

내가 정말로 원하는 것은 장면 그래프가 MyLib.Scenegraph되고 다른 클래스가되는 것입니다 MyLib.Scenegraph.*.하지만 그렇게하는 유일한 방법은 다른 모든 클래스를 ScenegraphScenegraph.cs 파일 의 내부 클래스로 만드는 것입니다. 너무 다루기 어렵습니다. .

대신, 나는 그것을 Mylib.Scenegraph.Scenegraphand 로 구성했는데 MyLib.Scenegraph.*, 어떤 종류의 작동하지만 Visual Studio는 내가 클래스를 참조하는지 네임 스페이스를 참조하는지에 대해 일부 조건에서 혼란스러워집니다.

이 패키지를 구성하는 좋은 방법이있어 유지 관리 할 수없는 엉망으로 내 모든 코드를한데 모으지 않고 사용자가 편리하게 사용할 수 있습니까?

---

나는 그것의 네임 스페이스와 같은 참조 클래스 이름을 권장하지 않습니다 이 .

프레임 워크 디자인 지침은 섹션 3.4 "네임 스페이스와 해당 네임 스페이스의 유형에 동일한 이름을 사용하지 마십시오"에 설명되어 있습니다. 그건:

namespace MyContainers.List 
{ 
    public class List { … } 
}

왜 이것이 나쁜가요? 오, 방법을 세어 보겠습니다.

한 가지를 언급하고 있다고 생각하지만 실제로는 다른 것을 언급하는 상황에 처할 수 있습니다. 이 불행한 상황에 처했다고 가정 해 보겠습니다. 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; } 
}

컴파일러에서 오류가 발생합니다. "Foo"는 Foo.Foo와 Bar.Foo 사이에서 모호합니다. Bummer. 이름을 완전히 정규화하여 수정하겠습니다.

   class C { Foo.Foo foo; } 

이제 " Foo.Foo의 Foo는 Foo.Foo와 Bar.Foo간에 모호합니다 "라는 모호성 오류가 발생 합니다. 우리는 여전히 첫 번째 Foo가 무엇을 의미하는지 알지 못합니다. 그리고 우리가 그것을 알아낼 때까지 우리는 두 번째 Foo가 무엇을 의미하는지 알아 내려고 노력하지도 않습니다.

---

네임 스페이스와 클래스에 동일한 이름을 지정하면 다른 사람들이 말한 것처럼 컴파일러를 혼동 할 수 있습니다.

그럼 어떻게 이름을 지 을까요?

네임 스페이스에 여러 클래스가있는 경우 이러한 모든 클래스를 정의하는 이름을 찾습니다.

네임 스페이스에 클래스가 하나만 있는 경우 (따라서 동일한 이름을 지정하려는 유혹) 네임 스페이스 ClassName NS . 이것은 Microsoft가 최소한 네임 스페이스의 이름을 지정하는 방법입니다.

---

난 당신이 내가에있어 조언을 따를 것을 제안 microsoft.public.dotnet.languages.csharp사용에 MyLib.ScenegraphUtil.Scenegraph와 MyLib.ScenegraphUtil.*.

---

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 useful in helping you find potential issues.

---

Just Adding my 2 cents:

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 .

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.

This behaviour was exhibited by VS 2015 running .Net 4.6

---

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."

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).

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:

namespace MyLib
{
    public partial class Scenegraph
    {
        //Scenegraph specific implementations
    }
}

DependentClass.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.

---

As others have said, it's a good practice to avoid naming a class the same as its namespace.

Here are some additional naming suggestions from an answer by svick to a related question "Same class and namespace name" on the Software Engineering Stack Exchange:

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.

(Note that the above answer uses Model.DataSource.DataSource, Model.QueryStorage.QueryStorage., and Model.Project.Project as examples rather than MyLib.Scenegraph.Scenegraph.)

(I also found the other naming suggestions in the other answers here helpful.)

---

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...

namespace SocketLib
{
    class Socket
    {

참고URL : https://stackoverflow.com/questions/18731415/namespace-and-class-with-the-same-name