[Qt-interest] question about mixing gui and non gui classess

[franki]

Monday 16 May 2011 22:05:43 Mihail Naydenov napisał(a):
> Your question is hardly Qt related, these are design/patterns questions :)

Sorry for that ;)

I have also application that acts as a server without GUI, also written in Qt, 
and I liked the idea of clean layout of classess. For example: server manages 
temperature and light in the building, it talks with microcontrolers and 
gets/receive commands from clients (gui clients application). In case of 
temperature the classess are as follow: 
Temperature - main class, retrives actual temperature from sensors, keeps 
rooms configuration - wheter they should be heated or cooled or not.
Heating - children of temperature responsible for keeping requested 
temperature for rooms, daily, weekly plans of temperature
Stove - children of Heating, responsible for checking temp diferences, 
radiators valves, etc. talks to device.
Clima - children of temperature same as for heating but during summer when 
instead of stove, air conditioning is working
ClimaDev - children of Clima responsible for talking to devices

Server is doing also other than temp related stuff, but in that layout things 
are clean: everything that is temp related goes to Temperature class, and 
inside it to Heating or Clima class, then inside lower classess commands for 
real devices are generated, and that's it.

I wanted to have similar setup in client application.
But my objects are created inside main GUI class (MainPages) so if I want to 
have every temp related stuff passed to Temperature class and inside it 
decided where, and how to display it I need to pass pointer to gui graphics 
to Temperature class and also classess like Heating and Clima and from them 
to 4 classess managing 4 pages of QStackedWidget.
I has becomed inclined to do it that way. I will still have worker classess 
like Temperature, Heating, Clima working only with data rooms, and sharing 
this data between 4 "gui" classess, and the gui classess will manage 
displaying it, I just need to pass gui pointer to them from the first 
MainPage class through Temperature, Heating, and create them as children of 
Heating instead of children of MainPages. 

I'm not a programmer, in fact this is my first application, maybe I'm just 
doing to much fuss about simple thing like passing this gui pointer to 
objects deeper into class hierarchy?

thanks for answering
Marek

>
> Anyways, first the generic answer - do the way that minimizes
> interdependency and maximizes specialization.
>
> It is hard to tell if your first solution is a bad one. It has many
> signals-slots but if these are not interdependent - like pure output
> communication from the 3 engines to the UI, I believe its fine. But if the
> 3 work classes are also linked to each other and depend on each others
> execution, well this could be messy, Is hard to tell from the outside...
> but may be then you can consider refactoring these into one engine object
> that uses a thread pool to do the work of the 3?
>
> Adding a mediator class Temperature that manges *both* UI and backend
> hardly solves anything IMOHO.
> You become dependent on this glue class, and the design is harder to
> change. If things need to be (or can be made) autonomous use signals and
> slots as much as possible.
>
> On the other hand, a class that wraps and aggregates some or all of the GUI
> or backend classes into one, manages these (calling functions on them,
> private even if needed) and then presents a simplified interface, I think
> it is worth it. The inner engines do their specialized work, with simple
> desing, not caring to present a full-featured interface, then an upper
> class, manages the mess of the engines communications, but containing no
> work-logic on its own, and presenting the simplest posible interface to the
> world. Same can be true for both UI and backend classes.
>
> So there you have it an opinion, mind you I am not a CS major :)
>
> MihailNaydenov
>
>
> ----- Original Message ----
>
> > From: franki <franki at franki.eu.org>
> > To: qt-interest <qt-interest at qt.nokia.com>
> > Sent: Mon, May 16, 2011 8:56:59 PM
> > Subject: [Qt-interest] question about mixing gui and non gui classess
> >
> > Hi all,
> >
> > I have app which communicates with server to display temperature  from
> > different devices. Question is how to lay out classess which interacts 
> > with GUI and classess responsible for holding/calculating data. Let's
> > say, I  have 4 pages (widgets of QStackedWidget), each page is separate
> > object (a  class) that displays data and interact with user, next there
> > are three  objects (different classess) that are holding data, and
> > exchanging it with  different QThread that is running network-manager to
> > get/send data from/to  server So far I have such a layout:
> >
> > MainPages: public QStackedWidget -  main class that has GUI pages,
> > inside this class four other gui classess are  created, and pointer for
> > managing gui widgets (UI::MainPages ui) is passed  to each class, each
> > class is responsible for one page of  QStackedWidget.
> > Apart from this, there are three objects that inherits  QObject (to be
> > able to
> >
> > send signals) also created inside MainPages class,  these just share and
> > calculate data received from server.
> > Now, when data  arrives from server it first goes to one of three
> > objects, it is calculated,  and then it goes to one or more "gui"
> > classess to display result.
> >
> > What is worrying me is that all these objects are not related  to each
> > other, thus all communication between them goes by signal-slot  solution.
> > I have more
> >
> > than 50 defined connections between these objects and  it looks like a
> > mess when I look at this.I would like to reorganize it in  such a way:
> >
> > MainPages - creates main Temperature class (pointer for gui  objects is
> > passed
> >
> > to that class), Temperature class creates "gui" classess  as a child
> > objects (again pointer for gui is passed), plus classes to  calculate
> > data received from network-manager are created as children of 
> > Temperature class. Now, lots of data I need to display (after calculation
> >  inside Temperature class) can be passed to "gui" classess by simple
> > function  calls, and I think it's simpler and more organized in that way.
> >
> > The  disadvantage of this approach (or at least I think so) is that I
> > need to pass pointer to gui elements from MainPages class deep inside
> > classess hierarchy, and to the classess that are only  responsible for 
> > calculating data received from network-manager.
> >
> > But should that ever  worry me?
> > What is "blessed" way of laying out objects that are gui  related
> > and these that are only calculating data? And is it safe to pass  pointer
> > for graphic elements deep inside class hierarchy?
> >
> > best  regards
> > Marek
> > _______________________________________________
> > Qt-interest  mailing list
> > Qt-interest at qt.nokia.com
> > http://lists.qt.nokia.com/mailman/listinfo/qt-interest