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