QT:¿Es una buena idea basar los objetos de mi dominio en QObject?

Question

Soy razonablemente nuevo en el uso del marco QT en combinación con C++.Me preguntaba:¿Es una buena idea basar mis clases de dominio en QObject?¿O debería hacer esto sólo para las clases superiores en la jerarquía?(más cerca del nivel de la interfaz de usuario).La documentación de QT no es clara al respecto:

Tomado de la documentación de QT:

El sistema de metaobjetos es una extensión de C++ que hace que el lenguaje se adapte mejor a la programación GUI de componentes reales.

Obviamente quiero crear mi aplicación de una manera agradable y bien estructurada.Durante los últimos días he estado navegando por la documentación de QT para encontrar una respuesta a esta pregunta.No quiero cometer ningún error elemental que haga que mi solicitud quede floja para toda la eternidad ;-).

Ya he mirado la documentación básica de QObject y el modelo Qt Object.También encontré un artículo de carne fresca lo que me ayudó pero no me ayudó mucho a llegar a una conclusión.Otra cosa que me confunde es que QT en sí no parece ser consistente en este asunto porque no todas las clases de QT usan QObject como clase base.

Las ventajas de usar QObject como clase base tal como yo las veo:

• Jerarquía
• Señales y ranuras
• Propiedades
• Ser capaz de utilizar punteros protegidos
• Internacionalización

Sin embargo, no necesito ninguna de estas funcionalidades en la mayoría de mis clases de dominio.¿Existe una regla de mejores prácticas para esto?¿O debería ser la regla:¿Utilizarlo si requiere alguno de los puntos mencionados anteriormente?

Espero no haber hecho esto demasiado confuso :-)

Answer 1

En general, a menos que haya una "necesidad convincente", es mejor mantener sus clases de dominio "Vanilla".Eso le brinda la mayor flexibilidad en el futuro (por ejemplo, re-usándolos en un entorno que no sea QT).

Answer 2

"Úselo si necesita alguno de los puntos mencionados anteriormente", es difícil decirlo mejor.No hay razón para agregar una funcionalidad innecesaria a cada clase. Piense también sobre las clases definidas en las bibliotecas compartidas: pueden ser utilizadas por clientes que no son QT, si no lo derivan desde QObject.

Answer 3

Este problema no es 'tan grande' como piensas.Realmente no importa todo eso.Yo diría que si lo haces o no, realmente no será tan diferente.Entonces, como regla general, no, solo para hacer las cosas más sencillas.Sin embargo, si necesita ranuras de señal o algo que se realice, adelante, siga adelante, no cuesta todo eso de todos modos.

Answer 4

Hay una buena razón para no heredar de QOBJECT innecesariamente, y es Justo allí en la documentación .

sin constructor de copia o operador de asignación

qobject no tiene un constructor de copia ni un operador de asignación.[...]

La principal consecuencia es que usted debe usar los punteros a QOBJECT (o para su subclase QObject) donde puedas de lo contrario, tenga la tentación de usar su QOBJECT Subclase como un valor.Para Ejemplo, sin un constructor de copia, No puedes usar una subclase de QOBJECT como El valor que se almacenará en uno de los Clases de contenedores. debes almacenar punteros.

Answer 5

Casi me gustaría responder lo contrario de tu pregunta, es no una mala idea.Si deberían ser QObjects Depende de tus necesidades.Para mí, la capacidad de utilizar propiedades y reflexión casi vale más que la señal y las ranuras. QMetaObject Puede ser muy útil para estrategias de programación flexibles.

Answer 6

Estoy aprendiendo (Documento de Lectura) pero no comenzó a usar QT Sin embargo, aquí está mi opinión sobre su pregunta. Siempre es bueno tener un solo objeto de raíz (cobject en MFC, TOBJECT en VCL), así que definirá su propio objeto raíz, tal como yowownrootObject. Si cree que necesita la mayor cantidad de tiempo, haga que TwoWNOWNROOTOBJECT sea heredado de QOBJECT, de lo contrario, deje solo a suyownrootObject solo hasta que necesite QObject.