Designing lower level classes.
 

I'm starting to write a QT-program on Linux but I'm not very experienced
yet. (hang on, it will be on topic)
What is the best way to go to design the lower level classes?
Should I use the standard libraries as much as possible so I can reuse the
classes maybe in the future in non-GUI programs?
Or is it best to use as much of the QT-libraries from the beginning?
For example string <-> QString.

Re: Designing lower level classes.
 

On 2008-06-29 14:15, Gunter Schelfhout wrote:
> I'm starting to write a QT-program on Linux but I'm not very experienced
> yet. (hang on, it will be on topic)
> What is the best way to go to design the lower level classes?
> Should I use the standard libraries as much as possible so I can reuse the
> classes maybe in the future in non-GUI programs?
> Or is it best to use as much of the QT-libraries from the beginning?
> For example string <-> QString.

My advice, for any non-trivial application, is to divide the code into
(at least) two parts: one for the "business" logic and one for
interfacing with the application (be it a GUI, command line, or
something else). In the business logic part I would advice against using
more dependencies than necessary to keep the code as portable as
possible, but if a specific library does exactly what you need then use
it. You might also consider putting the lower layers in one or more
libraries which makes it even easier to change to GUI later on.

--
Erik Wikström

Re: Designing lower level classes.
 

Gunter Schelfhout wrote:
> I'm starting to write a QT-program on Linux but I'm not very experienced
> yet. (hang on, it will be on topic)
> What is the best way to go to design the lower level classes?
> Should I use the standard libraries as much as possible so I can reuse the
> classes maybe in the future in non-GUI programs?
> Or is it best to use as much of the QT-libraries from the beginning?
> For example string <-> QString.

