数据驱动 ---书籍内容摘抄

rel="File-List" href="file:///G:%5Ctmp%5Cmsohtml1%5C01%5Cclip_filelist.xml">

数据驱动 ---书籍内容摘抄

<<人月神话>>的第9章 削足适履指出，数据的表现形式是编程的根本。战略上突破常来自数据或表的重新表达-----这是程序的核心所在。如果提供了程序流程图，而没有表数据，我仍然很迷惑。而给我看表数据，往往就不再需要流程图了，程序结构是非常清晰的。

 

<<Unix艺术编程>>的9章 数据驱动编程指出，

数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编成的核心是数据结构，而不是算法。

人类其实更善于肉眼观察数据而不是推导程序流程。数据比程序逻辑更易驾驭。无论数据是普通表格，说明性标记语言，模版系统还是一组可以扩展成程序逻辑的宏，这一点都成立。尽可能把设计的复杂度从程序代码转移到数据中是个好实践，选择便于人类维护和操作的数据表示法也是好的实践。把这些表示法转换为便于机器处理的形式是机器该干的事，而不是人类的活动。

进行数据驱动编程时，需要把代码和代码作用的数据结构划分清楚。这样，在改变程序逻辑时，就只要编辑数据结构而不是代码。数据驱动编程有时会跟面向对象混淆起来，后者是另一种以数据组织为中心的风格。它们之间至少有两点不同。第一，在数据驱动编程中，数据不仅仅是某个对象的状态，实际上还定义了程序的控制流。第二，OO首先考虑的是封装，而数据驱动编程看重的是编写尽可能少的固定代码。Unix中数据驱动编程的传统比OO更深厚。

进行任何类型的代码生成或数据驱动编程的重要原则是：始终把问题层次往上推。把程序逻辑从硬编定的控制结构转移到数据中。尽可能少干活；让数据塑造代码；依靠工具；把机制从策略中分离。

 

<<代码大全2>>的Message处理

首先看看Message的格式。

不同的Message通过MessageID来区分。所有的Message都共用基本的类型，如float，integer,string,time,bool,bitfield等。不同的Message包含的基本类型的个数，顺序是不同的。

需求是打印所有的Message。

依据不可重复的原则，对所有基本类型的打印逻辑封装在函数中。

然后以类型为索引，访问表，得到能够打印该类型的函数指针并调用。

困难的地方是，Message类型太多，各种不同的Message的打印处理都差不多，但又都不同。用OO的方法吧，好像没有起到什么效果。只不过把各种打印逻辑封装到了不同的对象中而已。

应用把程序逻辑从硬编定的控制结构转移到数据中的原则，我们可以将打印不同Message内容的逻辑从代码中迁移到数据结构中。如果我们利用数据结构表达出Message，那么就可以大大减轻工作量。数据结构定义的控制流就是Message的打印顺序和字段类型。

 

利用数据可以描述所有的Message，并且打印处理只需要一个函数便可以处理所有的Message。而且可以方便的应对Message结构的变更，Message种类的增加。

通过始终把问题层次往上推，实现者站在更高的抽象级别上来看待问题并解决。

 

有重复的代码，相似的代码时，一点要阅读代码，再次阅读代码，考虑如何改善。正应了那句话，只有解决问题之后，你才真正的理解了问题。这或许也正是重构，测试驱动开发的内在理论支持吧。

坚决不容忍破窗户。没有办不到的事儿，只有你肯花时间去想，去改善。表驱动，数据驱动是相当简单，但是容易被忽略，而又强力的方法。