Structure du document Single Document

Question

J'ai déjà posé des questions sur la manière correcte d'accéder aux variables membres présentes dans le projet. Dans le projet, j'ai une classe dérivée de CWinapp, classe CMainFrm, une liste de différentes classes d'affichage. Cependant, actuellement, j'ai des instances de différentes classes définies par l'utilisateur instanciées dans la classe dérivée de CWinApp, tandis que le reste des classes utilise un pointeur obtenu à partir de la fonction AfxGetApp(), puis accède aux différentes classes définies par l'utilisateur. Certains membres de la communauté sur le groupe de discussion MFC m'ont dit que c'est un très mauvais design (c'est-à-dire que le parent ne devrait rien savoir d'une classe d'application, d'une classe de vue ou d'une classe de document). Cependant, je ne sais pas comment je peux accéder à différentes classes définies par l'utilisateur sans utiliser cette conception. Ce serait génial d'entendre quelques suggestions car je ne connais pas assez le MFC pour trouver des termes de recherche appropriés.

Answer 1

« (le parent ne doit pas savoir quoi que ce soit au sujet d'une application de classe, classe de vue, ou classe de document) »

Je ne suis pas sûr que je comprends cette phrase, que voulez-vous dire par « parent » ici ?

De toute façon, à mon avis, le design que vous décrivez n'est pas vraiment un problème. C'est un compromis: transmettez-vous ces classes à toutes les fonctions qui en ont besoin, compliquant leur utilisation et API, ou les stockez-vous comme une sorte de variables globales comme vous le faites? Cela dépend des données auxquelles vous accédez, et à quelle fréquence. Les données nécessaires dans de nombreux endroits peuvent tout aussi bien être «globales». Il existe plusieurs façons de rendre les données 'globales': en faire un membre de CWinApp (c'est-à-dire votre classe dérivée de CWinApp), ou de CMainFrame, ou faites-vous une véritable 'variable globale', ou faites-vous faire un singleton, ...

Le problème avec les variables globales est qu'il devient difficile de savoir qui l'accède quand et où. Si vous faites des données en tant que membre de CWinApp, vous pouvez y accéder via une fonction accesseur et en suivre l'accès (via les messages de logs, les points de rupture, ...). Cela atténue, à mon avis, la plupart des problèmes associés aux variables globales. Ce que je fais habituellement de nos jours est d'utiliser un singleton Loki.

La raison qui est indiquée dans votre message pour ne pas faire de données un membre de CWinApp, comme un problème de découplage, est (dans le contexte que vous l'avez présenté) un peu étrange imo. Si certaines classes ont besoin d'un accès, elles devront quand même connaître ces structures de données, et leur emplacement de stockage n'est pas pertinent. Peut-être que c'est juste parce que je ne connais pas les détails de votre conception.