QT: ¿Es una buena idea basar mis objetos de 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 solo para las clases más arriba en la jerarquía? (más cerca del nivel de interfaz de usuario). La documentación de QT no está claro en esto:

tomado de la documentación de Qt:

el sistema de meta-objeto es una extensión C++ que hace que el lenguaje más adecuado para cierto programación de componentes GUI.

Obviamente, quiero construir mi aplicación de una manera bien estructurada. En los últimos días he estado buscando en la documentación de QT para encontrar una respuesta a esta pregunta. No quiero cometer ningún error elemental que haga que mi aplicación cojee por toda la eternidad ;-).

Ya he consultado la documentación básica para QObject y el modelo Qt Object. También encontré un freshmeat article que me ayudó, pero realmente no me ayudó a llegar a una conclusión. Otra cosa que me confunde es que QT en sí mismo no parece ser consistente en este asunto porque no todas las clases QT usan QObject como una clase base.

Las ventajas de utilizar QObject como clase base como las veo:

• Jerarquía
• señales y slots
• Propiedades
• ser capaz de usar punteros vigilados
• internacionalización

Sin embargo, no necesito Es cualquiera de estas funcionalidades en la mayoría de mis clases de dominio. ¿Hay una regla de mejores prácticas para esto? ¿O debería ser la regla: úselo si necesita alguno de los puntos mencionados anteriormente?

esperanza Yo no hice esto también confuso :-)

Answer 1

En general, a menos que haya una "necesidad apremiante", es mejor que mantenga sus clases de dominio "vainilla". Eso le brinda la mayor flexibilidad en el futuro (por ejemplo, volver a usarlos en un entorno que no sea Qt).

Answer 2

"Úsalo si necesita cualquiera de los puntos mencionados anteriormente" - es difícil decir mejor. No hay ninguna razón para agregar funcionalidad innecesaria a cada clase. Considere también las clases definidas en bibliotecas compartidas: pueden ser utilizadas por clientes que no son Qt, si no las deriva de QObject.

Answer 3

Este problema no es "tan grande" como podría pensar. Realmente no importa mucho. Yo diría que si lo haces o no, realmente no será tan diferente. Entonces, como regla general, no lo haga, solo para simplificar las cosas. Sin embargo, si necesita ranuras de señal o cualquier cosa Qt reactivada, adelante, de todos modos no cuesta tanto.

Answer 4

Me gustaría responder lo contrario de su pregunta, es no una mala idea. Si deben ser QObjects depende de sus necesidades. Para mí, la capacidad de usar propiedades y reflexión casi vale más que la señal y las máquinas tragamonedas.QMetaObject puede ser muy útil para estrategias de programación flexibles

Answer 5

Estoy aprendiendo (lectura de documentos) pero aún no comencé a usar Qt, esta es mi opinión sobre su pregunta. Siempre es bueno tener un único objeto raíz (CObject en MFC, TObject en VCL), así que defina un objeto raíz propio, como YourOwnRootObject. Si cree que necesita más tiempo de QObject, haga que YourOwnRootObject herede de QObject; de lo contrario, deje YourOwnRootObject solo hasta que necesite QObject.

Answer 6

Hay una buena razón para no heredar de QObject innecesariamente, y es right there in the documentation.

Sin constructor de copia o de operador de asignación

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

La principal consecuencia es que se debe utilizar punteros a QObject (o al la subclase QObject) en la que podría de otro modo tener la tentación de utilizar su QObject subclase como un valor. Para el ejemplo , sin un constructor de copia, no puede usar una subclase de QObject como el valor que se almacenará en una de las clases de contenedor . Debe almacenar punteros.