关于可配置工作流的一点想法

最近有些重构的工作，过程中在考虑能不能除了页面部分的代码消除重构以外，将流程什么的也提炼出来一点。

以前做c语言练习的时候，曾经有过这样的想法。

那是一个通信程序，简单的客户端和服务器端，发送和接收信息，类似一个聊天室。

当时我希望程序可以灵活的配置，因此把一个程序分成了好多部分，然后都通过socket来链接，建立链接的参数由shell脚本来控制。

我给这个程序起名字叫bamboo，呵呵，一节一节的，很形象。

编写过程中思考过怎么样将不同的部分链接起来，考虑到的主要有下面几点：

1.为了做到能灵活的控制程序的行为，每个程序对外的接口需要一致

2.每个程序都很简单，只做一件事

3.数据流入某一节的时候和流出那一节时要是不变的

4....当时可能还想到别的什么，但是现在不记得了。

编写代码时，我想着尽量满足上面几点要求，但是编写过程中确实碰到不少困难，结果程序写完，机构大概是这样的：

Pro 1>从一个监听一个socket，从中读取信息

Pro 2>将内容打印在屏幕上

Pro 3>从终端读入输入信息

Pro 4>将消息通过socket传送出去

Pro 5>分析信息，转发信息

好像是有这么几个程序，一开始想着，服务器和客户端能共用socket接收和发送的程序，只需要更改中间的部分就能让程序的功能改变

但是执行过程中并没有我想象中那么简单，服务器和客户端的接收发送程序随让功能差不多，但是其中有很多细微的差别，就因为这些细微的差别，我不得不权衡处理

是修改每个程序接口的规范还是重新写一段程序

如果修改了接口的规范，则很可能接口中的某个参数只是为这个程序特别设置的，在其他地方完全用不到，一方面占资源，一方面不容易理解

但是如果重新写一段程序的话，设计成这样的结构的意义就完全没有了。。。

嘿嘿，后来具体的实现有些记不清楚了。

最近又开始考虑类似的事了

感觉关于可配置流程的之类的设计上总是存在矛盾，如果要做的灵活，则很可能需要保证入口和出口的一致性，而且最好是无状态的

应该很显而易见——完全用这种设计的话不太现实。

就像函数式编程，纯函数式编程虽然非常优美，可以避免bug，但是由于完全没有副作用，做出来的程序也几乎没有什么实用价值

根据我写那个通信程序的经验，应该除了能配置一个程序进去来打印log之外，没有太多可以扩展的东西（现在想起来有点像面向切面编程），如果想加点更酷的功能的话马上就会需要修改接口

我想现在我重新来写那个通信程序的话，应该设计上会更好一些，但是还是无法解决接口简洁统一和需求多种多样之间的矛盾

前一阵看了《land of lisp》，有些小小的启发

纯的函数式编程很难满足我们的需要，但是这并不说明这个思想没用

我们可以通过尽量将有副作用的代码和无副作用的代码分离开，以达到减少bug的目的

了解了这些之后，对于现在这个需要做流程控制的需求，我有了些新的想法：

在提供统一接口的同时，提供一些附属物，用以表示状态，特需的参数之类的东西

这样不免牺牲了一些灵活性，现在每个节点并不是想原来理想状态下一样，可以任意搭配，有了状态，附属参数之后，每个节点的前驱节点和后继节点就有了一定的范围，这样所有节点连起来就成了一个有向无环图（无环最好了~但我觉得很难避免出现环），只要是遵循这个图的流程就可以无障碍的添加或裁减流程，途中任意两个联通的节点都可以单独拉出来做一个流程，能很方便的做成可配置的

通过附加物来实现流程的可扩展性，通过提炼一个通用的接口来提高流程的灵活性

说不定这个想法也有些幼稚，还没深入了解过jbpm之类控制流的思想，不过有自己的想法总是好的嘛~

目前还只是一个想法，之后再多想想，实践一下。