Template method vs Callback模式

最新推荐文章于 2024-07-19 08:49:43 发布

原创最新推荐文章于 2024-07-19 08:49:43 发布 · 1.4k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#callback #interface #object #service #jaxb #xml

J2SE 同时被 2 个专栏收录

12 篇文章

订阅专栏

Design Pattern

10 篇文章

订阅专栏

本文通过一个具体案例对比了模板方法模式和回调模式的应用场景。在处理固定流程时，模板方法简化了重复步骤，但在某些情况下可能导致类过于细化。而回调模式提供了更高的灵活性，尤其适用于操作较少的场景。

Template method vs Callback
以前曾在《也谈谈Spring中的Template和Callback模式》中谈过这两个模式的实用场合，那时候没有给出代码。
最近遇到一个问题，可以很好的说明这两种模式的使用场合。
需求：我暑假实习公司做的一个产品，我们Server组主要事情是：一、把页面的信息组装成DTO,使用JAXB技术
将定义的消息格式(xml schema)自动生成对应的Object,把DTO装配对应的Object，然后marsh成xml(JAXB是什么
东东可以参见以前我写的《尝试了一下JAXB2.0》)，最后把消息发送给Client端。二、从Client端接收到xml,然
后unmarch成Object,然后把Object装配成DTO，最后传到页面，来设置页面。
我们可以看到整个过程非常的固定，无非是Send还是Get信息的问题。所以我们很容易想到使用摸版来解决，事实上我们最常用的Servlet也是这两种过程Post和Get,它同样使用了摸版方法。
举一个例子，一个Site里有许多Rules,我们要操作Rules（例如增删改之类的操作），不同的操作过程可能不同，
例如新增一个Rule,我们只需要做上面说的第一件事情，而如果要修改Rule则两件事情都要做。我们现在就用模版
方法来实现：

public interface CAIBaseService{
       public String send(long agentId, String fullPath, int typeId,Object dto);
       public Object get(long agentId,String fullPath,int typeId);
}

public class CABaseServiceTemplate implements CAIBaseService{
    public String send(long agentId, String fullPath, int typeId,Object dto){
            RequestBean reqBean = doPrepareToSend(agentId,fullPath,typeId,dto);//把dto装配成Object[requestBean]
            Response response = doProcessRequest(reqBean);//真正把xml发送给Client端，这个过都是一样的，可以抽象出NetworkService来处理
            return doProcessSendResponse(response);//处理返回的response,例如根据response判断是否发送成功，以及失败的原因
    }
    public Object get(long agentId,String fullPath,int typeId){
           RequestBean reqBean = doPrepareToGet(agentId,fullPath,typeId);//装配成Object[requestBean]的根，这样Client就知道消息是什么类型的，从而设置信息返回
           Response response = doProcessRequest(reqBean);//真正把xml发送给Client端，这个过都是一样的，可以抽象出NetworkService来处理
           return doProcessGetResponse(response);//处理返回的response,例如把response装配成Dto,判断是请求否发送成功，以及失败的原因
    }
    protected RequestBean doPrepareToSend(long agentId, String fullPath, int typeId,Object dto);
    protected String doProcessSendResponse(Response response);
    protected RequestBean doPrepareToGet(agentId,fullPath,typeId);
    protected Object doProcessGetResponse(Response response);
}
//    对于Rule
class AddRuleServiceImpl extends CABaseServiceCallbackTemplate {
     protected RequestBean doPrepareToSend(long agentId, String fullPath, int typeId,Object dto){
      //...
     }
     protected String doProcessSendResponse(Response response){
      //...
     }
           protected RequestBean doPrepareToGet(agentId,fullPath,typeId){
     //因为我们不需要这个操作所以，空实现
     }
     protected Object doProcessGetResponse(Response response){
     //因为我们不需要这个操作所以，空实现
     }
    }

class EditRuleServiceImpl extends CABaseServiceCallbackTemplate {
    protected RequestBean doPrepareToSend(long agentId, String fullPath, int typeId,Object dto){
      //...
    }
    protected String doProcessSendResponse(Response response){
      //...
    }
    protected RequestBean doPrepareToGet(agentId,fullPath,typeId){
     //...
    }
    protected Object doProcessGetResponse(Response response){
     //...
    }
}

我们发现对于一个Rule就需要三到四个Service,Service的粒度显得有点太细，因为我们我们继承了CABaseServiceCallbackTemplate，我们Service的粒度已经由CABaseServiceCallbackTemplate

控制了，
这就是继承的不灵活性，同时我们看到我们在AddRuleServiceImpl中还需要空实现两个方法，当然我们
可以继续对CABaseServiceCallbackTemplate封装出一个新的Template，将他们都默认空实现了CABaseServiceCallbackTemplate未实现的方法，这样我们在AddRuleServiceImpl就不需要空实现了，

另外，
doPrepareToSend，doProcessSendResponse到底是干什么的(由于Send方法在CABaseServiceCallbackTemplate
定义的)，别人头一次看说不定发甍。综上，在这里使用Template　method模式，产生了过于琐碎的类，并且
显得不够直观。
下面我们考虑使用Callback模式来实现，来避免上面的问题：

