Object-oriented design for Wheel of Fortune

I'm trying to design the classes for the Wheel of Fortune game in Java. The below diagram represents the classes and the interaction between them.

.
Below is the partial implementation of it. I appreciate some feedback on my design and approach. I'm mainly interested in classes and their dependencies. In code I referred MoneyPrize as DollarAmountSpinOutcome.

1) Is Wheel dependency on Player correct? If not how can I redesign to avoid it?

2) In method WheelOfFortune.getSpinOutcomeProcessor(SpinOutCome outcome) I am explicitly casting it to Specific spin out come. Is it a smell. Does it indicate a broken modeling?

```
public class WheelOfFortune {

private List players;

private Host host;

private Wheel wheel;

public WheelOfFortune(List players, Host host, Wheel wheel) {
this.players = players;
this.host = host;
this.wheel = wheel;
}

public static void main(String[] args) {

Player player1 = new Player("player1", new Account());
Player player2 = new Player("player2",new Account());
Player player3 = new Player("player3",new Account());
ArrayList players = new ArrayList();
players.add(player1);
players.add(player2);
players.add(player3);

Host host = new Host();
Wheel wheel = new Wheel();
WheelOfFortune wheelOfFortune = new WheelOfFortune(players, host, wheel);
wheelOfFortune.start();

}

public void start() {
int round = 0;
while (!isGameOver()) {
round++;
for (Player player : players) {

boolean isTurnOver = false;
while (!isTurnOver) {
Choice choice = player.makeChoice();
if (choice == Choice.SPIN_WHEEL) {
SpinOutCome spinOutCome = player.spinWheel(wheel, round);
isTurnOver = processSpinOutCome(spinOutCome);
} else if (choice == Cho

Thumbs up for the diagram! That's more by far compared to what most people do when starting such a project.

A few things I recognized at first sight:

-
Player.buyOval() and WheelOfFortune.processOvalBuy(...) should read Vowel instead of Oval, shouldn't they?

-
You have a SpinOutComeProcessor (that, according to the name, processes spin outcomes) and you have an extra WheelOfFortune.processSpinOutCome(...) method. Why not use the processor directly thus saving this method?

-
The second if (choice == Choice.BUY_VOWEL) is not necessary since there are just 2 Choices. So, if it's not the one it's the other. Though I'd add a comment to the then bare else for clarity: // BUY_VOWEL

-
There are 2 typos in Host.unconverConsonent(...) → uncoverConsonant

-
Why does Wheel.spin(...) depend on player and round? A wheel by itself just spins and shows (returns) a result, regardless of external entities.

-
500 inside Wheel.spin(...) is a magic number. It'd better be a properly named constant.

-
I'd move the enum Choice to the top of the class. At least before the first usage in start().

-
With start() being private one can instantiate your WheelOfFortune but cannot start it.

-
You have a SpinOutComeProcessor but just a static processOvalBuy(...) method. I'm thinking of a BuyVowelProcessor with:

char process(Account account) { /* calculate vowel */; return vowel; }

Invoked with:

buyVowelProcessor.process(player.getAccount());

On the other hand: Doesn't a player buy a vowel from the host?

-
According to your diagram Player is far away from, with no direct connection to your SpinOutComes. Why is it a member of them then? I'd expect a SpinOutComeProcessor to glue everything together – according to your diagram: user(?), amount, host(?), spin result.

-
In which way does your SpinOutComeProcessor use the User and the Host?

-
Why do you use a Character in Player.buyOval() instead of a simple char?

-
Re ArrayList players = ... It's common practice to use the interface type in such declarations: List players = ...

-
Why do you use an Integer for the player's amount instead of a simple int? (AFAIK there are only integer amounts so that no floating point type is needed in this case. Contrary to what is used for amounts normally.)

-
I'd rename the Dollar... class to the more general Cash.... Such you can sell your application worldwide easily. ;-)

-
I'd move all static members to the very top of class (before member declarations), since they belong solely to the class. All others belong to an object created from the class.

I admit, it wasn't only "at first sight" but second or third, or so. :-)

StackExchange Code Review Q#84696, answer score: 10