An important key to good design is the ability to see into the future. You need to predict (and you will be judged on how well you predict) how the code will evolve.
You want MORE generalization where you expect the code to split up more, and become more complex. You generally need less generalization where the code wont change much.
A key flaw with your 'anonymizing' names so they don't mean anything, is that I cannot given GUESS where you will be wanted to generalize more in the future. You have to figure that out.
The code you have now - with conditionals (m_flag) - really isn't bad, depending on how you expect the code to evolve over time. But if you expect lots of doOtherThings() implementations depending on subtype - you see that as a productive area of change - then subclassing is a good idea.
What you described as IDoThingsStrategy does NOT seem like a particular good idea - at least as far as GENERIZING codes. It is a good strategy for MODULARIZING (but the reader - me - doesnt know if it makes sense for modularizing). What you are doing is allowing the subclassing to happen separated and without respect to the other data in 'Foo'. That could be a PITA (if you generally need that information) or smart, if you dont.
One more big hint - if thats C++ - use 'virtual' and 'override'. Even for stuff like this, it makes what you are doing clearer.