OSWorkflow深入分析 － 重新定义Configuration接口

在OSWorkflow中最让人恼火的就是它的接口定义！我会就这些接口的混乱展开一系列的分析，今天先说说Configuration接口

偶继承了它的Configuration接口

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.Configuration;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IConfiguration extends Configuration
{
 /**
  * @deprecated getIWorkflowStore()
  */
    WorkflowStore getWorkflowStore() throws StoreException;
   
    /**
     * return WorkFlowStore which implements the interface of IWorkFlowStore
     * @return
     * @throws StoreException
     */
    IWorkFlowStore getIWorkflowStore() throws StoreException;
   
}

你可能奇怪我为何要继承它的接口（肯定是Bad smell），原因如下，

IWorkFlowStore 接口定义

import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.spi.Step;
import com.opensymphony.workflow.spi.WorkflowEntry;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IWorkFlowStore extends WorkflowStore
{
 
 public Step createCurrentStep(WorkflowEntry _entry , Step _step) throws StoreException;

}

WorkflowStore接口定义

    /**
     * Persists a step with the given parameters.
     *
     * @param entryId The workflow instance id.
     * @param stepId the ID of the workflow step associated with this new
     *               Step (not to be confused with the step primary key)
     * @param owner the owner of the step
     * @param startDate the start date of the step
     * @param status the status of the step
     * @param previousIds the previous step IDs
     * @return a representation of the workflow step persisted
     */
    public Step createCurrentStep(long entryId, int stepId, String owner, Date startDate, Date dueDate, String status, long[] previousIds) throws StoreException;

看到了吧？

其实我只是希望在createCurrentStep时按照OO的方法执行，而不是传递那些"Bad Smell"的参数，而OSWorkflow中的WorkflowStore是需要Configuration来获取的，此时为了增加一个看似合理的方法，需要分别继承Configuration与WorkflowStore；这还没有完，你需要实现一个Configuration实现！！

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.DefaultConfiguration;
import com.opensymphony.workflow.spi.WorkflowStore;

public class DefaultIConfiguration extends DefaultConfiguration implements IConfiguration
{
 
    public static DefaultIConfiguration INSTANCE = new DefaultIConfiguration();
    private transient IWorkFlowStore store = null;

 /**
  * @deprecated getIWorkflowStore()
  */
 public WorkflowStore getWorkflowStore() throws StoreException
 {
  return null;
 }

 public IWorkFlowStore getIWorkflowStore() throws StoreException
 {
  if (store == null)
  {
   String clazz = getPersistence();

   try
   {
    store = (IWorkFlowStore) Class.forName(clazz).newInstance();
   }
   catch (Exception ex)
   {
    throw new StoreException("Error creating store", ex);
   }

   store.init(getPersistenceArgs());
  }

  return store;
 }

}

总结

1。OSWorkflow与WorkflowStore接口的关系比较的微妙，它需要借助于Configuration接口的实现来获取到实际的WorkflowStore对象。

2。由于这样的一种微妙关系，对WorkflowStore接口的扩展必将连带着需要扩展Configuration接口，而产生这样的"果冻效应"的罪魁祸首就是由于WorkflowStore接口与Configuration接口耦合的太紧。

3。OSWorkflow并没有很好的遵守OO的设计规则，尤其在它的参数传递上，非常的差！