¿Debo usar clases anidadas en este caso?

votos
42

Estoy trabajando en una colección de clases utilizadas para la reproducción y grabación de videos. Tengo una clase principal, que actúa como la interfaz pública, con métodos como play(), stop(), pause(), record()etc ... Entonces tengo clases de caballo de batalla que hacen la decodificación de vídeo y codificación de vídeo.

Acabo de enterarme de la existencia de clases anidadas en C ++, y tengo curiosidad por saber qué piensan los programadores sobre su uso. Estoy un poco cauteloso y no estoy seguro de cuáles son los beneficios / inconvenientes, pero parecen (de acuerdo con el libro que estoy leyendo) para ser utilizados en casos como el mío.

El libro sugiere que en un escenario como el mío, una buena solución sería anidar las clases de caballo de batalla dentro de la clase de interfaz, por lo que no hay archivos separados para las clases que el cliente no debe usar, y para evitar cualquier posible conflicto de nomenclatura. No sé sobre estas justificaciones. Las clases anidadas son un concepto nuevo para mí. Solo quiero ver qué piensan los programadores sobre el problema.

Publicado el 02/08/2008 a las 03:51
fuente por usuario
En otros idiomas...                            


10 respuestas

votos
25

Sería un poco reacio a usar clases anidadas aquí. ¿Qué sucede si crea una clase base abstracta para un "controlador multimedia" para manejar las cosas de back-end (workhorse), y una clase separada para el trabajo de front-end? La clase de front-end podría tomar un puntero / referencia a una clase de controlador implementada (para el tipo de medio apropiado y la situación) y realizar las operaciones abstractas en la estructura de caballo de batalla.

Mi filosofía sería seguir adelante y hacer ambas estructuras accesibles para el cliente de una manera pulida, bajo la suposición de que se usarían en tándem.

Haría referencia a algo así como QTextDocument en Qt. Proporciona una interfaz directa para el manejo de datos de metal desnudo, pero transfiere la autoridad a un objeto como un QTextEdit para realizar la manipulación.

Respondida el 02/08/2008 a las 04:00
fuente por usuario

votos
9

Utilizarí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. Tal vez le gustaría usar su clase VideoDecoder en otro proyecto. Si lo convierte en una clase anidada de VideoPlayer, no puede hacer esto de una manera elegante.

En cambio, coloque las otras clases en archivos .h / .cpp separados, que luego puede usar en su clase VideoPlayer. El cliente de VideoPlayer ahora solo necesita incluir el archivo que declara VideoPlayer, y aún no necesita saber cómo lo implementó.

Respondida el 17/09/2008 a las 12:50
fuente por usuario

votos
5

Una forma de decidir si se usan o no las clases anidadas es pensar si esta clase tiene o no una función de apoyo o si es parte de ella.

Si existe únicamente para ayudar a otra clase, generalmente la convertiré en una clase anidada. Hay un montón de advertencias al respecto, algunas de las cuales parecen contradictorias, pero todo se reduce a la experiencia y el presentimiento.

Respondida el 05/08/2008 a las 09:29
fuente por usuario

votos
4

Bueno, si usa punteros a sus clases de caballo de batalla 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 adelante declararlos en su lugar). De esta forma, los usuarios de su interfaz no necesitarán saber sobre las clases en segundo plano.

Definitivamente no es necesario anidar clases para esto. De hecho, los archivos de clase separados harán que tu código sea mucho más legible y fácil de administrar a medida que crezca tu proyecto. también lo ayudará más adelante si necesita una subclase (por ejemplo, para diferentes tipos de contenido / códec).

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

Respondida el 26/09/2008 a las 00:34
fuente por usuario

votos
4

Nos topamos con un problema con un compilador Sun C ++ semi-viejo 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, algo a tener en cuenta si planea compilar su software en muchas plataformas, incluidos compiladores antiguos.

Respondida el 21/09/2008 a las 01:39
fuente por usuario

votos
4

A veces es apropiado ocultar las clases de implementación del usuario; en estos casos, es mejor colocarlas en foo_internal.h que dentro de la definición de clase pública. De esta forma, los lectores de tu foo.h no verán lo que preferirías que no les molestara, pero aún puedes escribir pruebas contra cada una de las implementaciones concretas de tu interfaz.

Respondida el 16/09/2008 a las 10:31
fuente por usuario

votos
4

suena como un caso donde podrías usar el patrón de estrategia

Respondida el 05/08/2008 a las 09:37
fuente por usuario

votos
2

Debería usar una clase interna solo cuando no pueda implementarla como una clase separada utilizando la interfaz pública de la futura 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 parece que se ajusta mejor al patrón de estrategia

Respondida el 18/09/2008 a las 16:19
fuente por usuario

votos
1

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

Respondida el 23/09/2008 a las 20:07
fuente por usuario

votos
1

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

Respondida el 20/09/2008 a las 08:37
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more