一种在旧代码上增加新需求的重构模式

Posted 2020-08-22

应用场景

相信大家遇到过这种场景：
旧代码中已经有一堆的if-else或者switch-case了；产品却要求在这段流程里增加一个新的功能。

这种时候大家会怎么做？
我的建议是：

重构这段代码。在重构的基础上，加入新的功能。

肯定会有人说：

工期本来紧张，再对原有代码进行重构，岂不会更加捉襟见肘？

这里介绍的（也是我在实践中经常使用的）这种方式，我称之为“接口-分发器模式”。它可以在尽量减少重构工作量的同时，完成大部分重构工作。

类图

接口-分发器类图

接口

这个模式首先将旧代码/功能抽取为一个接口（ServiceInterface.java）。这个接口的抽象能力，应该能够同时覆盖旧代码中的原有逻辑和新需求中的功能。换句话说就是新、旧代码都可以抽象为同一个接口。
如果这一点都无法做到，建议先回头想想这两段逻辑应不应该放到同一个抽象内。

例如我在一次重构中所做抽取的接口：

 

public interface RequestApprover {       void approveById(Integer id, Request requestInfo,             UserInfo approver) throws ServiceException; }

这个接口是对请求数据（Request）的审批操作的抽象。
请求数据一共有三类（其中旧类型两种，新需求一种）；审批操作同样也有三类（同样，旧类型两种，新需求一种）。这样，最多会有九种审批逻辑（不过实际中只有六种）。而这些审批逻辑和代码，都可以用这一个接口来描述。

分发器

分发器（ServiceDispatcher.java）是服务的入口。但它本身并不提供任何业务服务，而只负责将请求分发给实际的服务处理类。
从这一点上看，分发器其实很像一个工厂。这么说也没错，不过这个分发器的重点在于“分发”，而不是“创建”。
另外，将它隐藏在对外接口之下，是因为我将这个分发器理解为接口的一种实现；它属于抽象之中，不需要被抽象之外的调用者感知。这是我个人偏好。

对应前面的接口，我用到的分发器是这样的。

class RequestApproverAsDispatcher RequestApprover {     private RequestApprover approver4First4NotLate;     private RequestApprover approver4First4PseudoOver;     private RequestApprover approver4Final4NotLate;     private RequestApprover approver4Final4M1;     private RequestApprover approver4Final4PseudoOver;       @Override     public void approveById(Integer id, Request requestInfo,             UserInfo approver) throws ServiceException {         RequestApprover requestApprover;         switch (some_field) {             case FIRST_APPROVED:             case FIRST_REJECTED:                 requestApprover = xxx;                 break;               case APPROVED:             case REJECTED:                 requestApprover = yyy;                 break;             default:                 throw new UnsupportedOperationException();         }         requestApprover.approveById(id, requestInfo, approver);     } }

具体服务类

具体服务类承担实际上的业务逻辑。在类图中，它们被表示成了Service4Scene1.java ~ Service4Scene7.java。并且，我专门画了ServiceAsAdapter.java和ServiceAsSkeleton.java 来表示：这些具体服务类还可以有自己的组织方式、应用自己应用的模式。

在我上面的例子中，我通过一个RequestApproverAsSkeleton.java定义了模板。而在另一项需求中，我用了组合和中介——至少我将那几个类理解为中介模式。

小结

本质上，这个所谓“接口-分发器模式”是一种策略模式。但是它比策略模式多一点东西——分发器。另外，在实践应用中，它不可能只有策略。在“具体服务类”的组织上，几乎都会用上更多的模式。
题外话，就设计模式的应用上，有策略则必有工厂，有工厂几乎必有单例，这似乎也自成一种“模式”。

重构

那么，这个“模式”要怎样应用到重构中呢？
很简单——让旧代码和新代码都成为“具体服务类”中的成员，并且是不同的成员。

仍以上面的例子来说，我将旧代码和新代码分别安排在这两个类中。再结合前面的分发器，很简单的就完成了这次重构，并同时完成了新需求。

旧代码在这个类中：

class RequestApprover4First extends         RequestApproverAsSkeleton {       private static final Logger LOGGER = LoggerFactory         .getLogger(RequestApprover4First.class);       private RequestService service;       @Override     protected void approve(Request requestInfo,             Request request) throws InvalidDataException {             ……     }       @Override     protected void reject(Request requestInfo,             Request request) {         // 不做处理     }       @Override     protected void configRequest(Request requestInfo,             Request request, UserInfo approver) {             ……     }   }

而新的业务在这个服务中：

class RequestApprover4Check extends         RequestApproverAsSkeleton {       private static final Logger LOGGER = LoggerFactory         .getLogger(RequestApprover4Check.class);       @Override     public void approveById(Integer id, Request requestInfo,             UserInfo approver) throws ServiceException {         ……         // 这个方法中有额外处理     }       @Override     protected void approve(Request requestInfo,             Request request) throws ServiceException {         ……     }       @Override     protected void reject(Request requestInfo,             Request request) {         // 不做任何操作     }       @Override     protected void configRequest(Request requestInfo,             Request request, UserInfo approver) {             ……     }   }

 

优点和缺点

优点应该说比较明显：新、旧逻辑和代码被隔离开了，也就完成了解耦合。并且后续如果还要加新的需求，也可以比较轻松的隔离到新的服务类中。相信接手过旧系统、旧代码的朋友们都能理解其中的意义。

另外，旧代码可以保持不动，或者简单的复制到对应的具体服务类中。因此，改造工作量比较小。

缺点呢？一是容易造成“类爆炸”。虽然不一定变得太多，但是类的数量肯定比不用模式要多。二是这种模式有时候不会（也不需要）对旧代码做任何改动。这样一来，重构目标实际上并没有实现。

最后补充

做重构之前，一定要有用于验证旧代码功能的测试，并且尽可能的覆盖流程分支。

本文出自 “编程的摩羯男” 博客，请务必保留此出处http://winters1224.blog.51cto.com/3021203/1879788