public interface CAIBaseService{
       public String send(long agentId, String fullPath, int typeId,Object dto);
       public Object get(long agentId,String fullPath,int typeId);
}

public interface CAProcessSendResponseCallback{
        RequestBean doPrepareToSend(long agentId,String fullPath,int typeId,Object dto);
}

pubilc interface CAProcessSendResponseCallback{
    String  doProcessSendResponse(Response response);
}

public interface CAPrepareToGetCallback{
    RequestBean doPrepareToGet(long agentId,String fullPath,int typeId);
}

public interface CAProcessGetResponseCallback{
    public Object doProcessGetResponse(Response response);
}

public class CABaseServiceCallbackTemplate implements CAIBaseCallbackService{
      public String send(long agentId, String fullPath, int typeId,Object dto,
               CAPrepareToSendCallback prepareToSendCallback,CAProcessSendResponseCallback processSendResponseCallback){

          RequestBean reqBean = prepareToSendCallback.doPrepareToSend(agentId,fullPath,typeId,dto);// 把dto装配成Object[requestBean]
          Response response = doProcessRequest(reqBean);// 真正把xml发送给Client端，这个过都是一样的，可以抽象出NetworkService来处理
          return processSendResponseCallback.doProcessSendResponse(response);// 处理返回的response,例如根据response判断是否发送成功，以及失败的原因
      }
     public Object get(long agentId,String fullPath,int typeId,CAPrepareToGetCallback prepareToGetCallback,
             CAProcessGetResponseCallback processGetResponseCallback){
                RequestBean reqBean = processSendResponseCallback.doPrepareToGet(agentId,fullPath,typeId);// 装配成Object[requestBean]的根，这样Client就知道消息是什么类型的，从而设置信息返回
             Response response = doProcessRequest(reqBean);// 真正把xml发送给Client端，这个过都是一样的，可以抽象出NetworkService来处理
             return processSendResponseCallback.doProcessGetResponse(response);// 处理返回的response,例如把response装配成Dto,判断是请求否发送成功，以及失败的原因
     }
    }

    public class CASiteRuleManageServiceImpl {
         private CABaseServiceCallbackTemplate caBaseServiceCallBackTemplate;

         public CASiteNewRuleDto getEditRuleInfo(long agentId, String fullPath, int typeId) {
               return (CASiteNewRuleDto)caBaseServiceCallBackTemplate.get(agentId, fullPath, typeId,new CAPrepareToGetCallback (){
                     public RequestBean doPrepareToGet(long agentId, String fullPath, int typeId){
                              // ...
                     }
                }
               ,new CAProcessGetResponseCallback (){
                     protected Object doProcessGetResponse(Response response){
                        // ...
                     }
               }
          );
     }

     public String sendEditRuleInfo(long agentId, String fullPath, int typeId, CASiteNewRuleDto dto) {
      return caBaseServiceCallBackTemplate.send(agentId, fullPath, typeId, dto, new dto,CAPrepareToSendCallback() {
              public RequestBean doPrepareToSend(long agentId, String fullPath, int typeId,Object object){
                  // ...
              }
             },
               new CAProcessSendResponseCallback(){
                     public  String doProcessSendResponse(Response response){
                          // ...
                     }
               }
             );
     }

     public String sendAddRuleInfo(long agentId, String fullPath, int typeId, CASiteNewRuleDto dto) {
           return caBaseServiceCallBackTemplate.send(agentId, fullPath, typeId, dto, new dto,CAPrepareToSendCallback() {
                   public RequestBean doPrepareToSend(long agentId, String fullPath, int typeId,Object object){
                       // ...
                   }
                },
                new CAProcessSendResponseCallback(){
                   public  String doProcessSendResponse(Response response){
                         // ...
                   }
                }
            );
// ...other operation
    }
}

我们发现使用Callback模式，我们可以把对Rule的操作组织成一个Service,避免产生大量的Service,同时我们可以随意使用Get和Send操作，而不象Template　method受缚于上层定义步骤，以及要实现的方法，同时我们可以给Service的方法很好的命名（例如sendAddRuleInfo），从而使得程序更加清晰。唯一的不完美的地方是使用了内部匿名类，给程序的阅读带来点困难，当然可以用内部类来代替匿名的，但大家似乎更习惯使用匿名内部类，如果Java象Ruby那样能够支持block就好了（Java 7据说要支持closure,但由于Java历史的包袱太重，实现是何等的丑陋，非泛型所能比--Java为了向前兼容，泛型的实现实在难以和c++和c#相比）。
从上面分析可以看到如果不是真正的"is-a"关系的话,组合优于继承绝对是至理名言，继承就会对子类有所限制，而组合则没有什么限制，显得更加灵活。一般情况下如果一个操作的子步骤比较少（三个以下），特别是如果你不想生成太细粒度的对象时，用Callback来代替template method能够获得更好的灵活性，子步骤多则使用template method.