I want to develop a MFC application in VS2010. I hope to separate GUI from the logic, so that modifying GUI can become much easier. But I don't know how to design the classes to implement this function. Which design pattern should I use? Does MFC have any special way to deal with the problem?
Moreover, I am not familiar with design patterns. So I hope someone can give me samples or detailed articles explaining this. (Also I prefer a less complicated pattern! ^^)
Thank you very much!
The MFC already provide such a separation in their SDI/MDI based templates. For example, you have a CWinApp instance and a CMainFrame for the program itself. For each file in MDI apps you have a CDocument and a CView class.
Note:
The MFC don't use the classic MVC separation, they combine the view and controller into a single UI part.
The MFC are not strict about this, you can also put a button handler into the application/document, not only into the frame/view.
You don't fully separate the model from the MFC, it is still built on that. If you want to achieve this separation, you have to do additional work, but then you have a module that you can test completely separately. This allows you to use test-driven development, which is more difficult when embedded into a GUI.
May be it will be helpful http://martinfowler.com/eaaDev/uiArchs.html . Also try to find MVC (model/view/controller) pattern.
Related
I'm creating one tab based C++ application using GTK+ toolkit and Webkit for learning purpose. I've created following files
Main.cpp => Application entry-point
MainWindow.cpp/.h => MainWindow which creates toolbar object, Notebook, Statusbar
Toolbar.cpp/.h => toolbar items like back, forward, urlbar, stop/refresh,
NotebookContainer.cpp/.h => for creating new tab etc
TabWebView.cpp/.h => for creating tab(label+close button), web-view etc.
Now I want to communicate in between toolbar and TabView class. So when any event occur on toolbar I can do the action in webview.cpp and some event trigger from webview I can do the required on toolbar (like enabling/disabling stop button)
Which design pattern should I need to follow in this scenario?
NOTE: GTK+ is c based library.
I would like to suggest that you are asking the wrong question. Rather than asking what design pattern to follow, I would suggest you ask what the most idiomatic way to solve your problem is.
All too often the wors design failures I have to fix come from a young coder whose approach is "what design pattern can I use here?", or "How can I use more design patterns".
Studying design patterns is useful in providing a vocabulary for discussing your designs, and they are useful in inspiring and informing your design choices, but your design approach should always be "what the simplest, cleanest, most effective, idiomatic approach here". Sometimes the answer to that question will be a design pattern. Sometimes it will a part of a design pattern, and sometimes it will be something much simpler -- typically an idiom in the language or library you are working with.
I don't do a lot of GUI programming, so I can't help much with your concrete question. For the problem you are presenting, it sounds like you want to use GTK's signal/slot framework. Alternatively boost offers similar functionality if you want to get familiar with boost's tools. Both would be idiomatic approaches to what you want to do.
I think what you are looking for is some along the lines of an observer pattern:
http://sourcemaking.com/design_patterns/observer
and more generally something like Model-View-Controller or Presentation-Abstraction-Control models:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control
You might want to have a look at the Qt Signal/Slot implementation also:
http://qt-project.org/doc/qt-4.8/signalsandslots.html
I have a phone-book program written in C++, that uses the MVC model, now what I want is to replace the View component, that's basically the console window, with an MFC. How would I do that?
Following is a schematic representation of MVC. View component is lossely coupled from the Model and the Controller and that is the whole point behind MVC design pattern. Without changing the external interfaces of View, you should be easily able to replace internal implementation by MFC. And that is what you should do.
The question is very broad to answer anything more in detail, If you can post a sample code then probably we can help you better.
I am wondering which way is the best to start building a GUI+SOFT in Qt. I am trying to build a sound media player based on a MVC pattern. Until now i have found 3 ways to do so.
1- Should I use a .ui file thanks to Qt designer, is it flexible enough ?
2- Should I use QML to make the design than integrate it to a C++ development ?
3- Should I just start from scratch and do it by hand without Qt Designer and using Qt library ?
Thank you very much for your answers.
NOTE: I'm using PyQt, so my comment may not be the most relevant.
I found Qt Designer to be great to create UIs, but then, when comes the time to modify them later, it becomes somewhat of a problem. Inserting new elements in an existing layout is often tricky, and you have to break all your layouts and re-assemble them (hoping you didn't mess anything up). Moreover, if your app is not trivial, you'll likely end up with code "fixing" what the .ui can't do. There are other tricky cases like that, but I don't remember them right now.
I ended up getting rid of my .ui files. So what I'd recommend is to initially use the designer to create the UI, and then use only the generated code from that point forward.
If you want your UI to be animated and it is not a requirement to follow platform UI appearance, QML is by far the best way to achieve this. If you want a UI that appears like any other application on your system and has limited animation then stick with QtDesigner and standard widgets.
I prefer building UI completely from scratch. This gives a lot of flexibility and better understanding of what is where, but on the other hand changing layout sometimes is a big headache.
I would use Qt Designer, as this is the easiest method IMHO.
how are the classses in MFC match the model-view-control pattern ?
the model is suppose to handle the Business Logic , the control suppose to be some kind of mediator and the view suppose to be the gui ?
what class in MFC represent each one ? cause it seems pretty different to me as i read more about mfc. (seems like CView represent the control, CfrmWnd the view , and CDocumnet the data- though i'm not sure if by data they mean BL)
clarifications ?
MFC is a Document/View architecture, not a full-blown MVC. Reference MFC Library Reference
Document/View Architecture.
In short in MFC the CDocument is the Model, and the CView classes combine the View and Controller aspects.
By "BL" in your question do you mean "business logic"? And in this case the CDocument does not mean business logic, but the actual data underlying your app.
MFC does not implement the MVC pattern. However, there are ways to integrate MVC with MFC.
MVC is to desktop widget libraries like the ISO OSI model is to the internet protocols. It just does not fit because it is too rigid.
I don't think a single pattern exists that describes MFC (or desktop GUI programming in general) well. Maybe the hierarchical Model-View-Presenter is a good approximation.
Why should I choose to use one instead of the other and in which cases?
I mainly focus on desktop applications and personally speaking I do find the humble dialog box more easy and natural to use.
In MVC, you would still use your "humble" dialog. Except all the business logic for it would be farmed off to another class somewhere else.
http://en.wikipedia.org/wiki/Model-view-controller
You need to weight up whether the investment in MVC will be worth it - especially if you're only working with a single simple dialog.
One of the best discussions I've found regarding the advantages and disadvantages of the model view controller/presenter patterns was written by Martin Fowler: http://martinfowler.com/eaaDev/uiArchs.html
In short, by choosing to use a MVC variant you are increasing the testability of your view (dialog). Keeping all of your logic in your dialog class on the other hand, can be fine if you do not expect that dialog to be very complex, however as the complexity increases, the benefit of testable code increases.
It really is a judgement call.
"Humble" dialogs themselves are already MVC. You have:
M, The content of the dialog's message.
V, The window and widgets the user can see.
C, How the dialog is displayed and how it responds to user activity.
Your GUI framework or wrapper library can provide MVC for you seamlessly without you having to think about it, but it's still MVC.
There is no simple answer.
You should use whatever will make your life easier.
If dialog is really simple, and you know for sure it is going to stay that way, go with humble dialog.
If you have something more complex, like multiple view presentations of the same data, or you know your simple dialog will become more complex over time, then, by all means, use MVC.
You can also take a look ant MVP pattern as an alternative to MVC.