聊聊程序设计思想之面向数据驱动编程

数据驱动

数据驱动是一种思想,数据驱动型编程是一种编程范式。基于数据驱动的编程,基于事件的编程,以及近几年业界关注的响应式编程,
本质其实都是观察者模型。数据驱动定义了data和acton之间的关系,传统的思维方式是从action开始,
一个action到新的action,不同的action里面可能会触发data的修改。数据驱动则是反其道而行之,以data的变化为起点,
data的变化触发新的action,action改变data之后再触发另一个action。如果data触发action的逻辑够健壮,
编程的时候就只需要更多的去关注data的变化。思考问题的起点不同,效率和产出也不同。

把知识叠入数据以求逻辑质朴而健壮

数据驱动编程的核心:数据驱动编程的核心出发点是相对于程序逻辑,人类更擅长于处理数据。数据比程序逻辑更容易驾驭,所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。

真的是这样吗?让我们来看一个示例。

假设有一个程序,需要处理其他程序发送的消息,消息类型是字符串,
每个消息都需要一个函数进行处理。第一印象,我们可能会这样处理:
void msg_proc(const char *msg_type, const char *msg_buf)  
{  
    if (0 == strcmp(msg_type, "inivite"))  
    {  
        inivite_fun(msg_buf);  
    }  
    else if (0 == strcmp(msg_type, "tring_100"))  
    {  
        tring_fun(msg_buf);  
    }  
    else if (0 == strcmp(msg_type, "ring_180"))  
    {  
        ring_180_fun(msg_buf);  
    }  
    else if (0 == strcmp(msg_type, "ring_181"))  
    {  
        ring_181_fun(msg_buf);  
    }  
    else if (0 == strcmp(msg_type, "ring_182"))  
    {  
        ring_182_fun(msg_buf);  
    }  
    else if (0 == strcmp(msg_type, "ring_183"))  
    {  
        ring_183_fun(msg_buf);  
    }  
    else if (0 == strcmp(msg_type, "ok_200"))  
    {  
        ok_200_fun(msg_buf);  
    }  
    。。。。。。  
    else if (0 == strcmp(msg_type, "fail_486"))  
    {  
        fail_486_fun(msg_buf);  
    }  
    else  
    {  
        log("未识别的消息类型%s\n", msg_type);  
    }  
}  
上面的消息类型取自sip协议(不完全相同,sip协议借鉴了http协议),消息类型可能还会增加。
看着常常的流程可能有点累,检测一下中间某个消息有没有处理也比较费劲,
而且,没增加一个消息,就要增加一个流程分支。

按照数据驱动编程的思路,可能会这样设计:

typedef void (*SIP_MSG_FUN)(const char *);  
  
typedef struct __msg_fun_st  
{  
    const char *msg_type;//消息类型  
    SIP_MSG_FUN fun_ptr;//函数指针  
}msg_fun_st;  
  
msg_fun_st msg_flow[] =  
{  
        {"inivite", inivite_fun},  
        {"tring_100", tring_fun},  
        {"ring_180", ring_180_fun},  
        {"ring_181", ring_181_fun},  
        {"ring_182", ring_182_fun},  
        {"ring_183", ring_183_fun},  
        {"ok_200", ok_200_fun},  
  
        。。。。。。  
        {"fail_486", fail_486_fun}  
};  
  
void msg_proc(const char *msg_type, const char *msg_buf)  
{  
    int type_num = sizeof(msg_flow) / sizeof(msg_fun_st);  
    int i = 0;  
  
    for (i = 0; i < type_num; i++)  
    {  
        if (0 == strcmp(msg_flow[i].msg_type, msg_type))  
        {  
            msg_flow[i].fun_ptr(msg_buf);  
            return ;  
        }  
    }  
    log("未识别的消息类型%s\n", msg_type);  
}  

下面这种设计思路的优势:

1、可读性更强,消息处理流程一目了然。
2、更容易修改,要增加新的消息,只要修改数据即可,不需要修改流程。
3、重用,第一种方案的很多的else if其实只是消息类型和处理函数不同,但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来,而把容易发生变化的部分提到外面。

隐含在背后的思想

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

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

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

3、机制和策略的分离。和第二点很像,本书中很多地方提到了机制和策略。上例中,我的理解,机制就是消息的处理逻辑,策略就是不同的消息处理。这和 UNIX 哲学之一「提供机制,而不是策略」是相吻合的,因为策略经常改变,而机制相对固定,在数据驱动编程中我们就可以使用数据来应对「策略」的变化,而使用数据驱动编程实现的程序就可以看做是我们所提供的「机制」。

小结

1.它不是一个全新的编程模型,它只是一种设计思路,而且历史悠久,在unix社区应用很多;
2、它不同于面向对象设计中的数据:“数据驱动编程中,数据不但表示了某个对象的状态,实际上还定义了程序的流程;
  OO看重的是封装,而数据驱动编程看重的是编写尽可能少的代码。”

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 119,234评论 16 133
  • L/2016-5-19 我是一个脸盲,所以一个月的时间我还是认不了中队的所有人,也大概是因为志不在此。 手机会收到...
    MY林小妖阅读 151评论 2 2
  • 下班取完快递回来想到是周末就想着去网咖玩几局游戏,就在去的路上买了份蛋炒粉外加两个绝味鸭头,开完机坐在那开电脑边吃...
    邱读书阅读 541评论 0 3