我是不是该使用策略模式？

   我有一个状态机，大家可以把它想成是一个叫M的类，状态机M中存在一个成员F，F中又有很多方法，一开始F挺单纯的，后来功能扩展，F越来越复杂，增加的接口越来越多。实际上F中有一个属性叫做Version，它会直接影响M状态机的变迁，例如Version==1的时候M的循环路线可能是A-B-C-D-A，Version==2的时候可能就是A-S-X-C-D-A了，我现在的做法就是让F成为一个大杂烩，依靠Version来走不同的逻辑，但是我觉得这种感觉不太好，F越发臃肿，一些接口和成员可以通用，一些却只能都在特定Version下才有意义，不管是M还是F，一些逻辑分支下都是靠if-else version来实现的，如果再这样臃肿下去，势必会越发难以理解和维护。
  然后我就想到了策略模式，但是有几个问题不太肯定：
1、我理解的策略模式除了一个继承树，还要把基类作为成员装到另外一个类里面。用我的例子来说，F就是那个抽象基类，我之前各种Version扩展出来的就继承为F1，F2，F3，...，而M就是使用策略的那个“另一个类”。不知道这个理解是不是正确？
2、还有一个关键，就是这些策略需要有共性，就是virtual fun的接口得可以抽象成一样的，在我的例子里面，它们既有共性又有很不一样的地方，就连策略使用者M都会根据F的某些特点而做出不同的状态变迁路径，我不知道这样的情况究竟合不合适使用所谓的策略模式？

2 个解决方案

#1

1. 首先你需要理清M与F、F与Version为什么是Has-a的关系，为什么M需要根据Version的值来决定自己的策略
2. 你理解的策略模式是正确的，但是如果策略的接口很不一样，你需要考虑这些策略之间根本不存在任何关系，不能使用继承，可以将这些策略用不同的类来封装；比如 Version=1时，实例化 F1和M1，Version=2时，实例化F2和M2，这样就可以保证F1和M1、F2和M2之间的接口一致性，在调用时也不存在歧义

#2

例如Version==1的时候M的循环路线可能是A-B-C-D-A，Version==2的时候可能就是A-S-X-C-D-A了
我觉得你这里都可以抽象出一个class(interface)，让不同循环路线的M去继承或实现，
另外不太清楚M是怎么去用F,如果能抽象出共同接口用策略模式挺合适的