Switch statements are not bad. Do not listen to people who say things like "switch statments are bad"! Some particular uses of switch statements are an antipattern, like using switch to emulate subclassing. (But you can also implement this antipattern with if's, so i guess if's are bad too!).

Your implementation sounds fine. You are correct is will get hard to maintain if you add many more states. But this is not just an issue of implementation - having an object with many states with different behavior is itself a problem. Imaging your car has 25 states were each exhibit different behavior and different rules for state transitions. Just to specify and document this behavior would be an enormous task. You will have thousands of state-transition rules! So if possible avoid going down this road.

A possible remedy is to break the state into independent substates. For example, is REVERSE really a distinct state from DRIVE? Perhaps the car states could be broken up in two: Engine state (OFF, IDLE, DRIVE) and direction (FORWARD,REVERSE). Engine state and direction will probably be mostly independent, so you reduce logic duplication and state transition rules. More objects with fewer states are a lot easier to manage than a single object with numerous states.

Switch statements are not bad. Do not listen to people who say things like "switch statments are bad"! Some particular uses of switch statements are an antipattern, like using switch to emulate subclassing. (But you can also implement this antipattern with if's, so i guess if's are bad too!).

Your implementation sounds fine. You are correct is will get hard to maintain if you add many more states. But this is not just an issue of implementation - having an object with many states with different behavior is itself a problem. Imaging your car has 25 states were each exhibit different behavior and different rules for state transitions. Just to specify and document this behavior would be an enormous task. You will have thousands of state-transition rules! The size of the switch would just be a symptom of a larger problem. So if possible avoid going down this road.

A possible remedy is to break the state into independent substates. For example, is REVERSE really a distinct state from DRIVE? Perhaps the car states could be broken up in two: Engine state (OFF, IDLE, DRIVE) and direction (FORWARD,REVERSE). Engine state and direction will probably be mostly independent, so you reduce logic duplication and state transition rules. More objects with fewer states are a lot easier to manage than a single object with numerous states.

Switch statements are not bad. Do not listen to people who say things like "switch statments are bad"! Some particular uses of switch statements are an antipattern, like using switch to emulate subclassing. (But you can also implement this antipattern with if's, so i guess if's are bad too!).

Your implementation sounds fine. You are correct is will get hard to maintain if you add many more states. But this is not just an issue of implementation - having an object with many states with different behavior is itself a problem. Imaging your car has 25 states were each exhibit different behavior and different rules for state transitions. Just to specify and document this behavior would be an enormous task. You will have thousands of state-transition rules! So if possible avoid going down this road.

A possible remedy is to break the state into independent substates. For example, is REVERSE really a distinct state from DRIVE? Perhaps DRIVE could encompass both, and then introduce a separate state for direction which could be FORWARD or REVERSE. More objects with fewer states are a lot easier to manage than a single object with numerous states.

Switch statements are not bad. Do not listen to people who say things like "switch statments are bad"! Some particular uses of switch statements are an antipattern, like using switch to emulate subclassing. (But you can also implement this antipattern with if's, so i guess if's are bad too!).

Your implementation sounds fine. You are correct is will get hard to maintain if you add many more states. But this is not just an issue of implementation - having an object with many states with different behavior is itself a problem. Imaging your car has 25 states were each exhibit different behavior and different rules for state transitions. Just to specify and document this behavior would be an enormous task. You will have thousands of state-transition rules! So if possible avoid going down this road.

A possible remedy is to break the state into independent substates. For example, is REVERSE really a distinct state from DRIVE? Perhaps the car states could be broken up in two: Engine state (OFF, IDLE, DRIVE) and direction (FORWARD,REVERSE). Engine state and direction will probably be mostly independent, so you reduce logic duplication and state transition rules. More objects with fewer states are a lot easier to manage than a single object with numerous states.