Re: Designing lower level classes.
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 =BBdrawing with the
mouse=AB, 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:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34