The document discusses the state machine pattern as an alternative to using many if/else statements to handle an object's internal state. It describes a CarEngine class that uses if/else statements for its different engine states like OFF and RUNNING. This violates object-oriented design principles. The state pattern extracts each state into its own class like EngineOff and EngineRunning. The handle method is moved to each state class to encapsulate the behavior for that state and transition to the next state. This improves encapsulation over the if/else approach.

1. State Machine
Patterns

2. The “IF” abuse
❖ I say: “80% of ifs in OOP are a bad solution
❖ polymorphism usually is a best solution

3. CarEngine
private EngineStatus status;
. . .
if (status == EngineStatus.OFF) {…}
if (status == EngineStatus.RALENTY) {…}
if (status == EngineStatus.BROKE) {…}
if (status == EngineStatus.RUNNING) {…}
a class that has a
different behavior
depending on some intenal
status

4. CarEngine
private EngineStatus status;
. . .
if (status == EngineStatus.OFF) {…}
if (status == EngineStatus.RALENTY) {…}
if (status == EngineStatus.BROKE) {…}
if (status == EngineStatus.RUNNING) {…}
each class has the
behavior…
EngineOff EngineRalenty EngineBroke EngineRunning

5. CarEngine
private EngineStatus status;
engine.handle();
EngineOff EngineRalenty EngineBroke EngineRunning
<<EngineStatus>>
handle();
implements

6. State Machine Pattern
❖ The state pattern can be
interpreted as a strategy
pattern which is able to switch
the current strategy through
invocations of methods defined
in the pattern's interface

7. UML

8. The Bad Way
state
if (state)…
AggregationExecutor

9. The Good Way
CancelBy
Timeout
ExecFirst
Phase
Finish
Error
Finish
Ok
ExecutionState
ExecutionState handle ();
Each class represents the actual state.
The handle method runs the state and returns the next state
(as other ExecutionState instance) updating the context (aggregationRequest)
Aggregation
Request
……..