行为的封装——模式系列谈之Command模式

                                     行为的封装——模式系列谈之Command模式
 
     解决一个问题，我们总是先将这个问题进行分解，分解成为很多小块，或者方面；然后我们关注问题的每一个方面，将他们一一解决；最后完成了对整个问题的解决。在我们的模式的解决思路中，都贯穿了这种思想。模式总是不厌烦的将各种依赖进行解耦，然后去关注问题的各个方面。
     一般说来，Command模式可以从以下两个方面进行理解：
     第一，Command模式成功的对行为和行为的调用者之间进行了解耦，解除了行为和其调用者之间的依赖，让调用者依赖行为的接口，符合了依赖颠倒原则。这无疑使得代码的扩展性有了很大的提高。
     第二，Command模式对对象的行为进行了分解，让我们对对象的各个行为一一关注，然后完成对对象的关注。
     现在我们来看一个Command模式的简单例子：
 package command;
 
 public interface Command {
  public void doCommand();
 }
    这是行为的接口，行为的调用者只需要直接和它打交道。
    行为的实现：
 package command;
 
 public class OnCommand implements Command {
  public void doCommand()
  {
   System.out.println("The light is turning on……");
  }
 }
 
 package command;
 
 public class OffCommand implements Command {
  public void doCommand()
  {
   System.out.println("The light is turning off……");
  }
 }
 Command模式将行为封装在类里，适用于在对对象的行为特别关注的场合。
 测试代码：
 Command[] commands = Command[]{new OnCommand(),new OffCommand()};
 Int I=1;
 Commands[i].doCommand();
 测试结果：
 The light is turning off.…...
 上面只是一个最简单的Command模式的例子，只是用来我们对该模式作初步的理解。实际的Command模式的应该可没有这么简单。
 谈到Command模式，有些人一方面同意Command模式解耦了行为和行为的调用者之间的依赖；另一方面却抱怨Command模式使得简单问题复杂化，在他们看来，将这么多的行为独立出来，十分麻烦，换来的系统的扩展性未必用得上。果然事情是他们所想得那样吗？我们来看下面的例子：
public class DictionaryDetailAction extends BaseAction
{
 public ActionForward actionExecute(ActionMapping actionMapping, ActionForm actionForm,
            HttpServletRequest request, HttpServletResponse response)
 {
  DynaActionForm dictForm = (DynaActionForm)actionForm;
  String dictId = request.getParameter("dict_id");
  
  String action = request.getParameter("req_action");
    
  DictionaryManager dictManager = new DictionaryManager(getAdminFacade(),getTransactionManager());
  Object dictObj = dictForm.get("dictId");
  DictionaryData data = new DictionaryData();
  data.setDictID( StringUtils.strObjectToLong(dictObj) );
  String dictName = StringUtils.strObjectToString(dictForm.get("dictName"));
  String dictDesc = StringUtils.strObjectToString(dictForm.get("dictDesc"));
  data.setDictName(dictName);
  data.setDictDesc(dictDesc);
  
  logger.debug("DictionaryDetailAction................" + dictId);
  if(dictId == null || "".equals(dictId))
  {
   dictId = StringUtils.longToString(data.getDictID());
  }
  DictionaryData dict = dictManager.getDictionaryData(StringUtils.stringToLong(dictId));
  
  dictForm.set("dictId", StringUtils.longToString(dict.getDictID()));
  dictForm.set("dictName", dict.getDictName());
  dictForm.set("dictDesc", dict.getDictDesc());
  
  
  if(OperationConstants.OPERATION_UPDATE.equalsIgnoreCase(action))
  {
   try
   {
    dictManager.updateDictionaryData(data);
    logger.debug("updateDictionaryData");
   }
   catch(Exception e)
   {
    logger.error("actionExecute", e, "updateDictionaryData occur error");
    dictForm.set("dictName", ConversionResource.getGBStr(dictName));
    dictForm.set("dictDesc", ConversionResource.getGBStr(dictDesc));
    return actionMapping.getInputForward();
   }
  }
  else if(OperationConstants.OPERATION_ADD.equalsIgnoreCase(action))
  {
   logger.debug("OPERATION_ADD");
   dictForm.set("dictName", "");
   dictForm.set("dictDesc", "");
   
  }
  else if(OperationConstants.OPERATION_SAVE.equalsIgnoreCase(action))
  {
   DictionaryData data2 = dictManager.getDictionaryData(StringUtils.stringToLong(dictId));
   
   DictionaryData data3 = new DictionaryData();
   data3.setDictID((new Sequence()).getSequence(TableNameConstants.HR_DICTIONARY));
   data3.setDictName(dictName);
   data3.setDictDesc(dictDesc);
   data3.setParentDictID(ObjectUtils.stringToInt(dictId));
   data3.setModuleID(data2.getModuleID());
   data3.setCategoryID(data2.getCategoryID());
   
   try
   {
    dictManager.insertDictionaryData(data3);
    logger.debug("insertDictionaryData");
   }
   catch(Exception e)
   {
    logger.error("actionExecute", e, "insertDictionaryData occur error");
    dictForm.set("dictName", ConversionResource.getGBStr(dictName));
    dictForm.set("dictDesc", ConversionResource.getGBStr(dictDesc));
    return actionMapping.getInputForward();
   }
   dictForm.set("dictName", ConversionResource.getGBStr(dictName));
   dictForm.set("dictDesc", ConversionResource.getGBStr(dictDesc));
  }
  request.setAttribute("attr_action", action);
  
  return actionMapping.findForward("success");
 }
}

