aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Finding a suitable abstraction Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Finding a suitable abstraction" Watch "Finding a suitable abstraction" New topic
Author

Finding a suitable abstraction

Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
I trying to code a craps simulator and I'm stuck at a particular part. The way the progam is structured as it stands, I pass a Die[] array to a DiceRoller object which (obviously) is responsible for rolling the dice. Bet instances register as listeners to the DiceRoller, and are notified of the results of each roll. The Bet itself is then responsible for interpresting the roll and deciding whether it was won, loss, or no result was obtained. The Bet interface looks like this:
Here is my problem, some Bets can only be made when a previous Bet was made. To enforce this I was thinking of having the Bet itself return another Bet that can be made.

The problem with this approach is that when a Player (or BetManager or whatever object ends up being responsible for is managing the set of Bets)has multiple Bets, it will need to do an instanceof check to see if the Bet offers an additional bet option.
I'm certain there has to be a better way but I haven't been able to figure it out yet. As always any suggestions or comments are welcome.

Garrett
[ November 13, 2006: Message edited by: Garrett Rowe ]

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
A couple ideas come to mind.

Bet[] availableBets = lastBet.getAvailableBets();
player somehow chooses from this array ...

But it seems more like the player ought to be keeping track of this. I'm not sure what information you need to get from one state to the next. Maybe something like:

playerState = playerState.nextState( bet );
availableBets = playerState.getAvailableBets();

PlayerState is a class that knows the current state and options that implies. You could have a subclass per state and hardcode the options in each subclass with no "if" tests at all. Somebody has to know the transition rules to other states. Maybe the state itself or maybe a factory.

Do you put this in the Player? Do you trust him to keep track of his own state? It would be fun to write a Player who cheats. (And another player to stabs him.) In a casino there is a croupier (?) or somebody to keep the peace. Does your game need one?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
Stan James: But it seems more like the player ought to be keeping track of this. I'm not sure what information you need to get from one state to the next.

Not sure how much anyone else knows about the game of Craps, but the gist of what I'm takling about is this: If you make a pass line bet, and a point (any number but 2, 3, 7, 11, 12) is rolled, you are allowed to wager additional funds at a different set of payout odds. So the only prerequisite is that you already have a pass line bet, and there is a point established. (I realize I've lost most non-gamblers at this point). I guess up to this point my code has been agnostic about where the Bet actually come from and only that it adheres to the contract of the Bet interface. I suppose I had been thinking that the Player itself would be the one to create the Bet:

But in retrospect that doesn't seem right. The solution you offer, that the Player actually is offered a list of bets, and he accepts the one(s) that he wants in the amount that he wants to wager (provided that the amount is consistant with any casino minima / maxima) seems more realistic. It will require an object that knows the current state of the player's bets and what bets are available to the Player given his current situation. I also feel like it may be necessary to distinguish betwween a BetOffer
and an actual in - play Bet, maybe something like this:
Any thoughts?
[ November 13, 2006: Message edited by: Garrett Rowe ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I like the "offer" semantics. Does it feels like someone should show you all the offers and only allow or require you to select exactly one?
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
Well they're pretty greedy at the casino so they'll allow you to take as many bets as you're comfortable making. You can also sit out a few rolls and not bet anything, just observe. So while you may be able to make only one of each type of bet, you can make as many bets as you want. The bets themselves have different semantics though. Some are only active for one roll and after that roll they are either won or lost, some are active until they win or lose or are called off, and some are active until they win or lose and can't be called off. Why do you ask? Does that suggest to you a diffent direction?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Wow, I think you went right by me on the rules of the game, but it sounds like your approach to offering a variety of bets (maybe only two kinds?) and letting the player choose 0..n is good.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Finding a suitable abstraction