正在阅读：经验分享:闲谈C++算法封装之穷举法经验分享:闲谈C++算法封装之穷举法

  template<class State>

  class WalkThrough

  {

  public:

    void setState(const State& s) { curState = s; }

    State getState() const { return curState;

    bool getNextFilter();

    bool isOver() const { return overFlag; }

  private:

    State curState;

    bool overFlag;

  };

    我们把构造函数与析构函数置后，先考虑起关键作用的getNextFilter()的实现。首先，getNextFileter()由当前的状态跳转为下一状态，然后判断新状态是否为可行，若可行，则停止跳转并返回true，否则继续跳转，重复上述步骤。另一方面，如果已经完成了遍历而还没有找到可行状态，则将overFlag设为false并且返回false.

    我们将跳转操作、判断是否为可行状态操作下放给用户实现：用户相应提供两个函数，然后向WalkThrough对象传入函数指针，供getNextFileter()调用。那么这两个函数应该采用什么样的接口形式比较合适呢？先看看跳转函数，一个很直观的实现是传入一个State对象（或其const引用），然后返回“下一个”State对象，不过至少在返回的时候，值传递会产生State对象的复制操作（诸如NRV优化之类的语言标准外的特定编译器实现不在讨论之列），当State对象比较大的时候，开销是不值得的。我们应当考虑传入State对象的引用，然后“全权委托”跳转函数进行直接修改——把它“变”成下一个状态。可能会有人质疑这样做是否违反了封装原则，但即使摒弃效率方面的权衡，这样做也是合情合理的。跳转函数——不妨视为负责“状态转化”函数，就像一个炼丹炉——有权利、甚至有义务这样做，它的职责是“转化状态”而非“获得状态”。唔……我都觉得自己在语言上过于细究了。嗯，除了转化状态，跳转函数在发现遍历完成之后也应当及时告知调用它的getNextFilter()，否则下放了大部分权力的getNextFilter()是无从知晓的。于是我们的跳转函数接口为：接受一个State的引用，返回一个bool值。如果遍历没有完成，那么函数执行完毕之后State引用将变为它的后继状态，且函数返回true；否则State不变，函数返回false.