c++ - What abstraction level should the servo transitions have? -

i think i'm using many methods because of poor abstraction design. that's why i'm asking question, different this one , similar ones, focus on number of methods per se.

long story short, i'm doing hexapod. i'm saying because there unusual design considerations: cannot change going forward going backwards in no time; there's transition time. also, there's idle time, that's when there's no action.

i'm refactoring code, achieve find i'm creating many methods should not in top-level abstraction, below:

void loop()   {   // potentiometer   string action = controller.action();   serial.println(action);    // set spider forward start position   if (action == "toforward")     {     spidey.toforward();     }    // move spider forward   else if (action == "forward")     {     spidey.forward();     }    // standby position   else if (action == "fromforward")     {     spidey.fromforward();     }    // many more methods here    // default action (stand by)   else     {     spidey.idle();     }    delay(10);   } 

in level, spidey.forward(); method should visible, not transition ones. how set abstraction level transition actions?

my options:

1. make controller return parameter, "transition", passed method being called. problem: over-complicates code.

2. instead of making controller return toforward, forward , fromforward, make return forward, , make spidey handle things internally (store variable lastaction inside spidey instead of storing insde controller i'm doing now). problem: creates many more private methods, okay according the question linked.

3. any other idea?

this depends bit on what's happening in controller now. somewhere there needs class keeps record of present state , handles transition sequencing, , translates request "forward" sequence transitions intermediate states. maybe controller, or maybe spidey.

to me, looks wrong have big if block call different functions based on lot of different magic strings. looks more top-level representation doesn't handle intermediate states. internal state transition logic appear more comfortable using enumeration. there may member function tostate() sequence states reach state.

bear in mind class going need polled or notified when intermediate state finished can start next. if controller knows this, may make sense have logic there. don't try duplicate or split logic between 2 classes.