4

I am writing a finite state machine in C++, designed as a library. Furthermore, I have a GUI implemented as a separate project which needs to update the user interface according to state changes happening in the library.

The way I implement the communication now, is that the GUI is calling a library function which returns a struct containing information about the state of the finite state machine (and other necessary information).

But I find this a rather ad-hoc solution and since it seems like a frequent situation, I am curious to know if there is a design pattern / text book way of handling this.

Improve this question
2
  • Though I support @ratchet's answer I still recommend you to go through State pattern explained in the book Design patterns by GOF(Gang of Four) – siva Jun 24 '15 at 17:01
  • @7383 Well I am actually using the state pattern internally in the FSM, but how would this help me notifying the GUI? You mean that the GUI provides a callback function which is called in every state(change)? – user695652 Jun 25 '15 at 14:00
5

Simplest method is to pass a callback function to the state machine that gets called when a state changes (or other event happens).

Then when it gets called you can update the gui in that function (or forward the message to the gui thread if the state machine runs in a separate thread).

The signature would be something like void callback(State oldstate, State newstate, void* userData)

the userData pointer is supplied at the same time as the function pointer and provides a context for the (static) callback function. If you want you can also use a std::Function instead and keep the function pointer+userData method as overload.

Improve this answer
2

GUI libraries (like for example Qt) are using some kind of subscriber-publisher design pattern, which is event based. That means, on an event, all subscribers are going to be notified.

So, on a state change, publish the event. Every object that subscribed to the event, is going to execute a callback.

Improve this answer
2

I think Observer Pattern is a simple and clean solution to update your GUI.

It is a behaviour pattern that allows you to implement an event like system. It will keep your GUI nicely decoupled from your library.

I normally use it in conjunction with an Adapter pattern in other to decouple the concrete "update" implementation from my main Entity. This way I can mix and match different update behaviours without having to inherit from IObserver

https://en.wikipedia.org/?title=Observer_pattern

The advantage over the "callback" implementation would be that:

  • it is possible to have multiple of observers that get notified, each responding in a different way
  • the class that started the operation can be different from the class that reacts, thus implementing the model-view-controller paradigm.
  • You can implement different lists for different events allowing the Observers to pick to what to react too

You can for example, use it to update your GUI, log to a file and something else, all of these in separated threads

Improve this answer
3
  • I am not sure if the Observer pattern is a good solution here, because it induces a pretty tight coupling between library and GUI – user695652 Jun 24 '15 at 14:18
  • @user695652 not really, the callback function in my answer is an example of the observer pattern (if you squint a bit). All the patterns means is that there is a interface in the library that the gui implements and passes to the library to get called. – ratchet freak Jun 24 '15 at 17:21
  • @user695652 i am sorry, i am not able to identify the tight coupling that you mention. Would you kindly elaborate ? I normally use the interfaces IObserver and IObservable in conjuction with Adapter patterns. My c++ is a bit rusty so i cannot supply a code example, sorry – eviloop Jun 24 '15 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.