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

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

以前做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之类控制流的思想,不过有自己的想法总是好的嘛~

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


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值