I've been given some Java code to look at, which simulates a car race, of which includes an implementation of a basic state machine. This is not a classical computer science state machine, but merely an object that can have multiple states, and can switch between its states based on a series of calculations.
To describe just the problem, I've got a Car class, with a nested enum class which defines some constants for the state of the Car (such as OFF, IDLE, DRIVE, REVERSE, etc). Within this same Car class I have an update function, which basically consists of a large switch statement which switches on the cars current state, does some calculations and then changes the cars state.
As far as I can see, the Cars state is only used within its own class.
My question is, is this the best way of dealing with the implementation of a state machine of the nature described above? It does sound like the most obvious solution, but in the past I've always heard that "switch statements are bad".
The main problem I can see here is that the switch statement could possibly become very large as we add more states (if deemed necessary) and the code could become unwieldy and hard to maintain.
What would be a better solution to this problem?
Best Answer
I turned the Car into a state machine of sorts using State Pattern. Notice no
switch
orif-then-else
statements are used for state selection.In this cases all states are inner classes but it could be implemented otherwise.
Each state contains the valid states it can change to.
User is prompted for the next state in case more than one is possible, or simply to confirm in case only one is possible.
You can compile it and run it to test it.
I used a graphic dialog box because it was easier that way to run it interactively in Eclipse.
The UML diagram is taken from here.