在做项目的时候，我总是会因为if else层层套而感觉很烦，所以我就去看了一点书，想办法解决代码千层饼的问题，最后在代码大全里面看到了表驱动编程的章节，就尝试使用表驱动编程的思想来改造代码，让其不会太过于又臭又长。同时我发现不止是ifelse问题，其他很多地方也可以使用这个思想，它值得发扬光大。
首先先简单介绍一下表驱动编程
举一个非常简单的例子,也是我自己项目中的例子
我在这里设置了一个prop type，使得外面可以传一个type进来，并且设置了一个api用来更新type，每次点击type改变。

   <li :class="type === '-' && 'selected'"
          :class=''value==='ok'&&get''
          :class=''value==='no'&&fail''>
收入
      </li>

修改后

 <li :class="{selected: item.type === '-',
        [this.state + 'get']:item.value==='ok' ,
        [this.state + 'fail']:item.value==='no' }" 
v-for="item in dataSource">
收入
            </li>

这里我把表驱动编程运用到了class名称里，使得再绑定的时候不用每个在：class来绑定,从而使得可读性更加强。同时需要注意的是如果你class名字要用到变量请用[]括起来。

这种思路的优势：

1、可读性更强，消息处理流程一目了然。

2、更容易修改，要增加新的消息，只要修改数据即可，不需要修改流程。

2、**隐含在背后的思想 **

很多设计思路背后的原理其实都是相通的，隐含在数据驱动编程背后的实现思想包括：

1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。

2、隔离变化。像上面的例子，每个消息处理的逻辑是不变的，但是消息可能是变化的，那就把容易变化的消息和不容易变化的逻辑分离。

3、机制和策略的分离。和第二点很像，本书中很多地方提到了机制和策略。上例中，我的理解，机制就是消息的处理逻辑，策略就是不同的消息处理（后面想专门写一篇文章介绍下机制和策略）。
4.减少重复代码

下面是我抄的，还看不懂，但是以后可以慢慢理解

3、**数据驱动编程可以用来做什么 **

如上例所示，它可以应用在函数级的设计中。

同时，它也可以应用在程序级的设计中，典型的比如用表驱动法实现一个状态机（后面写篇文章专门介绍）。

也可以用在系统级的设计中，比如DSL（这方面我经验有些欠缺，目前不是非常确定）。

它不是什么：

1、 它不是一个全新的编程模型：它只是一种设计思路，而且历史悠久，在unix/linux社区应用很多；

2、它不同于面向对象设计中的数据：“数据驱动编程中，数据不但表示了某个对象的状态，实际上还定义了程序的流程；OO看重的是封装，而数据驱动编程看重的是编写尽可能少的代码。”

书中的值得思考的话：

数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike

程序员束手无策。。。。。只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks

数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者。

3、可扩展性。注意这个函数指针，他的定义其实就是一种契约，类似于java中的接口，c++中的纯虚函数，只有满足这个条件（入参，返回值），才可以作为一个事件的处理函数。这个有一点插件结构的味道，你可以对这些插件进行方便替换，新增，删除，从而改变程序的行为。而这种改变，对事件处理函数的查找又是隔离的（也可以叫做隔离了变化）。、

4、程序有一个明显的主干。

5、降低了复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。

5、继承与组合

考虑一个事件驱动的模块，这个模块管理很多个用户，每个用户需要处理很多的事件。那么，我们建立的驱动表就不是针对模块了，而是针对用户，应该是用户在某状态下，收到某模块的某事件的处理。我们再假设用户可以分为不同的级别，每个级别对上面的提到的处理又不尽相同。

用面向对象的思路，我们可以考虑设计一个用户的基类，实现相同事件的处理方法；根据级别不同，定义几个不同的子类，继承公共的处理，再分别实现不同的处理。这是最常见的一种思路，可以叫它继承法。

如果用表驱动法怎么实现？直接设计一个用户的类，没有子类，也没有具体的事件的处理方法。它有一个成员，就是一个驱动表，它收到事件后，全部委托给这个驱动表去进行处理。针对用户的级别不同，可以定义多个不同的驱动表来装配不同的对象实例。这个可以叫他组合法。

继承和组合在《设计模式》也有提到。组合的优势在于它的可扩展性，弹性，强调封装性。（继承和组合可以参考这篇文章：面向对象之继承组合浅谈）

至于这种情况下的驱动表，可以继续使用结构体，也可以使用对象。

上面的方法的一点性能优化建议：

如果对性能要求不高，上面的方法足可以应付。如果性能要求很高，可以进行适当的优化。比如，可以建立一个多维数组，每一维分别表示模块，状态，消息。这样，就可以根据这三者的枚举直接根据下标定位到处理函数，而不是查表。（其实还是数据驱动的思想：数据结构是静态的算法。）

数据驱动编程再更高级，更为抽象一点的，应该就是流程脚本或者DSL了。我曾经写过一个简单的寄生在xml上的脚本来描述流程。这一块后面抽时间介绍。