Re: Relationship between GUI and logic?

[Matthew Woodcraft]

John Salerno <johnjsal@gmail NOSPAM.comwrote :

Basically, the question is this: can you write the logic behind a
program (whether it be a game, an email client, a text editor, etc.)
without having any idea of how you will implement the GUI?

You probably could, but it's best not to unless you're somehow forced
to.

In practice, the interface that you want your 'logic' layer to provide
to the GUI is likely to depend on some of the details of how the GUI
works.

If you did the lower levels first without having any idea at all of
what you were going to do with the GUI, it's quite likely that you'd
find you'd written a few functions which turned out not to be needed at
all, or that some functionality that the GUI needs to use very
frequently is rather slow to execute, or that some functionality that
you thought belonged to the 'logic' is really better done in the GUI
layer, and so on and so forth.

For example, if you were writing the 'logic' for a chess program you
might choose a way of modelling the board that can't represent a
position with more than one black king. And then when you got round to
doing the GUI you might find out that your users would like to be able
to have this temporarily when setting up a position.

-M-

[David C. Ullrich]

Re: Relationship between GUI and logic?

On 23 May 2008 18:23:04 +0100 (BST), Matthew Woodcraft
<mattheww@chiar k.greenend.org. ukwrote:

>John Salerno <johnjsal@gmail NOSPAM.comwrote :

>Basically, the question is this: can you write the logic behind a
>program (whether it be a game, an email client, a text editor, etc.)
>without having any idea of how you will implement the GUI?

>
>You probably could, but it's best not to unless you're somehow forced
>to.
>
>In practice, the interface that you want your 'logic' layer to provide
>to the GUI is likely to depend on some of the details of how the GUI
>works.
>
>If you did the lower levels first without having any idea at all of
>what you were going to do with the GUI, it's quite likely that you'd
>find you'd written a few functions which turned out not to be needed at
>all, or that some functionality that the GUI needs to use very
>frequently is rather slow to execute, or that some functionality that
>you thought belonged to the 'logic' is really better done in the GUI
>layer, and so on and so forth.
>
>For example, if you were writing the 'logic' for a chess program you
>might choose a way of modelling the board that can't represent a
>position with more than one black king. And then when you got round to
>doing the GUI you might find out that your users would like to be able
>to have this temporarily when setting up a position.

What you say may be true, but this doesn't seem to me like a good
example. Not that I see _why_ the player would want to have
two kings temporarily, but if so I wouldn't have the view report
this state to the model, I'd have the view wait until the player had
decided on the final configuration betore saying anything to the
model. The model should only deal with legal positions.

(Could be that it's not until we start actually playing the game
through the GUI that we find the model can't deal with two
black queens. But that's not an example either, that would just
mean the model is wrong, not allowing every legal position.)

>-M-

David C. Ullrich

[Matthew Woodcraft]

Re: Relationship between GUI and logic?

David C. Ullrich <dullrich@spryn et.comwrote:

Matthew Woodcraft <mattheww@chiar k.greenend.org. ukwrote:

>For example, if you were writing the 'logic' for a chess program you
>might choose a way of modelling the board that can't represent a
>position with more than one black king. And then when you got round
>to doing the GUI you might find out that your users would like to be
>able to have this temporarily when setting up a position.

What you say may be true, but this doesn't seem to me like a good
example. Not that I see _why_ the player would want to have two kings
temporarily, but if so I wouldn't have the view report this state to
the model, I'd have the view wait until the player had decided on the
final configuration betore saying anything to the model. The model
should only deal with legal positions.

Then you end up implementing a second model of the board state in the UI
layer. And if it turns out that you want to support things like 'save
current position' and 'clone current position to a new window' during
setup, you might well find yourself putting so much logic in the UI
layer that some of what you already wrote in the 'logic' layer ends up
unused.

As for why you might want illegal positions during setup, imagine a UI
where you can click on a square repeatedly and it cycles through the
possible pieces (dunno whether this would be good in practice, but I do
know that guessing whether a UI is good without trying it is rather
unreliable).

-M-