«

On 2008-06-29 17:45, Stefan Ram wrote:
> Gunter Schelfhout <> 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 disagree, for the same reason. Nobody is perfect and once things work
it is all to easy to not refactor the code just to get a better design.
Write code with good separation from the beginning and then refactor the
interfaces between modules if needed. Also, this way you will keep the
"dirty" pieces of code well contained from other modules and you can
focus on one module at a time.

While I do agree that you should stop developing every once in a while
and take some time to clean up the code it might not always be possible
(while it is short-sighted many companies do not care about refactoring
until they absolutely have to). I believe in trying to get as good
design as possible from the beginning, since it (usually) keeps down the
decay-rate of the code. Of course, if you have good processes then it is
less of a problem.

--
Erik Wikström

On 2008-06-29 17:38, Juha Nieminen wrote:
> 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.

On the other hand, in these kinds of applications the GUI code is
usually a very large percentage of the whole application, if you ever
want to change GUI framework it will take a lot of work regardless of
how abstract your logic code is. When creating those kinds of
applications you really do not want to select the wrong framework,
because you'll gonna have to live with it for a long time.

--
Erik Wikström

Juha Nieminen <> writes:
>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.

In this case, the UI-dependent part of the program is large
and the UI-independent part of the program is small or missing.
Sometimes it happens to be this way, and then a port to another
GUI library will nearly be a complete rewrite. I do not see
any other solution for this case than to live (cope) with it.

A indication of such a type of program might be that it can
not be ported to some kinds of environment at all. For example,
when the definition of a program includes »drawing with the
mouse«, it will not be possible to port it to a keyboard
interface by its definition.

On Jun 29, 6:04 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
> >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.

> In this case, the UI-dependent part of the program is large
> and the UI-independent part of the program is small or missing.
> Sometimes it happens to be this way, and then a port to another
> GUI library will nearly be a complete rewrite. I do not see
> any other solution for this case than to live (cope) with it.

> A indication of such a type of program might be that it can
> not be ported to some kinds of environment at all. For example,
> when the definition of a program includes »drawing with the
> mouse«, it will not be possible to port it to a keyboard
> interface by its definition.

This sounds like the old lightweight client vs. heavyweight
client dicotomy. Looking at the larger picture: at least in
business applications (but also in some of the process control
work I've done as well), there is a large body of "business
logic" (or application logic, if the application isn't
business), which can (and definitely should) be completely
separated from the GUI. In the lightweight client model, it is
so completely separated that it runs in a different program,
often on a different system. In which case, of course, the
client is almost pure GUI.

Regardless of where it is located, I would keep this business
logic completely separate from the GUI. In most cases, the GUI
itself will use some variant of MVC, in which the "model" serves
as a bridge between the GUI and the business logic (and doesn't
implement any of the business logic itself). (It's not all that
unreasonble to have the business logic run in a separate
process, even if it is on the same machine.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34