月下无限连？拒绝无休止switch！

拒绝无休止switch

---

一、前言

　　前天碰到个需求，其实很简单，就是Excel导入，Excel模板长下面这样：

　　

　　按我平常的逻辑是这样做的：

• 　　用文件输入流读取Excel，根据Excel的版本生成不同的对象，比如XSSFWorkbook或是HSSFWorkbook
• new一个工作簿，读取内容
• 按行遍历，按cell单元格读取
• 读取到值后，根据业务逻辑进行处理，最后存入entity

　　这个需求按这个逻辑下来，循环取值的代码是这样的：

　　

 if (CollectionUtils.isNotEmpty(rowList)) {
     List<DtTableCheck> data = Lists.newArrayList();
     Map<String, String> paramValueMap;
     for (int i = 0; i < rowList.size(); i++) {
         paramValueMap = Maps.newLinkedHashMap();
         DtTableCheck dtc = new DtTableCheck();
         for (Entry<String, String> entry : rowList.get(i).entrySet()) {
             switch (entry.getKey().trim()) {
                 case "检查编号":
                     //一堆业务处理
                 case "数据库":
                     //一堆业务处理
                 case "表":
                     //一堆业务处理
                 case "限制条件":
                     //一堆业务处理
                 case "检查规则":
                     //一堆业务处理
                 case "参数1":
                     //一堆业务处理
                 case "参数2":
                     //一堆业务处理
                 case "参数3":
                     //一堆业务处理
                 case "参数4":
                     //一堆业务处理
             }
         }
         data.add(dtc);
     }

注：原先的代码过于丑陋，所以用了我司封装的方法，将Excel内容读取到一个list中，再循环读取，可以看到代码依然冗长

　　这样做有一个问题，如果Excel模板变动或是业务逻辑变动，会牵一发而动全身，后端代码都要改，而且这样的代码可维护性极差，典型的面向过程编程。

　　于是，趁着周末，借助策略模式与工厂模式的思想，赶紧重构了代码。

---

二、重构

　　代码中重复的操作是频繁的根据Excel单元格名称去switch不同的处理逻辑，那我们把它抽离出来，即

　　

 /**
  * 解析Excel数据
  * @Author Cone
  * @Date 2019/12/7 12:39
  */
 public interface dealExcel {

     void deal(Map.Entry<String, String> entry, DtTableCheck dtc);
 }

　　传入map中的一个要素，和需要操作的entity，具体的业务处理由不同的实现类去做。

　　接下来我们写一个工厂，用来返回不同的实现类：

　　

 /**
  * @Author Cone
  * @Date 2019/12/7 12:49
  */
 public class dealFactory {

     private static Map<String, dealExcel> dealMaps = Maps.newConcurrentMap();

     public static dealExcel create(String name) {
         return dealMaps.get(name);
     }

     public static void register(String name, dealExcel de) {
         dealMaps.put(name, de);
     }

 }

　　dealMaps用来保存字段名称（比如检查编号、数据库、表等）和对应的操作实现类，create()方法根据传入的字段名称返回对应的实现类，register()方法则将字段名称与实现类保存到dealMaps中供我们调用。

　　这样听起来好像没什么问题，但是我什么时候注册这个实现类到dealMaps中去呢？我们以一个实现类来举例：

　　

 /**
  * 处理限制条件字段
  * @Author Cone
  * @Date 2019/12/7 13:16
  */
 @Service
 public class dealQueryCondition implements dealExcel, InitializingBean {
     @Override
     public void deal(Map.Entry<String, String> entry, DtTableCheck dtc) {
         dtc.setQueryCondition(null == entry.getValue() ? null : entry.getValue().trim());
     }

     @Override
     public void afterPropertiesSet() throws Exception {
         dealFactory.register("限制条件", this);
     }
 }

　　这个实现类用来处理 Excel中 “限制条件”这一字段，我们在deal()方法中去完成具体的处理逻辑。接下来重点来了，可以看到，这个类还实现了一个接口，即InitializingBean，它是Spring提供的，这个接口里面有一个方法afterPropertiesSet()，用来做属性初始化后的相关操作，凡是继承该接口的类，在bean的属性初始化后，都会执行该方法，我们这里将实现类注册进去。

　　接下来就很简单了，只需要根据业务去完成实现类即可。这样改造完后，程序的调用是这样的：

　　

 List<Map<String, String>> rowList = ExcelHelper.readExcelSheet(file.getPath());
 if (CollectionUtils.isNotEmpty(rowList)) {

     for (int i = 0; i < rowList.size(); i++) {
         DtTableCheck dtc = new DtTableCheck();
         for (Entry<String, String> entry : rowList.get(i).entrySet()) {
             dealExcel de = dealFactory.create(entry.getKey());
             de.deal(entry, dtc);
         }

     }

 }

　　rowList即为Excel中的数据，数据按行存入list，每一行的数据被放入map中，类似这样：

　　

 [
   "检查编号":value,
   "数据库":value,
   "限制条件":value
 ]

　　改造后的效果不用我多说了。

---

三、结语

　　我之所以要改造原有代码是因为这个需求在不断变化，模板也在调整，但是如果Excel本来就2,3个字段，或者业务变动不大，那我觉得就没有必要做改造了，改造成本，开发效率需要自己去权衡。运用设计模式应该让代码更好维护，而不是更糟，对吧。