- Forum
- General C++ Programming
- How to separate GUI from the process?
How to separate GUI from the process?
Guys, I have a philosophical question: I am programming an application with GUI which one of these is the best option:
1. include the interface and the processes in one class.
2. include the processes in one class and add a member of the class type to the class of GUI (or vise versa)
3. create an abstract class for the GUI and then derive a class from it and write the processing parts?
Do you know which way is usually done? the first seems best to me, but what do we do when the program gets larger and we don't want to have everything in just one class?
1. include the interface and the processes in one class.
2. include the processes in one class and add a member of the class type to the class of GUI (or vise versa)
3. create an abstract class for the GUI and then derive a class from it and write the processing parts?
Do you know which way is usually done? the first seems best to me, but what do we do when the program gets larger and we don't want to have everything in just one class?
Usually, GUI libraries already exist, such as Qt or MFC. In real world, people use these, meaning they already have a separation between the GUI and whatever they want to do, and this usually works.
Now, what do people do after this? Wildly varied and largely dependent on preference. For example, I have a BHO (which I did not create, just maintain) that inherits from MFC classes and adds the specific functionality like this. Others would create worker classes as they see fit. It is a matter of what your criteria are. Example: I want maximum reusability of the worker code for other, future projects. Then maybe a fully separate class is best because maybe the next app won't have a GUI, maybe it will be a console app. It is all about YOUR requirements.
Now, what do people do after this? Wildly varied and largely dependent on preference. For example, I have a BHO (which I did not create, just maintain) that inherits from MFC classes and adds the specific functionality like this. Others would create worker classes as they see fit. It is a matter of what your criteria are. Example: I want maximum reusability of the worker code for other, future projects. Then maybe a fully separate class is best because maybe the next app won't have a GUI, maybe it will be a console app. It is all about YOUR requirements.
Topic archived. No new replies allowed.