The idea of using the Command pattern to decouple the StateManager and DataReceiver sounds good to me, especially if you anticipate extensibility. However, for a simpler system, it may introduce unnecessary complexity.
I think the main considerations should be to weigh up the benefits, together with the simplicity of StateManager and the need for concurrency and asynchrony:
The Command pattern excels when handling different types of actions, supporting queuing, dynamic updates, and undo functionality. It also helps manage asynchronous updates in a controlled manner, ensuring correct execution order and potentially avoiding race conditions.
If your state update logic is simple, embedding the logic directly in the singleton StateManager might suffice, avoiding the overhead of creating multiple command classes. This approach keeps your code lean but risks overloading the class with responsibilities.
With updates coming from asynchronous sources, the Command pattern can help ensure consistency by queuing state changes. However, other techniques (eg., locks or message queues) can also manage concurrency without requiring the full Command pattern overhead.
Summing up, if the update logic is simple and stable, managing it within StateManager should minimise complexity. However, if you expect the system to grow in complexity, the Command pattern offers better long-term scalability and maintainability, particularly for managing asynchronous state updates.
