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