¿Debería utilizar clases anidadas en este caso?

Question

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...Luego tengo clases de caballos de batalla que hacen la decodificación y codificación de video.

Acabo de enterarme de la existencia de clases anidadas en C++ y tengo curiosidad por saber qué piensan los programadores sobre su uso.Soy un poco cauteloso y no estoy muy seguro de cuáles son los beneficios/desventajas, pero parecen (según el libro que estoy leyendo) usarse 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, de modo que no haya archivos separados para las clases que el cliente no debe usar y evitar posibles conflictos de nombres.No conozco estas justificaciones.Las clases anidadas son un concepto nuevo para mí.Solo quiero ver qué piensan los programadores sobre el tema.

Answer 1

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

Mi filosofía sería seguir adelante y hacer que ambas estructuras sean accesibles para el cliente de una manera pulida, bajo el supuesto de que se usarían en conjunto.

Haría referencia a algo como un QTextDocumento en Qt.Proporciona una interfaz directa para el manejo de datos básicos, pero pasa la autoridad a un objeto como QTextEdit para realizar la manipulación.

Answer 2

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

En este caso, la principal desventaja de las clases anidadas es que dificulta su reutilización.Quizás quieras utilizar tu clase VideoDecoder en otro proyecto.Si lo convierte en una clase anidada de VideoPlayer, no podrá hacerlo de forma elegante.

En su lugar, coloque las otras clases en archivos .h/.cpp separados, que luego podrá 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ó.

Answer 3

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

Si existe únicamente con el propósito de ayudar a otra clase, generalmente la convierto 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 la intuición.

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

Bueno, si usa punteros a sus clases de caballos 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 batalla en su archivo de encabezado de interfaz (simplemente declararlos en su lugar).De esa manera, los usuarios de su interfaz no necesitarán conocer las clases en segundo plano.

Definitivamente no necesitas anidar clases para esto.De hecho, los archivos de clase separados harán que su código sea mucho más legible y fácil de administrar a medida que su proyecto crezca.También le ayudará más adelante si necesita crear subclases (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).

Answer 8

Debe usar una clase interna solo cuando no pueda implementarla como una clase separada usando la interfaz pública de la posible 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 adapta mejor a Patrón de estrategia

Answer 9

Una razón para evitar las clases anidadas es si alguna vez pretendes envolver el código con swig (http://www.swig.org) para usar con otros idiomas.Actualmente, Swig tiene problemas con las clases anidadas, por lo que interactuar con bibliotecas que exponen clases anidadas se convierte en una verdadera molestia.

Answer 10

Otra cosa a tener en cuenta es si alguna vez imagina diferentes implementaciones de sus funciones de trabajo (como decodificación y codificación).En ese caso, definitivamente querrás 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.