My personal experience on using GUI libraries is that you should,
obviously, separate what all the functionalities of the program which
you can into their own portable modules (this is rather obvious for the
simple reason that it's good OOD), but trying to abstract away the
non-standard GUI library completely from your program is usually more
trouble than it's worth.

I once tried this, and the results were less than satisfactory. My
intention was to make a clean abstraction of the underlying GUI library,
ie. hide everything in it inside its own module in a way that would
allow me to change the underlying GUI library easily to something else
(eg. from gtk to wxwidgets or to qt or to native Windows API or whatever).

While this sounds like a great idea in theory (and it still is), in
practice the whole system became awkward, limited and hard to maintain
and expand. At one point I simply noticed that I was basically
replicating the underlying GUI public interface in my own "abstract"
module. While I got something working, in the end I was not very
satisfied with the result. (And, rather ironically, the underlying GUI
library was never changed to anything else, so all that abstracting
basically went to waste.)

Sure, liberally using the GUI library everywhere in your code will tie
your code to that library in question, but whether that's better or
worse than the alternative is not clear at all. In some cases a clever
design could allow a clean abstraction between your code and the
library, but it's not easy.

Re: Designing lower level classes.
 

Juha Nieminen wrote:

[snip]

>
> Sure, liberally using the GUI library everywhere in your code will tie
> your code to that library in question, but whether that's better or
> worse than the alternative is not clear at all. In some cases a clever
> design could allow a clean abstraction between your code and the
> library, but it's not easy.


I'm sure I'm not the only beginner facing this question and the most books
handle the technicalities of the language well but don't give any info like
this.
Probably this info will be in other more general progamming books I suppose?
I noticed the book 'Large scale programs with C++' or something from Addison
Wesley. I will look for a review. Maybe this is just the book I need for
questions like this.

Anyway, thanks a lot. It gives me something to think about.

Re: Designing lower level classes.
 

Juha Nieminen <nospam@thanks.invalid> writes:
>simple reason that it's good OOD), but trying to abstract away the
>non-standard GUI library completely from your program is usually more

This usually will not work, because the GUI library often uses
callbacks or acts as a framework and by this it enforces a
specific structure of the high level code of the application,
and different GUI libraries indeed have different APIs,
because.

Separation still is possible, but just the other way around:
You abstract away every part of your program that is not
directly related to the user interface - but »abstract« now
is the wrong verb: You stash it away in a »model« and a
non-UI-related library to the maximum extend possible.

What is left over is a program that solely consists of UI
related parts (view and controller). This might be a text
console UI or a GUI. Now, this UI needs to be written for
every type of UI library used: For example, once for a console
library, once for GTK, once for WxWidgets, and so on. It is
the rest that cannot be abstract from the UI, because
everything else already has been stashed away in the model or
a non-UI-related library.

What is won by this approach is that the code for the model
and in the non-UI-related library does not have to be changed,
when writing the controller and view for a annother UI.

Re: Designing lower level classes.
 

On 2008-06-29 16:43, Stefan Ram wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>>simple reason that it's good OOD), but trying to abstract away the
>>non-standard GUI library completely from your program is usually more
>
> This usually will not work, because the GUI library often uses
> callbacks or acts as a framework and by this it enforces a
> specific structure of the high level code of the application,
> and different GUI libraries indeed have different APIs,
> because.
>
> Separation still is possible, but just the other way around:
> You abstract away every part of your program that is not
> directly related to the user interface - but »abstract« now
> is the wrong verb: You stash it away in a »model« and a
> non-UI-related library to the maximum extend possible.
>
> What is left over is a program that solely consists of UI
> related parts (view and controller). This might be a text
> console UI or a GUI. Now, this UI needs to be written for
> every type of UI library used: For example, once for a console
> library, once for GTK, once for WxWidgets, and so on. It is
> the rest that cannot be abstract from the UI, because
> everything else already has been stashed away in the model or
> a non-UI-related library.
>
> What is won by this approach is that the code for the model
> and in the non-UI-related library does not have to be changed,
> when writing the controller and view for a annother UI.

And if you ever want to incorporate the functionality of the application
in some other, bigger, application you just have to include the module/
link to the library. Even better, if you do create a separate library
and use a pure C interface, you can often use the module from other
programming languages.

--
Erik Wikström

Re: Designing lower level classes.
 

Stefan Ram wrote:

[snip]

>
> What is won by this approach is that the code for the model
> and in the non-UI-related library does not have to be changed,
> when writing the controller and view for a annother UI.

Ok, since I am still in the design phase, it's probably better to keep
things separated as much as I can.
I'm glad I asked because on the IRC-channel of qt, people advised the
complete opposite.

Somebody who has good books of software design in his library which are
worth reading?

Re: Designing lower level classes.
 

Stefan Ram wrote:
> Separation still is possible, but just the other way around:
> You abstract away every part of your program that is not
> directly related to the user interface - but »abstract« now
> is the wrong verb: You stash it away in a »model« and a
> non-UI-related library to the maximum extend possible.

This is a good design, but possible (or, more precisely, feasible)
only if the core code of your program is not heavily dependent on the
GUI itself.

I have used this design myself many times. The typical situation is a
program which reads some input data, performs some lengthy and heavy
calculations/processing on it, and outputs the results to a file. The
core implementation (including I/O and the calculations) is easy to put
into its own separate module, and then it's easy to create a
command-line interface as well as a GUI application (using whichever
library) which uses this module in question. (Perhaps the thing which
needs the most careful design is how to pass the user-defined options
from the UI to the module.)

However, not all programs are like that. Many programs require, for
example, user input in real-time (such as mouse and keyboard events),
drawing things on screen, update some GUI elements (such as the value of
some spinbutton) and other such GUI-dependent functionalities. This is
where abstracting the core code from the GUI becomes laborious, if not
outright unfeasible.

Re: Designing lower level classes.
 

Gunter Schelfhout <no.mail@please.com.invalid> writes:
>Ok, since I am still in the design phase, it's probably better to keep
>things separated as much as I can.

It is not even required to keep it separated right from the
start.

You also can have some »dirty« code parts in the first version
where data processing and UI interface code is mixed and
refactor it later to get the separation. Not everyone is so
perfect that he can write it all separated from the start.

Between sessions of coding to extend the set of features,
there always should be sessions to improve the quality of the
code without adding new features. Nobody can write everything
in the best possible way the first time. But one will
eventually not be able to maintain the code anymore if one
never refactors it to improve separation of responsibilities.

Re: Designing lower level classes.
 

Stefan Ram wrote:

> Gunter Schelfhout <no.mail@please.com.invalid> writes:
>>Ok, since I am still in the design phase, it's probably better to keep
>>things separated as much as I can.
>
> It is not even required to keep it separated right from the
> start.
>
> You also can have some »dirty« code parts in the first version
> where data processing and UI interface code is mixed and
> refactor it later to get the separation. Not everyone is so
> perfect that he can write it all separated from the start.
>
> Between sessions of coding to extend the set of features,
> there always should be sessions to improve the quality of the
> code without adding new features. Nobody can write everything
> in the best possible way the first time. But one will
> eventually not be able to maintain the code anymore if one
> never refactors it to improve separation of responsibilities.

I agree, but this is imho one of the decisions which are almost impossible
to switch back later on since a complete refacturing is then needed which
I'm trying to avoid.
So it's probably advisable to keep the the core classes as much as possible
independant of the GUI (and there libraries) and if nescessary, to provide
an extra layer to glue the core with the GUI.

I found out that between learning the technicalities and writing a program,
there is al lot more to discover. ;-)