Hello!
I came from Web-development, and encountered some design problems.
For example, in Symfony2 framework I has one controller for one action, that have access to service container, that holds services, such as templator, database, emailing and other.
When I start to write programm in C++ with WxWidgets, I noticed, that there is much more objects, that can't interpreter as services.
I have main frame, config dialog, tray icon and other. And each of them call methods for each other too many times. So, i need to write service class for each of this kind of objects, or write one, that have controlls to all of this classes and use it, or whatever?
Now I have this design:
Main Application class has timer, on that he calls HttpClient and get info from it. If App encoundered error, he calls ErrorHandler, that calls Main frame to set visual error state. If there is no error - App calls Main Frame to show new info, that comes from HttpClient.
Config Dialog into OnOk handler calls App to update info, and things are run again in the same order as above.
Spaghetti, spaghetti code! Can't test, can't understand where is what happens.
Can you give me advice on this? How do you solve such class dependencies on each other?
Architecture problems with C++
-
tierra
- Site Admin
- Posts: 1355
- Joined: Sun Aug 29, 2004 7:14 pm
- Location: Salt Lake City, Utah, USA
- Contact:
Re: Architecture problems with C++
Coming from an MVC-based framework, this concept should actually be a little easier for you to wrap your mind around...
Try to think of each of your frames and dialogs as a view. Your timer is actually a service itself. Your views (i.e. each frame, dialog, window, control, etc) need to subscribe themselves as event handlers to your timer. If the user closes a frame, it can unbind it's event handler, and your timer goes on about it's business without any issues, and can continue to notify other parts of your application about events.
So, you can either re-use wxTimer's built-in events for this, and each frame can bind to the timer's event handler, or create your own custom event specifically for this purpose, and trigger it from Notify(). Taking this approach with any other services in your application can help decouple class dependencies quite a bit. Also take a look into using wxUpdateUIEvent for updates to menus and toolbars.
In general, it's worth noting that wxWidgets isn't a "framework", it's a "library" or "toolkit". You're free to use any application architecture you wish (including your own MVC design), as opposed to being mostly locked in to one specific way of implementing everything like most web frameworks encourage.
Try to think of each of your frames and dialogs as a view. Your timer is actually a service itself. Your views (i.e. each frame, dialog, window, control, etc) need to subscribe themselves as event handlers to your timer. If the user closes a frame, it can unbind it's event handler, and your timer goes on about it's business without any issues, and can continue to notify other parts of your application about events.
So, you can either re-use wxTimer's built-in events for this, and each frame can bind to the timer's event handler, or create your own custom event specifically for this purpose, and trigger it from Notify(). Taking this approach with any other services in your application can help decouple class dependencies quite a bit. Also take a look into using wxUpdateUIEvent for updates to menus and toolbars.
In general, it's worth noting that wxWidgets isn't a "framework", it's a "library" or "toolkit". You're free to use any application architecture you wish (including your own MVC design), as opposed to being mostly locked in to one specific way of implementing everything like most web frameworks encourage.