从上面的例子我们可以看到，笼统地将行为的实现放在客户端，会造成多方面的困惑：第一，编码的困难，外部变量对行为体的影响，可能在行为体内部使用了与外部相同的变量而不觉查；可能造成各个行为之间的相互混淆；等等一系列的问题。第二，调试的困难，在调试过程中，可能造成程序调试的混乱，你可能不知道程序跑到了那个行为体去了，等等。
 总之，将所有的行为混在了一起，容易造成思维的混乱。解决的办法还是需要我们将问题分解开来，我们需要一一关注每一个行为。而我们的Command模式恰恰很好地做到了这一点。
 首先，我们来给我们的行为定义一个接口：
 public interface WebAction
 {
   public ActionForward doAction(DictionaryData data, DictionaryManager dictManager, DynaActionForm dictForm,ActionMapping actionMapping);
 }
 
 然后，我们来实现各个行为：
 public class Update implements WebAction
 {
   public ActionForward doAction(DictionaryData data, DictionaryManager dictManager, DynaActionForm dictForm,ActionMapping actionMapping)
   {
   try
   {
    dictManager.updateDictionaryData(data);
    //logger.debug("updateDictionaryData");
    return actionMapping.findForward("success");
   }
   catch(Exception e)
   {
    //logger.error("actionExecute", e, "updateDictionaryData occur error");
    dictForm.set("dictName", ConversionResource.getGBStr(dictName));
    dictForm.set("dictDesc", ConversionResource.getGBStr(dictDesc));
    return actionMapping.getInputForward();
   }
 
 }
 }
 
 
 public class Add implements WebAction
 {
   public ActionForward doAction(DictionaryData data, DictionaryManager dictManager, DynaActionForm dictForm,ActionMapping actionMapping)
   {
   dictForm.set("dictName", "");
    dictForm.set("dictDesc", "");
   return actionMapping.findForward("success");
 }
 }
 
 
 public class Save implements WebAction
 {
   public ActionForward doAction(DictionaryData data, DictionaryManager dictManager, DynaActionForm dictForm,ActionMapping actionMapping)
   {
   DictionaryData data2 = dictManager.getDictionaryData(StringUtils.stringToLong(dictId));
   
   DictionaryData data3 = new DictionaryData();
   data3.setDictID((new Sequence()).getSequence(TableNameConstants.HR_DICTIONARY));
   data3.setDictName(dictName);
   data3.setDictDesc(dictDesc);
   data3.setParentDictID(ObjectUtils.stringToInt(dictId));
   data3.setModuleID(data2.getModuleID());
   data3.setCategoryID(data2.getCategoryID());
   dictForm.set("dictName", ConversionResource.getGBStr(dictName));
   dictForm.set("dictDesc", ConversionResource.getGBStr(dictDesc));
   try
   {
    dictManager.insertDictionaryData(data3);
    //logger.debug("insertDictionaryData");
    return actionMapping.findForward("success");
   }
   catch(Exception e)
   {
    logger.error("actionExecute", e, "insertDictionaryData occur error");
    dictForm.set("dictName", ConversionResource.getGBStr(dictName));
    dictForm.set("dictDesc", ConversionResource.getGBStr(dictDesc));
    return actionMapping.getInputForward();
   }
 }
 }
 
 
 public class NothingDo implements WebAction
 {
   public ActionForward doAction(DictionaryData data, DictionaryManager dictManager, DynaActionForm dictForm,ActionMapping actionMapping)
   {
   return actionMapping.findForward("success");
 }
 }
 
 这样我们可以看到，将各个行为独立出来以后，我们对各个行为进行了单独的关注，使得编码和测试都变得更为简单。这是Command模式带给我们的第一个好处。
 然后我们看看客户端的调用情况：
   WebAction command;
 if(OperationConstants.OPERATION_UPDATE.equalsIgnoreCase(action))
   {
    command = new Update();
 }
 else if(OperationConstants.OPERATION_ADD.equalsIgnoreCase(action))
  {
  command = new Add();
 }
 else if(OperationConstants.OPERATION_SAVE.equalsIgnoreCase(action))
 {
  command = new Save();
 }
 else
 {
  command = new NothingDo();
 }
 command.doAction();
 现在我们的客户端变得极为简单和清晰，我们的Command模式的确让我们的编码和测试简单起来；同时，她也给我们的系统的扩展带来了一定的可扩展性。如果我们要增加新的行为，就不需要在客户端大动干戈了，只需要增加一个行为类，然后到客户端作相应的改动。
 之所以说Command模式给我们的系统带来了一定的可扩展性，是因为客户端和行为的现实还存在一定的依赖，所以我们增加了一种行为，就不得不去对客户端进行相应的改动，虽然这种改动比不用Command模式小得多。
 到了这里，我们就一定会想，能不能将这种依赖关系完全去掉呢？我们说，当然可以。
 解决的办法是让Command模式结合Factory模式，这样使得客户端完全不依赖具体的行为。
 首先，我们来做一个工厂，让它来生产行为：
 public class Factory
 {
  public static WebAction getAtion(String name)
  {
   try
   {
    Class cls = Class.forName(name);
    Return (WebAction)cls. newInstance();
 }
 catch(Exception e)
 {
  return null;
 }
 }
 }
 
 然后我们在一个常量类OperationConstants里存储下列常量：
 final String PATH = “”;
 final String[] ACTIONNAMES = new String[]{“UPDATE”,”ADD”,”SAVE”};
 fianl String[] CLASSNAMES = new String[]{PATH+”Update”,PATH+”Add”,PATH+”Save”};
 
 最后客户端的代码为：
 for(int I=0;I< OperationConstants.ACTIONNAMES.length;I++)
 {
  if(OperationConstants.ACTIONNAMES[i]. equalsIgnoreCase(action))
  {
   Factory.getAction(OperationConstants.CLASSNAMES[i]).doAction();
   Break();
 }
 }
 这样就完全将具体的行为类和客户端解耦开来，如果我们需要增加一个行为delete的话，那么我们只需要增加一个Delete类来实现WebAction接口，然后在常量类里增加actionName和className到相应的常量里，而对客户端则无须做任何修改。