Hello all, this question concerns how a certain app be built - generaly - using MFC. App's function: To analyze simple text files that are supposed to obey strict formatting rules and warn on any mistakes it finds in the files (such as wrong positioning, expecting to find a number but encoutering a letter instead... etc.) So far, a standard MDI app with the "formatting rules" hard-coded inside it would do. But - The "formatting rules" themselves are several, meaning for this file the app will operate one set of rules, and for that file - another. So, I wish the user to operate a different part of the app in order to create the rules himself. Granting an option for immediate changes, and future additions. This made me think of adding a dialog box to my MDI app, in which to include a special custom control for displaying/editing the "rules". What I noticed, and what got me wondering and questioning is that - The View that will be used to display/operate input for my original Doc (text file being analyzed) is quite similar to the View that this special custom control should have... ...In the way it will pick up the user's mouse clicks and map them, by their coordinates, to an object corresponding to the field of letters the user clicked on, and also shared OnDraw stuff. So, after looking up lotsa stuff, to the best of my beginner's understanding, I am faced with two options: 1) Have 2 Doc types, 2 Views and 2 Doc Templates, and let the 2 views derive from the same base view that will implement their shared behavior. Meaning that afterwards, in my "formatting rules" editing dialog box, I'll need a control that will display a View (which is not common practice, I gather, or is it?) 2) Have a custom control that will implement the 2 views' shared behavior, and derive it to a control in the dialog box and to a View as part of the MDI in order to display my analyzed text files (using CCtrlView). Both are a bit of a mystery to me, so I'd appriciate some advice, thoughts Thanks for whatever reply, or simply for reading up to here.
As I can see you are concentrating on the design of the application and if you use the inheritance you will always be making a tight couplong and so use the aggregation over inheritance. As I can understand you are looking for something where you have 2 screens where you see a control that has common behaviour and so put them in one class and derive from it but instead of that use some suitable design pattern to your problem. I have one article regarding it. Design pattern in simple examples. I think the best suited pattern will provide you better solution.
