继上篇博客
上篇博客我们将现有的实现介绍了一番。不知道大家有没有发现问题，也有可能由于我并没有贴上对应的代码，大家非常难理解。以下我来说明一下：
首先说。之前的那种方式是实现了工作流类似的功能，可是它的实现方式，却没有做到灵活，而是加强了和业务的耦合，并且并没有实现工作流管理业务。
我们一再强调。工作流管理业务。每一个工作流结点并不知道业务须要做什么，每一个结点也不知道要实现什么功能。这一切的操作都要看业务给了我们什么，当业务结点扔到工作流程中，那么业务就被工作流管理起来了，而业务要实现的功能由业务提供。
事实上这也就是说我们常说的托付实现。我们不再靠强耦合去调用对应的方法，而是在于业务主动向外提供给我们什么服务。
这样的方式的实现更强调实现流程的复用。以及工作流管理业务。
即我画好一个流程图，那么他的结点个数已经确定。而此时业务和这个结点绑定什么业务。那么这个结点就实现什么功能，这时我们不但结点复用，并且流程相同能够复用
对照前后两种方式的差别：
之前方式：
长处：
1。对于已经使用工作流的业务。应对业务变更不须要编写不论什么代码
缺点：
1。业务和工作流的方法全然耦合在一起，仅仅是将工作流的方法单独抽象来了一个类而已。当然实现功能是没有问题，并且全部的业务仅仅要是继承我们抽象出来的工作流方法就能够非常好的共用这套方法，可是这就须要我们业务要懂得我们抽象出来的方法的含义
2，不能实现整个流程的复用。由于和业务的耦合
3，之前的方式更强掉的是业务的变更。（对于已经使用工作流的业务的变更，假设是之前并没有使用工作流，后来想要应用的话，维护非常不便。由于和业务的耦合）
4，并没有体现出工作流管理业务
5，不能应对扩展
思考：
改进方式：
抽象出来单独的结点池，全部的业务都使用使用这些结点池中的结点，对于详细业务要什么通过托付的方式实现！
//结点池1
publicvoid test1(){
//启动流程
//调用托付
//调用完毕当前结点
}
//结点池2
publicvoidtest2(){
//调用托付）
//调用完毕当前结点
}
长处：
1。实现流程的复用
2，真正做到和详细业务解耦
3。扩展方便
4，由工作流管理业务（开发结点池。仅仅要是使用工作流，那么它的结点池就已经设置好了运行过程）
5，当然也能应对业务的变更
总的来说。尽管第一种方式实现了业务的变更，可是这并非工作流出现的核心目的，这不过应用工作流的第一步，随着我们对工作流的理解我们应该将它应用的更加淋漓尽致。
当然也非常有可能。到如今我们的理解还不是非常透彻，还不是非常成熟，这都是学习的一个过程，在实践中再不断完好。