Separation of logic and UI

There are several ways of doing this so your question is valid.

  1. Your GUI class can be derived from your logic class. Not the typical approach but it depends on how your application is designed. One major drawback is that the GUI would have to stay in the same thread as logic if you don't want to involve locking-mechanisms in your logic class. Often you want two objects to run in separate threads such that heavy computation does not freeze the GUI (see Qt's QObject thread affinity).

  2. Your GUI class can hold a pointer to your logic class and/or vice-versa. It may also be a reference for convenience if your logic class exists before the GUI class and survives it. Then you can pass the reference to the constructor of the GUI class and you never have to test whether a pointer is valid.

  3. Your GUI class can access data members via getters/setters or directly, if you want to make them public or simply define your GUI class as a friend class to the Logic class. Even if you use getters, they can return const references, so no copy involved. Qt classes like QStringList also have their own reference counting, copy-on-write mechanism that avoids copies.

  4. Your GUI class can emit signals and the Logic class can receive them. See Qt signal/slot mechanism. It is very nice for events like a "Start computation" button. Signals have two advantages: (a) they can go across threads, however if the receiver is not the main loop it gets a little bit more tricky; (b) the objects don't have to see each other (no pointer passing), you can connect the signals to slots anywhere in your program where you have see both objects at once.

Typically you will use a mixture of 2 and 3: Use getters to read the data from Logic class that is presented to the user. Use Signals to provoke action or manipulate data (user makes a choice, Logic class has to react).


Maybe I'm missing something here but simply inject your data class into the UI class via a setter and expose the data class' method as public. You only need to pass a pointer of your data class to avoid any coping overhead.


There is a programming model called MVC (Model - View - Control)

For simple cases, just Model - View is enough. Model represents data, and View represents UI.

Model class exposes some interfaces set/get data. Model class usually has no knowledge about View class, but it usually can notify the View class when the data changes (this can be done using the signal/slot in Qt).

View class holds an pointer to the Model class, and use the interfaces Model class provides to manipulate the data.