On 2/5/06, ia...@co... <ia...@co...> wrote:
> Erik wrote:
> > >
> > > brett lentz wrote:
> > >
> > > It sounds like you are suggesting adjustMoney returns a flag and Bank
> > > doesn't keep any state that it is broken, so it is up to all
> > > the callers
> > > to check the return value and propagate that information to anything
> > > that needs to know it. Since there are very few places that need to
> > > know the bank is broken (which will also need to check other game-end
> > > conditions), it seems to make more sense to have the Bank object keep
> > > track of whether it is broken and have those few things that
> > > care check
> > > for it rather than checking after every adjustment to the
> > > bank balance.
> > >
> >
> > I agree with John, which is how I would approach it.
> >
> > We also need a mechanism to inform the user that the bank has
> > "just" broken (e.g. via a pop-up). That could be a method that
> > returns true exactly once (Bank.isJustBroken()), but that method should
> > then be called after every action. It's perhaps easier to have
> > the Bank send out an Event or an Observer update call
> > (I prefer the latter, as the mechanism is already being used).
> >
> > Erik.
>
> I agree, the Bank should make the current balance an observable property.=
A 'GameEndMonitor' can then register itself as a listener of that property=
of the bank, and if the balance ever goes negative, set the game end flag.=
This would allow other game end conditons (e.g. player bankruptcy) to be c=
ollected in the same place. You can then easily display the game status ('e=
nding after this OR set'), and you don't need to worry about which action c=
ould cause the bank-breaking event.
>
> Iain.
>
See... I have exactly two problems with the side of the fence the
three of you are on...
1. The addCash() method is a part of the CashModel, and not the Bank
object. This means that this boolean is for both breaking the bank AND
triggering forced purchase/sale actions for players.
2. This is not how the current code works. We've been value checking
things outside of the container classes for a very long time now. If
you look at Bank, CashModel, and Portfolio, you'll see that none of
them do this.
I do think that the approach you guys are advocating is a sound
approach AND my changes don't disallow it. In fact, it shouldn't be
difficult to use my change as the first step in building the rest of
the bank breaking mechanism.
---Brett.
|
