best practices to make an app with a GUI?

Hello


What's the best way to create a complex application with a user interface?


Is it advised to create the GUI as the main part of the application, and let that GUI call other modules/executables to perform calculations? (the GUI will also be the central brain).


Or is it better to have a main executable module as simple as possible that call other modules, one of them being the GUI?


Or mix it alltogether in one single module? (I guess no)



For example I want to create an interactive rubik cube solver with graphic interface.
Using C++ and maybe Qt o wxWidgets or Ultimate++.

regards

Every designer, developer, or vendor of an application or GUI development framework has an opinion on this. And each claims their approach is superior to others (and, by extension) that other approaches are inferior.

Generally, I prefer something like "model-view-controller" architecture. The key is separation of concerns: the model looks after all logic that is GUI independent, the GUI logic is conceptually in two parts (one to contain information from the user and use it to manipulate the model, the other to retrieve updates from the model and use it to update information that is displayed to the user). Practically, it's a bit more that that, since some user interactions only affect the GUI itself, rather than the data it works with.

The advantage of separating concerns is that the "back end" (aka business logic) can be maintained separately from the "front end" (eg GUI). It also means that multiple GUIs can be used that each interact with one back end (eg distinct GUIs on different hardware platforms, each talking over a network to a shared server), and each GUI can be maintained separately. It doesn't matter whether the GUI and back end reside in one process, in separate DLLs, in separate processes, or even on separate machines (the only differences those aspects make is in how changes in one part of the system are managed).

The challenge, however, is that some vendors of GUI frameworks and some vendors of other frameworks (eg for accessing a database) design their frameworks assuming it will be the central crown jewel of the application, and therefore lock developers or end users into their favourite frameworks. That makes separation of concerns somewhat difficult, but it is possible (by taking time up front designing the GUI logic and the back-end logic with a view to keeping them separate, rather than just jumping in and coding).

Hello and thank you for your explanation.
Do you know of any document (web site or book chapter) describing more in detail how to do it?
What method would you use to communicate the different parts with each other? (shared memory, tcp...)
Do you advise to do it with different dlls?

Google is your friend, here. Search for "model view controller" will turn up useful pages.

You're premature in asking about how parts might communicate with each other, or using different DLLs. If you're worrying about that level of detail up front, you are going in completely the opposite direction to what I suggested.

Quote:

---

Originally Posted by grumpy

Google is your friend, here. Search for "model view controller" will turn up useful pages.

You're premature in asking about how parts might communicate with each other, or using different DLLs. If you're worrying about that level of detail up front, you are going in completely the opposite direction to what I suggested.

---

OK, thanks I've seen that there is a model view controller, presenter and viewmodel, I didn't know that names before. I'll read about it.

regards