This is a bad example. All it did was move the implementation of multiple behaviors (calls, messages, alarms, notifications) into each of the state instances.<p>A better way to handle this is to separate policy and mechanism. The state has configuration about handling of (calls, messages, alarms, notifications), and when each thing needs to be done that call/message/etc config is requested from the state and processed uniformly from there on out, not by the phone nor the state but by the call/message/etc handler.
Turning if statements into a collection of classes requires a bit more thoughts than "Stop Writing If-Else Trees"<p>Sometimes the State pattern transforms "one big if-else tree" into "a forest of tiny classes" with its own complexity tax. Good design isn't about eliminating conditionals — it's about putting them where they make the most sense.<p>The real skill is knowing when your state transitions are complex enough to warrant the abstraction overhead.
This is a domain modeling question.<p>If your if-else branches and flags are creating a combinatorial explosion and/or allowing more states to exist than are valid, pay the complexity tax of introducing a State pattern - it will pay itself back in maintainability and lack of bugs over time.<p>But if you’re just talking about one or two standalone values, the state is already there, represented as simply as possible by your enums.