Reputation: 689
I am designing an application that should work as GUI or console (command line) app. One mode at a time. When application will be compiled as console it should not use any GUI libraries. As I am doing such thing for the first time, I would like to ask about pitfalls, tips and tricks for such case. What approach wolud be the best? Simply use macros like #define withGUI 1
to switch? Or to make something like client/server solution?
Upvotes: 4
Views: 485
Reputation: 27611
There is a design pattern for this called Model View Controller (MVC). This separates the presentation of data from the model of data itself, with a controller acting as a delegate and controlling the update of the view with updates to the model.
Qt provides a similar system, but just uses the model and view.
The main point to focus on here is the separation of the model of your data from its visual representation. Get that right and it will be simple to maintain both a GUI and console version of your application.
With signals and slots, it's quite simple; any changes made by the view (either GUI or command line) causes a signal to be picked up by the model. Likewise, when data in the model changes, emit signals for the connected view to update its representation of that data.
Upvotes: 3
Reputation: 21220
I would completely separate the business logic and the GUI into the stand alone libraries - one for each. In case of the console application mode I will link to the only library that contains the logical part and to both libraries otherwise. With this you will not need to put #ifdef-s everywhere in your code and make it hard to read.
Upvotes: 2