네임 스페이스의 클래스 수-코드 냄새?

여러 실행 파일에서 사용하는 C # 라이브러리가 있습니다. 라이브러리에는 네임 스페이스가 두 개 뿐이며 네임 스페이스 중 하나에 클래스가 상당히 많이 있습니다. 분류로 인해 단일 네임 스페이스에 너무 많은 클래스가있는 것을 항상 피했습니다. 그리고 무의식적으로는 더 깊은 네임 스페이스 계층 구조를 갖는 것이 더 예쁘다고 생각합니다.

내 질문은 : 클래스가 서로 관련이 있더라도 네임 스페이스에 많은 클래스가있을 때 다른 사람이 그것을 "코드 냄새"로 간주합니까? 하위 분류를 허용하는 클래스에서 뉘앙스를 찾기 위해 많은 노력을 기울입니까?

반드시 그런 것은 아닙니다. 모든 클래스가 실제로 네임 스페이스에 의해 정의 된 범주에 속한다면 괜찮습니다.

당신이 할 수있는 일은 수업을보고 수업 중 일부를 병합 할 가능성을 반영하는 것입니다. 이러한 클래스의 작은 그룹이 "가족"기능을 지원할 수도 있지만 몇 가지 역사적인 이유로 개별적으로 구현되었습니다. 이제 충분한 시간이 경과하면 더 나은 구성이 가능할 수 있습니다.

네임 스페이스가 너무 많으면 프로그래머가 라이브러리를 사용하고 탐색하기가 훨씬 어려워 지므로 피해야합니다. 또한 네임 스페이스가 많으면 디자이너가 각 네임 스페이스에 정확한 이름을 제공하고 특정 클래스가 속하는 네임 스페이스를 결정하는 것이 어려울 수 있습니다.

가장 간단한 방법은 모든 기본 시나리오를 단일 네임 스페이스에 넣고 고급 시나리오 클래스를 하위 네임 스페이스에 넣는 것입니다. .NET Framework는 항상 이 작업을 수행합니다.이 실습의 좋은 예 System.Collections와 참조하십시오 System.Collections.Specialized.

하나 또는 두 개의 첫 번째 수준 네임 스페이스 만 있으면 프로그래머가 그러한 클래스를 찾을 준비가 될 때까지 고급 또는 특수 클래스가 숨겨져 코드를 훨씬 쉽게 탐색 할 수 있습니다.

이들이 서로 속해 있고 서로 관련되어있는 한, 네임 스페이스에 너무 많은 클래스를 갖는 데에는 문제가 없습니다.

그것은 자신의에 여부 클래스가 속한 별도의 네임 스페이스는 개인 취향의 문제이다.

더 자연스러운 것?

Parsers.XML.XmlParser.cs
Parsers.XmlParser.cs

그것은 전적으로 방법에 따라 달라집니다 당신이 보고 싶어하고 코드를 호출합니다.

개인적으로, 하나 이상의 클래스가 속해 있다는 것을 알 때에 만 별도의 네임 스페이스를 선호 합니다.

이건 괜찮아. 네임 스페이스를 갖는 주된 이유는 이름 충돌을 피하기 위함입니다.이 후에야 규칙이 아닌 개인적인 선택의 문제인 논리적 범위에 대해 생각해야합니다. 물론 현명한 규칙도 환영합니다. 아무도 하나의 네임 스페이스에서 3k ~ 4k 클래스를 스크롤하고 싶지 않습니다.

좋은 예는 C ++ 표준 라이브러리 의 표준 네임 스페이스로, 고유 알고리즘을 표준 알고리즘과 분리 할 수 ​​있습니다.