RE: [Rails-devel] Operating Round

[Erik V. <eri...@hc...>]

> > These classes allow marking allowed actions in the UI in detail.
> > For instance, to check if the current Player can buy a share
> > of a given company from the Pool you could call
> >     isCompanyBuyable (company, pool);
> 
> I've approached this slightly differently in the Swing UI.
> 
> There's only two buttons: Buy and Selling.
> 
> When you select a particular company and player, and press the Buy
> button, if the company isn't started yet, it buys the 
> president's share,
> if it is started, it buys the next available share from any pool.

OK, that is a sensible approach (and it answers my question in the other
mail).
You could then still call isCompanyStartable() and/or isCompanyBuyable()
afterwards to see what StockRound method to call (startCompany() or
buyShare()). Or use company.hasStarted() to check this, but then you have to
look
up company yourself. 

I could change the isCompanyWhateverable methods (or any other method) 
to suit your approach if you would want to highlight the clickable areas 
(which I would recommend).
 
> I'm planning on making this a bit more granular once I add 
> displays for
> each pool, but for now it keeps things simple and effective.
> 
> > This method does not yet include a check that the player has enough
> > money (this is checked, though, in buyShare), but I will
> > add such checks later.
> 
> I think conditions like these only need checking once. The tricky part
> is, where should the checking be?
> 
> Do we want to use exception throwing to pass errors deeper in 
> the class
> hierarchy up to the higher level classes for handling?

As I said, I'm doing this in StockRound.buyShare().

Currently, all XxxxRound action methods return true or false
indicating whether the action was valid or not (all checks included).
If false, an error message is stored in Log, you can retrieve it
with Log.getErrorBuffer() (the message is then cleared) and display it.

I don't see a real need to use exceptions right now,
unless you would find checking the return values cumbersome.

My current approach is to move most of the game logic to the
middle layer (i.e. the Rounds and GameManager), including all
validation, and that is only one level below the UI.

BTW I'm testing an initial version of GameManager, which, however,
does not handle the private auction yet. That will come next.

Erik.