Relationship between GUI and logic?

[Matthew Woodcraft]

David C. Ullrich <dullrich at sprynet.com> wrote:

> Matthew Woodcraft <mattheww at chiark.greenend.org.uk> wrote:
>> 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-