Sous-classer QApplication

Bonjour,

Je souhaite savoir s'il est judicieux de sous-classer QApplication pour assurer l'initialisation et la finalisation d'une unique connection à une BDD indispensable pour un fonctionnement correct du programme ?

On m'a toujours dit : sous-classer A en B uniquement si B est A. Mais j'ai un peu de mal à répondre à cette question si j'ajoute la connection / déconnection de la BDD.

Bonjour

On dit "hériter" ou "dériver", pas "sous classer".

Sinon, pourquoi ta classe QApplication (ou dérivée) devrait avoir la responsabilité de gérer les connections à la base de données ? Je dirais à priori aucune raison donc pas besoin de dériver QApplication (et ça serait lui donner une responsabilité supplémentaire, ce qui contrevient au "principe de responsabilité unique", cf blog d'Emmanuel Deloget)

Je lis dans la doc Qt que QApplication est responsable de l'initialisation et de la finalisation de l'application.
L'application ne pouvant pas fonctionner sans la connection à la BDD, je considère qu'il s'agit la d'une étape indispensable et prérequise. En d'autre terme qu'il s'agit d'une des étapes d'initialisation.
D'où ma question.... Mais j'avoue que même si sur un plan pratique il y a des avantages; j'ai le sentiment qu'il y a un problème.

Heu parfois il ne faut pas chercher midi à 14h ;)

Il suffit d'initialiser au début du main.cpp et de libérer à la fin il me semble.

Pour une approche plus 'orienté objet', tu peux créer une classe qui initialise dans le constructeur et finalise dans le destructeur. Il te reste à créer l'objet dans le main (il sera détruit lorsqu'il sera hors de portée) par exemple.

Mais aller chipoter dans QApplication qui n'a rien à voir avec ça non !
On utilise l'héritage pour des concepts qui se ressemble, pour des spécialisations de concepts. Pas pour faire une chose en même temps qu'une autre quand ça nous arrange :)

Dans le main ce n'est pas possible parcequ'il faut que la finalisation est lieu après app.exec() pour permettre la libération de ressources.
Dans mon widget principal (fenêtre principale) ce n'est pas possible non plus parcequ'il faut que l'initialisation de la BDD est lieu dans le constructeur, et il faut qu'il soit possible d'annuler la construction de ce même objet.

Donc faut-il créer un autre objet qui encapsule mon widget principal, et qui s'occupe de la BDD ?

Je pense créer une classe singleton qui gére la connection avec la BDD (puisqu'elle doit être unique pour tout le programme), initialise la connection dans le main et qui connecte QApplication::aboutToQuit() à un slot de déconnection.
Pour la libération des ressources avant de fermer la connection, entretenir une liste de pointeurs vers les ressources.

Merci :)

J'ai l'impression que tu te compliques la vie pour rien...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int main(int argc, char** argv) { // initialisation de l'application QApplication app(argc, argv); // initialisation de la base de données QSqlDatabase db = ... // initialisation de la fenêtre principale QMainWindow w; w.show(); // démérrage de la boucle d'évènement return app.exec(); }

---

Si le code dans ta fonction main est trop important, tu peux créer des classes pour initialiser ta base de données et ta fenêtre principale mais pas besoin de les faire hériter de QSqlDatabase et QMainWindow, une simple composition/agrégation est suffisante.
Et pas besoin de créer un singleton, QSqlDatabase est lui même un singleton.

C'est exactement le main que j'ai... mais comment faire les appels à :

Code:

---

1 2 3

QSqlDatabase::database(QSqlDatabase::defaultConnection).close(); QSqlDatabase::removeDatabase(QSqlDatabase::defaultConnection);

---

à la fin de l'application ?
Sachant que w est une instance d'une classe qui hérite de QMainWindow et qui encapsule des modèles SQL.
En d'autres termes l'exécution du code précédent sans la suppression des ressources utilisées provoque une erreur Qt SQL.

Je peux résoudre le problème en modifiant :

Code:

---

1 2 3 4

QMainWindow *w = new QMainWindow(); w->show(); w->setAttribute(Qt::WA_DeleteOnClose);

---

Mais c'est vraiment du bricolage...
Je préfèrerais avoir un vrai contrôle sur la BDD et ne pas laisser Qt s'occuper des appels à removeDatabase.

http://qt.developpez.com/doc/latest/...n/#abouttoquit

Même problème avec QCoreApplication::aboutToQuit()...
Le widget comporte des modèles qui ne sont pas détruit au moment du signal ce qui provoque la même erreur.

Ma question ne porte pas vraiment sur l'aspect technique mais plutôt sur la conception.