Requesting help with class structures

glennib

Hi,

I'm trying to design a GUI which is supposed to communicate with some hardware that I'm making. The hardware is logging some data, can be controlled and read via Mavlink-messages. The structure is something like this: http://i.imgur.com/OXHBhWh.png.

What I'm having trouble with is how to divide the GUI into classes. I don't know how to do it "cleanly". I've designed a couple of GUIs before, and it ended up being messy, sort of like a card-house. Lots of dependencies up and down in the stack, which didn't scale well.

What I want the GUI to be able to do is:

read and control the hardware, via serial communication
log whatever's being read into a database
be easily expanded with additional data being sent/received to/from the hardware

What I need help with is this:

How do I most efficiently structure the classes so that point 3 is maintained? My initial thought is this: http://i.imgur.com/SbECvZ2.png, but it really doesn't look scalable. Is there any specific patterns I should use for this type of design?

Any help is appreciated. Thanks.

SGaist

Hi and welcome to devnet,

Does your GUI have anything to do with that database ?

As for the dependency problem, do you mean you have tight coupling issues with your software ?

glennib

@SGaist Thanks for your answer.

The database connected to the GUI should store the logged information.

The previous GUIs I have designed have what you're calling tight coupling issues yes. Essentially what I'm asking is how to think to avoid such issues with the GUI I'm making now.

Do you have any suggestions?

SGaist

The the first question, is it really the role of the GUI to store these information ?

One way to avoid thigh coupling is to write your classes so that they follow the Single Responsibility principle. e.g. your controller class should only provide the information that your GUI will use. It's not it's role to write a status information in your main window. It can make it available through a property but who makes use of this property is not of his concern.

glennib

So your suggestion is to make a controller which is a layer between the visual elements and the data and communication?

Thanks for your advice.

SGaist

That's one way yes. Having a clean separation between both will allow you to easily change your GUI. For example change from widgets to QML.