Discussion :

[Galak67]

Bonjour,

Je me suis mis il y a peu au C++/Qt (avec un déjà bon passé de c#). Après avoir lu les faq C++ et Qt, j'ai trouvé réponses à bon nombre de mes questions.

Le point délicat pour lequel j'ai du mal à trouver une réponse est la gestion des "delete" des objets que je crée. Pour tous les objets structurants (dao, repository, services, factory, controller, view, ...) pas de souci, je vois bien comment gérer.

Par contre pour mes entités (panier d'achat, articles, ...), si je sais que je les crée dans un Factory la plupart du temps, j'ai du mal à savoir où il est le plus pratique / le plus recommandable de gérer leur suppression de la mémoire. Et surtout pourquoi. En c#, c'est une question que je ne me suis jamais posé :-)

1/ Dans le Factory parce que c'est lui qui crée alors c'est à lui de détruire ? Pourquoi pas sur le principe mais comment peut-il savoir qu'on a fini d'utiliser ce qu'il a créé ?
2/ Dans le Repository parce que c'est lui qui gère le cycle de vie de mes entités ? oui mais non, on parle du cycle de vie au sens de l'entité (création modif, archivage, suppression), pas vraiment au sens technique de programmation...
3/ Dans le controller ? Après tout c'est un problème bien applicatif, la couche semble être appropriée.
4/ Dans la vue, une fois qu'on a finit de lier le modèle ? bof, bof, son job c'est d'interagir avec l'utilisateur, pas trop la gestion de la mémoire.

L'idée de la question est : la couche métier renvoie une liste des articles correspondants à la recherche (genre un QList<Article*>).
Dois-je tourner sur toute la liste pour faire des delete puis un delete de la liste elle-même ? Qui est responsable de cette destruction ?

Je ne sais même pas si c'est super utile que ça de les détruire mais quand même, si la liste d'article est bien gonflée et qu'on ne libère pas la mémoire, ça risque de pas aimer au bout d'un moment ?

J'espère que ma question ne paraîtra pas idiote à vos yeux de chevronnés du C++ !

Merci d'avance.

[Sylvain Togni]

En fait en C++ moderne on n'utilise pas de pointeurs, c'est trop source de problèmes de durée de vie, de problèmes avec les exceptions, ...

On renverra donc directement un QList<Article>, ou un quelque chose comme un QList<QSharedPointer<Article> > si les Article sont polymorphes.

[Invité]

1/ Dans le Factory parce que c'est lui qui crée alors c'est à lui de détruire ? Pourquoi pas sur le principe mais comment peut-il savoir qu'on a fini d'utiliser ce qu'il a créé ?

Normalement, non : le pattern factory, comme son nom l'indique, ca sert à créer, mais pas à détruire...

2/ Dans le Repository parce que c'est lui qui gère le cycle de vie de mes entités ? oui mais non, on parle du cycle de vie au sens de l'entité (création modif, archivage, suppression), pas vraiment au sens technique de programmation...

Si ce que tu appelles repository est le conteneur où tes éléments sont stockés (la liste dont tu parlais), il me semble qu'effectivement, c'est elle qui va avoir une méthode Enleve(), ou Vide() qui élimine un (ou tous ses) élément(s). Ce sont ces méthodes qui appellent les destructeurs des éléments...

Le code spécifique à la destruction (désallocation de mémoire privée, mise à jour de comptes de références), lui, sera dans le destructeur de la classe de tes objets.

3/ Dans le controller ? Après tout c'est un problème bien applicatif, la couche semble être appropriée.

Le controleur (dans un modèle MVC) ne va pas explicitement détruire les objets, mais sera en charge d'appeler la méthode Enleve() citée précédemment.

4/ Dans la vue, une fois qu'on a finit de lier le modèle ? bof, bof, son job c'est d'interagir avec l'utilisateur, pas trop la gestion de la mémoire.

Effectivement, ce n'est pas son rôle, mais celui du controleur.

L'idée de la question est : la couche métier renvoie une liste des articles correspondants à la recherche (genre un QList<Article*>). Dois-je tourner sur toute la liste pour faire des delete puis un delete de la liste elle-même ? Qui est responsable de cette destruction ?

Normalement, c'est du ressort du controleur : quand la vue lui demande la liste, il la crée, la passse à la vue, puis la détruit, tout de suite, ou quand la vue lui dit "j'ai fini", ou quand il le juge bon (si par exemple il a un cache des requêtes les plus récentes). Mais les détails de la destruction (destruction des éléments puis de la vue) sont normalement l'affaire de la liste (ou du conteneur)... A mon avis, l'élément liste devrait avoir dans son destructeur la libération / destruction de ses éléments. Donc la controleur détruit la liste, qui détruit ses éléments...

Bien sur, ca, c'est la grande théorie. En pratique, une appli, sauf les plus grandes, n'a pas tous ces niveaux, ou plutôt, a tendance à les intégrer en quelques composants. Si tes listes ne contiennent jamais qu'un ou deux types d'éléments, la factory et le repository seront souvent une seule et même structure. Si tu n'as qu'une liste ou deux par vue, tu risques de laisser tomber le controleur (ou de l'intégrer dans une fonction de ta vue). Sinon, ton architecture trop segmentée, au lieu de simplifier ton programme, risque de le compliquer (et en tous cas le ralentir).

Francois

[Galak67]

Merci beaucoup pour vos réponses. Vous m'avez bien éclairé.

Bonne soirée.