Structure of a single document
I already asked about the correct way to access member variables present in a project. In a project I have a CWinapp derived class, a CMainFrm class, a list of different view classes. However, I currently have instances of different custom classes created in the CWinApp class, while the rest of the classes use the pointer obtained from the AfxGetApp () function and then access the different custom classes. I was told by some community members on the MFC newsgroup that this is very bad design (i.e. the parent should know nothing about the application class, view class, or document class). However, I'm not sure how else I can access the various custom classes without using this design. It would be great to hear some suggestions,as I am not familiar with MFC well enough to find suitable search terms.
a source to share
"(ie the parent should know nothing about the application class, view class, or document class)"
I'm not sure I understand this sentence, what do you mean here with the parent?
In any case, in my opinion, the design you are describing is not really a problem. It's a tradeoff: do you either loop through these classes to all the functions they need, making them harder to use and API, or store them as some sort of global variables, as you do? It depends on the data being accessed and how often. Data that is needed in many places can also be "global".
There are several ways to make data global: make it a member of CWinApp (ie your CWinApp derived class) or CMainFrame, or make the actual "global variable", or you make a singleton, ...
The problem with globals is that it becomes difficult to determine who gets it, when, and from where. If you are a member of CWinApp, you can access it through an accessor function and track access from there (through log messages, breakpoint, ...) This, in my opinion, mitigates most of the problems with global variables. What I usually do at the moment is to use a single Loki single.
The reason the post says you don't make the data a member of the CWinApp as a decoupling issue is (in the context you presented it in) a bit odd. If some classes need access, they will still need these data structures, and their storage location does not matter. Maybe it's just because I don't know about the specifics of your design.
a source to share