canonical

    现在很多设计中推崇接口和依赖注入(dependency injection)，而不倾向于采用继承机制来构造程序结构。但很多时候作为一种简便而廉价的封装方法,继承仍然是不可或缺的. 例如与一些Engine打交道的时候,需要实现某些特定的接口. 在osworkflow中, 我们需要实现FunctionProvider接口,
     interface FunctionProvider{
        void execute(Map transientVars, Map args, PropertySet ps) throws WorkflowException;
     }
    在Quartz中需要实现Job接口
      interface Job{
          public void execute(JobExecutionContext context) throws JobExecutionException;
      }
    这些接口是一种技术性的要求, 它们表示了代码生存所依赖的技术环境. 为了屏蔽这种对于外部引擎的依赖, 我们可以简单的选择实现一个基类,
    abstract class AbstractFunction implements FunctionProvider,Runnable{
        Map transientVars;
        Map args;
        PropertySet ps;

        public final void execute(Map transientVars, Map args, PropertySet ps){
            this.transientVars = transientVars;
            this.args = args;
            this.ps = ps;
            run();
        }

        public Object getPersistVar(String name){
           return ps.getAsActualType(name);
        }

        public void setPersistVar(String name, Object value){
           ps.setAsActualType(name,value);
        }

        public void removePersistVar(String name){
           ps.remove(name);
        }
    }
    在派生类中我们只要使用getPersistVar等函数就可以回避对于osworkflow特有的PropertySet类的依赖，而只在概念上需要一 个对象的持久化机制．当我们把业务代码从osworkflow移植到其他工作流引擎的时候，　只需要改变一下基类即可．我们可以在基类中引入更加特殊的假 设，
    abstract AbstractBusinessFunction extends AbstractFunction{
        public BusinessObject getBusinessObject(){
            return transientVars.get("businessObject");
        }

        public void commonBusinessOp(){ ... }
    }

    AbstractBusinessFunction提供的可以是一个完整的业务对象环境，　我们在派生类中的所有代码都可以是与业务直接相关的，而与具体 的技术实现无关（例如业务变量是存放在transientVars中还是存放在args中）

    class BusinessFunction extends AbstractBusinessFunction{
        public void run(){
            BusinessObject bo = getBusinessObject();
            bo.methodA();
            commonBusinessOp();
        }
    }
    对于我们来说实际有意义的是在派生类中所书写的代码，基类仅仅提供一个环境而已．无论我们使用Ioc注入业务变量还是从transientVars中主动 获取业务变量，都是与我们的业务操作无关的．　实际上在理论上我们希望整个基类都可以是注入的（包括业务变量和业务操作），在泛型编程中这对应于所谓的 policy class.