이 경우 중첩 클래스를 사용해야 합니까?

08-06-2019
|

문제

저는 비디오 재생 및 녹음에 사용되는 클래스 모음을 작업 중입니다.다음과 같은 메소드를 사용하여 공개 인터페이스처럼 작동하는 하나의 기본 클래스가 있습니다. play(), stop(), pause(), record() 등...그런 다음 비디오 디코딩 및 비디오 인코딩을 수행하는 주력 클래스가 있습니다.

방금 C++에 중첩 클래스가 있다는 사실을 알게 되었는데, 프로그래머들이 이를 사용하는 것에 대해 어떻게 생각하는지 궁금합니다.나는 약간 조심스럽고 장점/단점이 무엇인지 잘 모르지만 (내가 읽고 있는 책에 따르면) 나와 같은 경우에 사용되는 것 같습니다.

책에서는 나와 같은 시나리오에서 인터페이스 클래스 내에 주력 클래스를 중첩하여 클라이언트가 사용하지 않을 클래스에 대한 별도의 파일이 없도록 하고 가능한 이름 지정 충돌을 방지하는 것이 좋은 해결책이라고 제안합니다.나는 이러한 정당화에 대해 모른다.중첩 클래스는 나에게 새로운 개념입니다.프로그래머가 이 문제에 대해 어떻게 생각하는지 보고 싶을 뿐입니다.

해결책

여기서는 중첩 클래스를 사용하는 것을 약간 꺼려합니다.백엔드 작업(작업자)을 처리하기 위해 "멀티미디어 드라이버"에 대한 추상 기본 클래스를 만들고 프런트엔드 작업을 위한 별도의 클래스를 만들었다면 어떻게 될까요?프런트 엔드 클래스는 구현된 드라이버 클래스(적절한 미디어 유형 및 상황에 대해)에 대한 포인터/참조를 취하고 주력 구조에 대한 추상 작업을 수행할 수 있습니다.

내 철학은 두 구조가 동시에 사용될 것이라는 가정하에 클라이언트가 세련된 방식으로 두 구조에 액세스할 수 있도록 만드는 것입니다.

나는 다음과 같은 것을 참조 할 것입니다 QTextDocument Qt에서.베어메탈 데이터 처리에 대한 직접적인 인터페이스를 제공하지만 조작을 수행하려면 QTextEdit과 같은 개체에 권한을 전달합니다.

다른 팁

기본 클래스를 구현하는 데 필요한 (작은) 도우미 클래스를 만들려면 중첩 클래스를 사용합니다.또는 예를 들어 인터페이스(추상 메서드가 있는 클래스)를 정의합니다.

이 경우 중첩 클래스의 가장 큰 단점은 재사용이 더 어렵다는 것입니다.아마도 다른 프로젝트에서 VideoDecoder 클래스를 사용하고 싶을 수도 있습니다.VideoPlayer의 중첩 클래스로 만들면 우아한 방식으로 이 작업을 수행할 수 없습니다.

대신 다른 클래스를 별도의 .h/.cpp 파일에 넣어 VideoPlayer 클래스에서 사용할 수 있습니다.이제 VideoPlayer의 클라이언트는 VideoPlayer를 선언하는 파일만 포함하면 되며 이를 구현한 방법은 알 필요가 없습니다.

중첩 클래스를 사용할지 여부를 결정하는 한 가지 방법은 이 클래스가 지원 역할을 하는지 아니면 자체 역할을 하는지 생각하는 것입니다.

다른 클래스를 돕기 위한 목적으로만 존재하는 경우 일반적으로 중첩 클래스로 만듭니다.여기에는 많은 경고 사항이 있으며 그 중 일부는 모순되는 것처럼 보이지만 모두 경험과 직감에 달려 있습니다.

당신이 사용할 수있는 경우처럼 들립니다. 전략 패턴

때로는 사용자로부터 구현 클래스를 숨기는 것이 적절합니다. 이러한 경우 공용 클래스 정의 내부보다 foo_internal.h에 넣는 것이 더 좋습니다.이렇게 하면 foo.h의 독자는 여러분이 원하는 것이 무엇인지 고민하지 않아도 되지만 인터페이스의 구체적인 구현 각각에 대한 테스트를 계속 작성할 수 있습니다.

우리는 약간 오래된 Sun C++ 컴파일러와 표준에서 동작이 변경된 중첩 클래스의 가시성 문제에 직면했습니다.물론 이것이 중첩 클래스를 수행하지 않는 이유는 아닙니다. 단지 오래된 컴파일러를 포함한 많은 플랫폼에서 소프트웨어를 컴파일할 계획이라면 알아야 할 사항일 뿐입니다.

인터페이스 클래스에서 주력 클래스에 대한 포인터를 사용하고 이를 인터페이스 메서드에서 매개변수나 반환 유형으로 노출하지 않는 경우 인터페이스 헤더 파일에 해당 작업 말에 대한 정의를 포함할 필요가 없습니다. 대신 앞으로 선언하세요).이렇게 하면 인터페이스 사용자는 백그라운드의 클래스에 대해 알 필요가 없습니다.

이를 위해 클래스를 중첩할 필요는 없습니다.실제로 별도의 클래스 파일을 사용하면 프로젝트가 성장함에 따라 코드를 훨씬 더 읽기 쉽고 관리하기 쉽게 만들 수 있습니다.나중에 하위 클래스를 지정해야 하는 경우(다른 콘텐츠/코덱 유형에 대해) 도움이 될 것입니다.

자세한 내용은 다음과 같습니다. PIMPL 패턴 (섹션 3.1.1).

외부 클래스의 공용 인터페이스를 사용하여 별도의 클래스로 구현할 수 없는 경우에만 내부 클래스를 사용해야 합니다.내부 클래스는 클래스의 크기, 복잡성 및 책임을 증가시키므로 아껴서 사용해야 합니다.

귀하의 인코더/디코더 클래스가 전략 패턴

중첩 클래스를 피하는 한 가지 이유는 코드를 swig(http://www.swig.org) 다른 언어와 함께 사용할 수 있습니다.Swig는 현재 중첩 클래스에 문제가 있으므로 중첩 클래스를 노출하는 라이브러리와의 인터페이스는 정말 고통스럽습니다.

명심해야 할 또 다른 사항은 작업 기능(예: 디코딩 및 인코딩)의 다양한 구현을 구상하는지 여부입니다.이 경우 함수를 구현하는 다양한 구체적인 클래스가 있는 추상 기본 클래스가 필요할 것입니다.각 구현 유형에 대해 별도의 하위 클래스를 중첩하는 것은 실제로 적절하지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow