C ++에서 네임 스페이스를 사용하는 모범 사례 [닫기]

몇 개월 전에 Bob 아저씨의 Clean Code를 읽었 으며 코드 작성 방식에 큰 영향을 미쳤습니다. 비록 그가 모든 프로그래머가 알아야 할 것들을 반복하는 것처럼 보였지만, 그것들을 모두 모아서 연습하게함으로써 훨씬 더 깨끗한 코드를 얻게됩니다. 특히 큰 함수를 여러 개의 작은 함수로 나누고 큰 클래스를 여러 개의 작은 클래스로 나누면 매우 유용합니다.

이제 질문이 있습니다. 이 책의 예제는 모두 Java로되어 있으며 지난 몇 년 동안 C ++로 작업 해 왔습니다. Clean Code 의 아이디어 는 Java에 존재하지 않는 네임 스페이스 사용으로 어떻게 확장됩니까? (예, Java 패키지에 대해 알고 있지만 실제로는 다릅니다.)

책임을 명확하게 정의한 많은 작은 엔티티를 생성하는 아이디어를 네임 스페이스에 적용하는 것이 합리적입니까? 소규모의 관련 클래스 그룹은 항상 네임 스페이스로 묶어야합니까? 이것이 많은 작은 클래스를 갖는 복잡성을 관리하는 방법입니까, 아니면 많은 네임 스페이스를 관리하는 비용이 엄청 날까요?

편집 : 내 패키지 질문에 대한이 위키 백과 항목 에서 내 질문에 대답 합니다.

( 깨끗한 코드를 읽지 않았으며 Java를 많이 알지 못합니다.)

책임을 명확하게 정의한 많은 작은 엔티티를 생성하는 아이디어를 네임 스페이스에 적용하는 것이 합리적입니까?

예, 여러 클래스와 여러 함수로 리팩토링하는 것과 마찬가지입니다.

소규모의 관련 클래스 그룹은 항상 네임 스페이스로 묶어야합니까?

실제로 대답하지 않으면 : 예, 최소한 하나의 최상위 네임 스페이스를 사용해야합니다. 이것은 프로젝트, 조직 또는 원하는 것을 기반으로 할 수 있지만 전역 이름을 거의 사용하지 않으면 이름 충돌이 줄어 듭니다. 다른 모든 것을 그룹화하는 단일 네임 스페이스는 하나의 전역 이름 만 도입합니다. extern "C"함수는 제외하지만 C 상호 운용성으로 인해 다른 extern "C"함수에만 영향을줍니다.

소규모의 관련 클래스 그룹을 전용 네임 스페이스로 래핑 해야합니까? 아마. 특히 FrobberThing, FrobberThang, FrobberDoohickey 클래스에서 공통 접두사를 사용하는 경우 네임 스페이스 (frobber :: Thing 등)를 고려해야합니다. 더 큰 프로젝트의 일부인 경우 여전히 루트 네임 스페이스 또는 다른 네임 스페이스 아래에 있습니다.

이것이 많은 작은 클래스를 갖는 복잡성을 관리하는 방법입니까, 아니면 많은 네임 스페이스를 관리하는 비용이 엄청 날까요?

위의 접두사 이름 예제를 사용하면 FrobberThing보다 frobber :: Thing을 관리하는 것이 어렵지 않습니다. 문서화 및 코드 완성과 같은 일부 도구를 사용하면 더 쉬울 수도 있습니다. ADL과 다른 점이 있지만 이는 유리한 방식으로 작동 할 수 있습니다. 연결된 네임 스페이스의 이름이 적을수록 ADL을 알아내는 것이 더 간단 해지며 선언을 사용하여 특정 네임 스페이스에 특정 이름을 주입 할 수 있습니다.

네임 스페이스 별명을 사용하면 특정 컨텍스트에서 더 긴 네임 스페이스에 더 짧은 이름을 사용할 수 있으므로 다시 쉽게 사용할 수 있습니다.

void f() {
  namespace CWVLN = Company_with_very_long_name;  // Example from the standard.
  // In this scope, use CWVLN::name instead of Company_with_very_long_name::name.
  namespace fs = boost::filesystem;  // Commonly used.
}

다양한 라이브러리에 대해 단일 루트 네임 스페이스, boost 및 여러 하위 네임 스페이스 (boost :: asio, boost :: io, boost :: filesystem, boost :: tuples 등)가있는 Boost를 고려하십시오. 일부 이름은 루트 네임 스페이스 로 "승격" 됩니다.

모든 정의는 namespace :: boost :: tuples에 있지만 가장 일반적인 이름은 선언을 사용하여 namespace :: boost로 들어갑니다. 이 이름은 tuple, make_tuple, tie and get입니다. 또한 ref와 cref는 :: boost 네임 스페이스에서 직접 정의됩니다.

"실제"모듈을 가진 언어와의 가장 큰 차이점은 더 평평한 구조를 사용하는 것이 얼마나 흔한 지입니다. 중첩 된 이름을 정의하기 위해 특별한 노력을 기울이지 않는 한 주로 작동하기 때문입니다.

모든 코드에 대해 하나의 마스터 네임 스페이스가 있어야합니다. 네임 스페이스와 관련하여 외부 코드와 구별됩니다.

마스터 네임 스페이스 내에서 크기와 복잡성에 따라 하위 네임 스페이스를 열 수 있습니다. 여기에서 이름은 컨텍스트 내에서 분명한 의미를 가지며, 동일한 이름이 다른 컨텍스트 내에서 사용될 수 있습니다.

특히 컨텍스트 내에서 특정한 것을 의미하는 FileInfo와 같은 일반적인 소리 이름이 있으면 네임 스페이스에 넣으십시오.

클래스를 확장 할 수 없어서 헤더를 수정하지 않고 클래스에 새 선언을 추가 할 수는 없지만 클래스를 사용할 수도 있습니다.

네임 스페이스는 모듈 개념이 아니므로 이름 충돌이 발생할 수있는 경우에만 사용합니다.

Java에는 네임 스페이스가 있으며 실제로는 그렇게 부르지 않습니다. In javax.swing.* javax은 네임 스페이스이며 swing하위 네임 스페이스입니다. Java 패키지에 대한 내용을 알기 위해이 책을 읽지는 않았지만 동일한 원칙이 모든 언어의 네임 스페이스에 거의 직접 적용됩니다.

좋은 휴리스틱은 클래스에 대해 동일한 접두사를 반복해서 입력하려는 경우 네임 스페이스를 사용한다는 것입니다. 예를 들어, 최근 OmciAttribute, OmciAlarm, OmciMe 등의 클래스를 작성했으며 Omci를 자체 네임 스페이스로 분리해야한다는 것을 깨달았습니다.

나는 깊은 네임 스페이스 (일반적으로 세 가지 수준을 의미 함)를 좋아합니다.

• 회사 이름이 있습니다.
• app / util / lib / etc
• 적절한 프로젝트 이름 또는 패키지

상황에 따라 한 단계 더있을 수 있습니다

• 세부 사항 (플랫폼 특정 구현 세부 사항)
• utils (아직 일반 유틸리티로 이동하지 않은 유틸리티 개체)
• 내가 필요한 건 뭐든지