chenyongguang
2005-12-26 09:54
to banq,banq老师,能否将您上次讲的公文流转的例子讲的再详细些,目前正在做些这方面的尝试,很多地方理解的不太好.特别是StateOwner这个对象的作用不是太理解,能否给出代码并解答,实在是不胜感激啊!

banq
2005-12-26 10:06
具体研究可看看工作流方面的东西，基于状态模式，但是更大，有个开源osworkflow还是不错。

chenyongguang
2005-12-26 10:41
to banq,
谢谢banq老师的这么迅速的回复。有个疑问还想请教您。我觉得各个状态转换应该有用户的参与，在上面的讨论中，用户好象没有提及（还是被Event代替？即使是被event代替的话，event中也应该要包含用户信息啊，不知这样的理解对不对？）。如果用户信息要被加入，是放在State的各个子类中还是放在Event里？是设置为一个actor还是一个role?谢谢！

banq
2005-12-27 10:25
>状态态转换应该有用户的参与
注意耦合，状态模式的特点就是用事件作为输入信号，状态作为输出信号，而事件的发生则是由用户触发的：

用户---->事件--->状态。

所以用户离我们讨论的状态模式很远，不用拉进来。

chenyongguang
2005-12-28 09:26
to banq,
谢谢banq老师。banq老师在前面谈到怎样将状态机与应用逻辑解耦。但在实现时，状态机又必须跟应用逻辑结合，特别是状态机进行状态切换的时候，需要访问相关的应用数据。比如一个会议室的申请流程，如何实现状态机与应用数据的交互？

chenyongguang
2005-12-28 09:30
to banq,
是通过事件或参数来向实例化后的状态机传递相关数据吗？如果是，还请banq老师详加指点一二。谢谢

banq
2005-12-28 10:12
你的问题是一种实际中经常遇到的解耦问题：

本帖开始时的代码transition中一段代码
State currentState = readCurrentState(taskid); //从数据库获得当前状态

实际就是和业务逻辑发生关系，通过依赖或关联关系可和业务逻辑层进行交互，当然，之间最好是面向接口的。

chenyongguang
2005-12-28 21:40
通过banq老师的多次指点，今天终于在前面介绍的思想和部分代码的基础上实现了一个非常简单的工作流状态机，是一个有关会议室申请的流程，在这里非常感谢banq老师和其他的jdon道友。但同时也对前面一个道友谈到的观点深有体会，就是状态太多了。（我设计了一个State,下面有许多具体子类，比如Committed,Passed,Finished之类），如下图。


有没有更好的方法？另外，比如公文发文流程，它一般有拟稿、核稿、批准、归档等状态，这些状态是不是又要重写？还是可以复用会议室申请的那个工作流状态机？也就是说可不可以抽象出一个一般工作流状态机，然后根据具体应用逻辑，在实例化成会议室申请状态机、公文发文状态机、物品领用状态机之类的？

chenyongguang
2005-12-28 21:44
这里特别想请教一下的是，对公文发文流程中的会签操作，该怎么处理？感觉很难啊，敬请指教！

banq
2005-12-29 09:41
状态机可以细化，分类成很多。

图画得不错，如果使用UNML的状态图就不感觉那么“飞舞”了

chenyongguang
2005-12-29 15:06
to banq,
我用的是visio的数据流状态图，本来是准备用visio里面的UML状态图的。还请banq兄不要避重就轻，对我的疑问要详加解释才是啊，哈哈！

tuzhihai
2006-04-28 11:43
但对于下列情况该如何描述：
假设一个对象处于正在执行状态，其要做的事是与另一个系统通信，这个通信可能成功也可能失败，如果成功，该对象应处于完成状态，如果不成功，该对象应该处于失败状态。
这种情况如果用单一的FROM_STATE--EVENT--TO_STATE该如何表达？

greki
2010-03-17 17:14
2003年12月07日 00:10 "banq"的内容
public State next(Event e) { if(transitions == null){ addEventState(new EventImp("PAUSE"), new Suspended()); addEventState(new EventImp("END"), new Completed()); addEventState(new EventImp("STOP"), new Aborted()); } return super.next(e);


这里有点不解，既然我已经知道了Event，何必要把该状态的后续可能的事件和状态都new出来。
另外请教下事件的处理（事件处理的逻辑，比如该表数据啊之类操作）是不是在event类里做。
不知道是不是哪里理解错了

banq
2010-03-17 17:19
2010年03月17日 17:14 "greki"的内容
已经知道了Event，何必要把该状态的后续可能的事件和状态都new出来

事件导致状态，这是一个问题的两个方面，什么事件导致什么状态，有一个规则在里面，这样，我们就有了三种对象：事件 状态和状态转换规则。

状态模式封装了状态和状态转换规则，状态机输出的是状态，事件是状态机的输入。

greki
2010-03-18 11:50
banq您好，非常感谢回复，我思路有点混乱，还有疑惑想请教，

事件--》新状态 的变化过程中
在实际应用中往往带有不同的【数据输入和逻辑处理】，在哪里带入数据和封装处理逻辑比较好？
我打比方，比如我是订单系统，从（未受理)--->受理--->（已受理）过程，需要 带入受理人等数据 和受理逻辑处理
按您说的
【状态模式封装了状态和状态转换规则】
是不是 通过 Event 带入数据，在 State子类里封装处理逻辑。
还是数据在stateOwner带入，在 State子类里封装处理逻辑。

猜你喜欢
有3页 Go 上一页 1 2 3 下一页