-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
- The following is true for all active objects defined in this project as it is today, but let's take the
class Toaster, fromsamples/toaster/main.cppas a study case here... - Currently, when you define an active object (like
Toaster) it will contain, amongst other things, an instance of aclass StateManager- This object is the one that will perform state transitions and call the state's
process_eventmethods, based on the events removed from the object's queue
- This object is the one that will perform state transitions and call the state's
- In order to create a
StateManagerobject, we need to describe the object's Hierarchical State Machines (HSM) - The HSM is modeled as a "n-ary tree", that presents the hierarchical relationship between the states
- Also, to be able to access the nodes (states), a
mapis defined as a member of the active object to allow referencing specific nodes via an enumeration:
std::map<StateValue, tree<ToasterSuperState_ptr>::iterator> m_states;
/* ... */
if (m_next_state != m_states[StateValue::UNKNOWN])- This makes it so that the definition of a new object is really painful, there is so much boiler plate code and coupling
- Just like the
class StateManagerdoes not need to know the tree definition, and just acts on the tree nodes in an abstract manner, theclass Toaster(used here as an example) ideally would also not need to be responsible for defining the FSM, it could just be inputed to it in it's creation - I believe that the best approach would be to describe a FSM in it's own independent scope, and when creating an active object, I pass as a parameter that FSM definition
Metadata
Metadata
Assignees
Labels
No labels