Debo usar clases anidadas en este caso?

Usaría una clase anidada para crear una clase auxiliar (pequeña) que se requiere para implementar la clase principal. O por ejemplo, para definir una interfaz (una clase con métodos abstractos).

En este caso, la principal desventaja de las clases anidadas es que esto hace que sea más difícil reutilizarlas. Quizás te gustaría usar tu clase VideoDecoder en otro proyecto. Si lo convierte en una clase anidada de VideoPlayer, no puede hacer esto de una manera elegante.

En su lugar, ponga las otras clases en separado .h.archivos cpp, que luego puede usar en su clase VideoPlayer. El cliente de VideoPlayer ahora solo necesita incluir el archivo que declara VideoPlayer, y todavía no necesita saber cómo lo implementó.

Una forma de decidir si usar o no clases anidadas es pensar si esta clase juega o no un papel secundario o es su propia parte.

Si existe únicamente con el propósito de ayudar a otra clase, generalmente la hago una clase anidada. Hay un montón de advertencias a eso, algunas de las cuales parecen contradictorias, pero todo se reduce a la experiencia y el sentimiento visceral.

Suena como un caso en el que podrías usar el patrón de estrategia

A veces es apropiado ocultar las clases de implementación del usuario -- en estos casos es mejor ponerlas en un foo_internal.h que dentro de la definición de clase pública. Así, lectores de tu foo.h no verá con lo que preferiría que no se preocuparan, pero aún puede escribir pruebas contra cada una de las implementaciones concretas de su interfaz.

Encontramos un problema con un compilador Sun C++ semi-antiguo y la visibilidad de las clases anidadas cuyo comportamiento cambió en el estándar. Esta no es una razón para no hacer su clase anidada, por supuesto, solo algo que debe tener en cuenta si planea compilar su software en muchas plataformas, incluidos los compiladores antiguos.

Bien, si usa punteros a sus clases workhorse en su clase de Interfaz y no los expone como parámetros o tipos de retorno en sus métodos de interfaz, no necesitará incluir las definiciones para esos caballos de trabajo en su archivo de encabezado de interfaz (simplemente los declara en su lugar). De esa manera, los usuarios de su interfaz no necesitarán saber acerca de las clases en segundo plano.

Definitivamente no necesitas anidar clases para esto. De hecho, los archivos de clase separados en realidad, haga que su código sea mucho más legible y más fácil de administrar a medida que su proyecto crece. también le ayudará más adelante si necesita subclase (por ejemplo, para diferentes tipos de contenido/códec).

Aquí hay más información sobre el patrón de PIMPL (sección 3.1.1).

Debe usar una clase interna solo cuando no pueda implementarla como una clase separada usando la interfaz pública de la clase externa. Las clases internas aumentan el tamaño, la complejidad y la responsabilidad de una clase, por lo que deben usarse con moderación.

Su clase de codificador/decodificador suena como que se ajusta mejor al Patrón de estrategia

Una razón para evitar las clases anidadas es si alguna vez tiene la intención de envolver el código con swig (http://www.swig.org ) para su uso con otros idiomas. Swig actualmente tiene problemas con las clases anidadas, por lo que interactuar con bibliotecas que exponen cualquier clase anidada se convierte en un verdadero problema.

Otra cosa a tener en cuenta es si alguna vez visualiza diferentes implementaciones de sus funciones de trabajo (como decodificación y codificación). En ese caso, definitivamente querrá una clase base abstracta con diferentes clases concretas que implementen las funciones. No sería realmente apropiado anidar una subclase separada para cada tipo de implementación.