Handle communication in multi layer application

Question

I am creating an application using Python.

I first designed an API, that is working fine. I am now designing my GUI. The GUI starts a Thread that is used to perform tasks against the API.

Up to now, I used the Observer pattern to handle communication through the different layers. Basically, communication can be of two types (mainly): - The GUI asking the Thread (and the API subsequently) to START/STOP - The API giving information back to the Thread, that propagates to the GUI.

Here is a simple schema of the current architecture I am talking about. One arrow means "notify", basically.

My concern is that when the application Thread communicates, both the Gui and the API receive the message because they subscribed. Thing is, each message is only meant to be read by one of the two.

What I did to solve that is to send an message together with an ID. Each of the three elements have an id and they know whether the message is for them or now. But I am not sure if this is the "correct" (understand nicest) way to do it. What if I have more parties in the future ?

I started thinking about some kind of manager handling communication, but It would then have to be at the top of the architecture, and I am not sure how to further organize it :s.

I am not asking for a complete solution, but mainly ideas or best practises by more experienced people ;)

I can keep handling multiple Observer pattern in this simple case. But I was thinking about porting my code on a server. In this case, I am likely to have way more than one thread for the application, and handling API calls will become quite impossible.

Link to the code I am talking about : GUI, ApplicationThread and Application API.

You want to look at notify and update methods.

Thx for any piece of advice !

Answer 1

One of the nice implementation of the observer pattern I've met is the signal/slot system in Qt. Objects have signals, and slots (which are actually methods) can be connected to signals. The connected slots are called when the signals are emitted.

It seems to me that some of your problems may stem from the fact you have single communication canal in each of your objects. This forces you to have some dispatch mechanism in every update method, and makes the code quite complex.

Taking inspiration from Qt, you could have different signals for each kind of message and recipient. The code for signal would look like :

class Signal:
    def __init__(self):
        self.subs = []

    def subscribe(self, s):
        self.subs.append(s)

    def signal(self, *args, **kwargs):
        for s in self.subs:
            s(*args, **kwargs)

---

For example, the gui would have a signal stop_signal and the thread a method to handle it :

def handle_gui_stop(self):
    self.console_logger.debug("Facemovie is going to stop")
    self.my_logger.debug("Facemovie is going to stop")
    self.stop_process = True
    # ...

Somewhere in the initialization code, we would tie everything together :

gui.stop_signal.subscribe(thread.handle_gui_stop)

Answer 2

I recently created a GUI app with similar architecture (GUI thread + a separate work thread), and I end up creating an explicit protocol between threads, in a form of two queues (from Queue Python module). One queue is for requests made by GUI and is consumed by worker thread(s). The other queue is for answers produces by worker threads and consumed by GUI.

I find it much clearer when communication between threads is explicit, you have full control over when and where the updating is done (GUI methods can be called only from the GUI thread).

A natural extension of this model in a server environment is a message queue protocol like AMQP.