QT: è una buona idea basare i miei oggetti di dominio su QObject?

Question

Sono abbastanza nuovo nell'usare il framework QT in combinazione con C++. Mi stavo chiedendo: è una buona idea basare le mie classi di dominio su QObject? O dovrei farlo solo per le classi più in alto nella gerarchia? (più vicino al livello dell'interfaccia utente). La documentazione QT non è chiaro su questo:

recuperate dalla documentazione QT:

Il sistema di meta-oggetto è un'estensione C++ che rende il linguaggio più adatto alla vera programmazione componente GUI.

Ovviamente voglio costruire la mia applicazione in un modo ben strutturato. Negli ultimi giorni ho cercato la documentazione QT per trovare una risposta a questa domanda. Non voglio fare un errore elementare che renderà la mia applicazione inerte per tutta l'eternità ;-).

Ho già esaminato la documentazione di base per QObject e il modello Qt Object. Ho anche trovato un freshmeat article che mi ha aiutato ma non mi ha davvero aiutato a raggiungere una conclusione. Qualcos'altro che mi confonde è che il QT stesso non sembra essere coerente in questa materia perché non tutte le classi QT usano QObject come classe base.

I vantaggi di utilizzare QObject come classe base come li vedo:

• Gerarchia
• segnali e slot
• Proprietà
• Essere in grado di utilizzare i puntatori custoditi
• Internazionalizzazione

Tuttavia, non richiedo e ognuna di queste funzionalità nella maggior parte delle mie classi di dominio. C'è una regola di best practice per questo? O dovrebbe essere la regola: usala se hai bisogno di uno dei punti sopra menzionati?

La speranza non ho fatto questo :-) troppo confusa

Answer 1

In generale, a meno che non vi sia un "bisogno impellente", è meglio mantenere le classi di dominio "vanilla". Ciò ti dà la massima flessibilità in futuro (ad esempio riutilizzandoli in un ambiente non Qt).

Answer 2

"Usalo se hai bisogno di uno qualsiasi dei punti di cui sopra" - è difficile da dire meglio. Non c'è motivo di aggiungere funzionalità inutili ad ogni classe. Pensa anche alle classi definite nelle librerie condivise: possono essere usate dai client non-Qt, se non li si ricava da QObject.

Answer 3

Questo problema non è "grande" come si potrebbe pensare. Non importa molto. Direi che se lo fai o no non sarà davvero così diverso. Quindi, come regola generale, non farlo, solo per semplificare le cose. Se, tuttavia, hai bisogno di slot di segnale o di qualcosa che Qt ha realizzato, vai avanti, non costa comunque molto.

Answer 4

Mi piacerebbe quasi rispondere al contrario della tua domanda, è non è una buona idea. Se dovrebbero essere QObjects dipende dalle tue esigenze. Per me la capacità di usare proprietà e riflessioni vale quasi più quel segnale e gli slot.QMetaObject può essere molto utile per strategie di programmazione flessibili

Answer 5

Sto imparando (leggendo il documento) ma non ho ancora iniziato a utilizzare Qt, ecco la mia opinione sulla tua domanda. È sempre utile disporre di un singolo oggetto radice (CObject in MFC, TObject in VCL), quindi definire un oggetto radice personale, ad esempio YourOwnRootObject. Se pensate di aver bisogno di QObject più tempo, rendete YourOwnRootObject ereditato da QObject, altrimenti lasciate YourOwnRootObject da solo fino a quando non avrete bisogno di QObject.

Answer 6

C'è una buona ragione per non ereditare da QObject inutilmente, ed è right there in the documentation.

Nessun costruttore di copia o di operatore di assegnamento

QObject non ha né un costruttore di copia né un operatore di assegnazione. [...]

La principale conseguenza è che si dovrebbe usare puntatori a QObject (o per il vostro QObject sottoclasse) dove si potrebbe altrimenti essere tentati di utilizzare il QObject sottoclasse come un valore. Per esempio , senza un costruttore di copia, non è possibile utilizzare una sottoclasse di QObject come il valore da memorizzare in una delle classi di contenitore . È necessario memorizzare i puntatori .