State machines, encapsulation and OOP design - oop

Question

I'm implementing a FSM using Boost's MSM library.
In the FSM, I have transition tables which describe Events, Source states, Target states, Actions and Guards.
It's my first time using a higher-level design of a state machine. In the past, I've just used switch statments and executed code. However, this one is going to be big and I wanted to keep everything organized properly so it doesn't turn into a mess.
I have an object that represents the state machine (it's a boost::msm::back::state_machine<MyStateMachine> where MyStateMachine is my implemenmtation which inherits from boost::msm::front::state_machine_def ).
The trick is that my business logic will be done in the Actions. I don't think that's uncommon for a FSM. Boost's examples seems to suggest that these Actions should be implemented as methods in the state machine itself, but I'm thinking that this just might make the one class too massive. I feel it makes sense to separate the work from the state machine.
Which makes more sense to keep a readable, maintainable, and extendable design?
Do the business logic in methods in the FSM class (I'm worried that this mixes state management with work too closely).
Do the business logic in the parent which instantiates the FSM. The FSM will need a pointer to the parent, and the parent will need to implement an interface that the FSM understands (that, or the FSM implementation will need to #include the declaration of the parent).
Do the business logic in a new class which is instantiated and owned by the FSM.
Do the business logic in a new class which is instantiated and owned by the parent, but passed as a reference (or pointer) to the FSM.
Something else.

Answer 1

It depends on your situation but I have one approach I usually use.
Maybe it is a variation of the 2 or 5.
Let's say your_app has your business logic. And it needs to behave as state-machine. I think that it is one of the typical use-case of the state-machine.
In this case, the state-machine can be placed as the nested class of the your_app. your_app has the member variable sm_, state-machine instance.
The definition of the state-machine is sm_def. It has the reference of the your_app.
When someone that is outside of the your_app want to process an event, call your_app::process_event(). If you don't want to provide direct event process interface, you can wrap it as your_app::handle_some(). If you do so, your_app::process_event() should be private.
Here is example implementation:
#include <iostream>
#include <boost/msm/back/state_machine.hpp>
#include <boost/msm/front/state_machine_def.hpp>
#include <boost/msm/front/functor_row.hpp>
namespace msm = boost::msm;
namespace msmf = boost::msm::front;
namespace mpl = boost::mpl;
// application domain
class your_app {
public:
your_app() :sm_(boost::ref(*this)) {
sm_.start(); // start state machine
}
// public interface for event processing
// Event definitions
struct Event1 {
int param;
};
template <typename Event>
void process_event(Event const& ev) {
sm_.process_event(ev);
}
void handle_some(int param) {
process_event(Event1 {param});
}
private:
// internal business logic triggered from the state machine
void do_some_business(int param) {
std::cout << "do_some_business " << param << std::endl;
}
// state machine definiition
struct sm_def:msmf::state_machine_def<sm_def> {
sm_def(your_app& ya):ya_(ya) {}
// States
struct State1:msmf::state<> {
template <class Event,class Fsm>
void on_entry(Event const&, Fsm&) {
std::cout << "State1::on_entry()" << std::endl;
}
template <class Event,class Fsm>
void on_exit(Event const&, Fsm&) {
std::cout << "State1::on_exit()" << std::endl;
}
};
struct State2:msmf::state<> {
template <class Event,class Fsm>
void on_entry(Event const&, Fsm&) {
std::cout << "State2::on_entry()" << std::endl;
}
template <class Event,class Fsm>
void on_exit(Event const&, Fsm&) {
std::cout << "State2::on_exit()" << std::endl;
}
};
// Set initial state
typedef State1 initial_state;
// Actions
struct Action {
template <class Event, class Fsm, class SourceState, class TargetState>
void operator()(Event const& e, Fsm& f, SourceState&, TargetState&) const {
// get your_app via Fsm.
f.ya_.do_some_business(e.param);
}
};
// Transition table
struct transition_table:mpl::vector<
// Start Event Next Action Guard
msmf::Row < State1, Event1, State2, Action, msmf::none >,
msmf::Row < State2, Event1, State1, Action, msmf::none >
> {};
your_app& ya_;
};
friend class sm; // give the friend access to the sm
typedef msm::back::state_machine<sm_def> sm;
sm sm_;
};
int main() {
your_app ya;
ya.process_event(your_app::Event1{42});
ya.handle_some(44);
}
And running demo: https://wandbox.org/permlink/PQGSGr0bnJHgaMpD