方法提取实战：从缓存重复代码到清晰抽象的完整重构指南

看着PR里那段复制粘贴了三次的代码，我第一反应不是"写的人水平不行"，而是"当时我大概也会这么干"。三个方法做的事情几乎一样：从缓存拿数据，拿不到就查数据库，查到了顺手刷新过期时间，最后拼成响应对象返回。区别只是入参类型不一样，以及中间那行查询语句换了张表。这种代码在业务系统里太常见了，常见到所有人都默认它就该长这样。

但"默认"不代表"正确"。方法提取（Extract Method）是重构里最基础、也最容易被用偏的一个手法。很多人以为它就是把重复代码搬进一个新方法，改几个参数名，完事。真这么做，大概率会造出一个更别扭的抽象层——比如那个被塞了六个参数、里面全是if分支的"万能方法"。所以这篇不打算只讲"怎么提取"，重点讲提取前怎么判断该不该提取、提取时变化点怎么找、提取后怎么证明没改坏。这些都是我在真实项目里踩过的坑，写出来给正准备动手的你参考。

1. 动手之前，先看清重复逻辑的三种形态

方法提取的第一步不是打开IDE按快捷键，而是先确认你面对的重复到底属于哪种形态。不同形态的重复，处理方式完全不同。我见过太多人栽在第二步：没分清重复类型，强行提取，最后代码比原来还难维护。

1.1 复制粘贴型重复：最容易被识别，也最不值得骄傲

复制粘贴型重复最好认：两段代码几乎一模一样，只差类型名、变量名，或者某个字段路径。比如在一个订单系统里，loadProductData 和 loadOrderData 两个方法，前半段都是先查缓存、缓存没有就查数据库、查完再写回缓存，代码片段几乎完全对齐。

这种重复最让人头疼的地方在于：它不只是丑，它还会放大bug。假设缓存那边要加一个空值保护，或者要补充一段埋点日志，你需要在三个地方同步修改。只要漏改一处，线上就会出现"某个接口有缓存保护、另一个接口还是老逻辑"的诡异差异。所以遇到这种重复，别犹豫，该提取就提取。

1.2 结构一致但细节漂移的"伪重复"：方法提取最常翻车的地方

比复制粘贴型更阴险的是"伪重复"。表面上看几个方法都长一个骨架：查出列表、按条件过滤、排序、转DTO、返回。但具体到每一步，过滤条件不同、排序字段不同、DTO的映射规则也不同。

这类代码如果硬提取，很容易掉进"万能参数"陷阱。我以前见过一个方法，为了合并三个"看起来一样"的查询逻辑，塞了五个参数进去，其中有两个是布尔开关，方法内部全是 if (xxx) {} else {}。调用方的代码确实从三段变成三行了，但可读性直接从"啰嗦"变成了"黑盒"——没人知道传 true 和传 false 到底会触发哪条路径。

伪重复的正确处理方式不是"用参数强行统一"，而是先看骨架是否真的同构。如果一段代码里有50%相同、50%不同，那把相同的部分（比如分页处理、异常包装）提出来，不同的部分保留在各自方法里，往往比强行合并更合理。方法提取的粒度，一对一错，效果天差地别。

1.3 判断"该不该提取"的三个问题与一张对照表

在按下重构快捷键之前，我自己习惯先过三个问题：

1. 这段代码承担的职责是同一个吗？如果两段代码只是"恰好长得像"，但业务含义完全不同，提取后会导致语义错位。
2. 变化点能否用参数化解决，且不引入复杂分支？判断标准是：参数传入后，方法体内不需要靠 if (type == A) 这种开关来分流。一旦需要，说明你提取的根本不是同一种逻辑，只是同一个模板。
3. 提取出来的方法名能不能准确表达业务意图？一个叫 processData 的方法大概率是抽象过度了；但如果它能叫 publishOrderEvent，说明你找到了真正的业务概念。

下面这张表是我平时判断时参考的：

这个表不严谨，但很实用。它的核心意思是：方法提取的第一目标不是"消除重复"，而是"让代码的职责边界清晰"。重复只是你发现职责边界的一个线索，不能当作唯一标准。

2. 一次完整的方法提取流程：从缓存逻辑重复案例说起

光讲理论容易飘，下面用一个完整的案例走一遍提取流程。这个案例来自一个典型的电商后台服务，逻辑不复杂，但很能说明问题。

2.1 重构前的样子：两个看似不同、实则同构的方法

当时项目里有一个库存查询服务，里面两个方法，分别加载商品信息和订单信息：

java复制public ProductVO loadProductData(Long productId) {
    String cacheKey = "product:" + productId;
    Object cached = redisTemplate.opsForValue().get(cacheKey);
    if (cached != null) {
        redisTemplate.expire(cacheKey, 30, TimeUnit.MINUTES);
        return (ProductVO) cached;
    }
    Product product = productMapper.selectById(productId);
    if (product == null) {
        throw new BizException("商品不存在");
    }
    ProductVO vo = convertToProductVO(product);
    redisTemplate.opsForValue().set(cacheKey, vo, 30, TimeUnit.MINUTES);
    return vo;
}

public OrderVO loadOrderData(Long orderId) {
    String cacheKey = "order:" + orderId;
    Object cached = redisTemplate.opsForValue().get(cacheKey);
    if (cached != null) {
        redisTemplate.expire(cacheKey, 30, TimeUnit.MINUTES);
        return (OrderVO) cached;
    }
    Order order = orderMapper.selectById(orderId);
    if (order == null) {
        throw new BizException("订单不存在");
    }
    OrderVO vo = convertToOrderVO(order);
    redisTemplate.opsForValue().set(cacheKey, vo, 30, TimeUnit.MINUTES);
    return vo;
}

两个方法结构同构：拼缓存key、查缓存、命中则延期并返回、未命中则查库、为空抛异常、转VO、写缓存。区别只是缓存key前缀、查询逻辑、转换逻辑、异常消息不同。

2.2 提取稳定骨架：用泛型和函数式接口统一变化

这个场景非常适合方法提取，因为稳定骨架很清晰，变化点也能用参数化表达。我的做法是抽出一个泛型方法，把"查缓存/写缓存/刷新过期时间"这段基础设施逻辑固定下来，把"如何加载数据"作为函数式接口传入：

java复制private <T> T getWithCache(String cacheKey, Class<T> type, Supplier<T> loader,
                           String notFoundMessage) {
    Object cached = redisTemplate.opsForValue().get(cacheKey);
    if (cached != null) {
        redisTemplate.expire(cacheKey, 30, TimeUnit.MINUTES);
        return type.cast(cached);
    }
    T value = loader.get();
    if (value == null) {
        throw new BizException(notFoundMessage);
    }
    redisTemplate.opsForValue().set(cacheKey, value, 30, TimeUnit.MINUTES);
    return value;
}

调用方变成这样：

java复制public ProductVO loadProductData(Long productId) {
    return getWithCache(
        "product:" + productId,
        ProductVO.class,
        () -> convertToProductVO(productMapper.selectById(productId)),
        "商品不存在"
    );
}

public OrderVO loadOrderData(Long orderId) {
    return getWithCache(
        "order:" + orderId,
        OrderVO.class,
        () -> convertToOrderVO(orderMapper.selectById(orderId)),
        "订单不存在"
    );
}

注意这里我用的是 Supplier<T> 而不是直接传 Product / Order 对象。原因很简单：loader 是惰性执行的。只有当缓存未命中时才会真正查询数据库。如果我把 productMapper.selectById(productId) 的结果当作参数先算好再传入，那即使缓存命中了，也一样会触发一次无谓的数据库查询，缓存的意义就直接没了。

2.3 变化点边界怎么切：不是所有差异都得塞进方法参数

上面这个案例变化点很清晰，提取得顺手。但真实业务里，两个方法往往不是刚好只有这么点差异。我再举一个反例：如果 loadOrderData 在查完订单之后，还需要额外查订单明细、校验库存、计算运费，那它还适合继续走这个 getWithCache 方法吗？

我的答案是：不适合。硬走也行，但你得给 loader 里塞一大堆逻辑。假设把"查订单明细、算运费"都塞进 loader 的 Lambda 里，Lambda 会变得非常长，方法提取就等于把一段逻辑从一个坑挪到另一个坑。

正确的做法是：提取只到"相同骨架结束的地方为止"。比如订单这部分，可以拆成两步：

java复制public OrderDetailVO loadOrderDetailData(Long orderId) {
    OrderVO base = getWithCache(
        "order:" + orderId,
        OrderVO.class,
        () -> convertToOrderVO(orderMapper.selectById(orderId)),
        "订单不存在"
    );
    // base 之外还有独立的扩展逻辑
    return enrichOrderDetail(base);
}

enrichOrderDetail 里的逻辑保留在 loadOrderDetailData 这一层，不强行并进通用方法。方法提取不是在追求"最小重复"，而是在追求"最合理的职责边界"。两段逻辑共享的是缓存读写这一段基础设施，那就只抽这一段；后续各走各的业务分支，就不要为了消除重复把它们绑在一起。

2.4 重构后效果与IDE操作路径

上面这个案例重构完，效果最直观的体现是：

• 缓存key拼接规则统一了，不再出现某个方法用 "product:" + id、另一个方法用 String.format("product_%d", id) 的混乱。
• 缓存的过期时间、刷新逻辑集中在一处，后续要调整TTL或者加监控，只改 getWithCache 一个地方。
• 新增一个 loadLogisticsData 方法时，不需要再复制一坨缓存代码，调 getWithCache 就行。

如果你已经非常确定要提取，那可以借助IDE减少手工出错。以 IntelliJ IDEA 为例，选中要提取的代码块，快捷键 Ctrl + Alt + M（macOS 是 Cmd + Option + M），在弹出的对话框里改方法名、调参数顺序、选择提取后放置的位置。IDE会自动帮你处理变量声明和返回值。但我的建议是：IDE只负责机械提取，你负责决策。对伪重复，不要一上来就按快捷键，先想清楚边界再动手。

3. 提取之后，怎么证明这次重构没把代码改坏

很多人重构完跑一遍主流程，看到接口能通就觉得自己成功了。但方法提取最阴险的问题往往藏在边界条件里。我在这个环节翻过车，所以现在特别重视"重构后验证"。

3.1 先写特征测试，再动结构

如果你要重构的代码模块本来就有完整单测，那很好，直接跑。但现实是：很多遗留代码根本没有测试。这时候我建议先写"特征测试"（Characterization Test），也就是把当前行为当作预期行为锁死的测试。它不关心实现对不对，只关心"重构前后行为不变"。

比如针对 loadProductData，可以先写一个简单的JUnit 5测试：

java复制@Test
void shouldReturnProductVOFromCacheWhenCacheHit() {
    ProductVO mockVO = new ProductVO();
    when(redisTemplate.opsForValue().get("product:1")).thenReturn(mockVO);
    
    ProductVO result = productQueryService.loadProductData(1L);
    
    assertEquals(mockVO, result);
    verify(redisTemplate, never()).expire(anyString(), anyLong(), any());
}

这种测试的价值不在于验证业务正确性，而在于给你一张安全网。先写好测试，再重构；重构完跑一遍，全绿就说明行为没变。

3.2 文本diff靠不住：重点核对排序、Null、异常这三类细节

说实话，文本层面看到两个方法高度相似，不一定意味着行为一致。我在一次提取中遇到过这样的情况：两个方法都被我收拢到统一的 getWithCache 里，但其中一个方法在缓存未命中时，查出来的列表还需要排序，另一个不需要。提取的时候我把排序逻辑顺手塞进了公共代码，结果就是原本不排序的接口也排上序了，线上数据顺序直接变了。

后来我总结了三个重构后必须人工核对的地方：

• 排序与遍历顺序：原始代码里有没有依赖HashMap的迭代顺序？提取后有没有改成TreeMap或者LinkedHashMap？
• Null处理：原始代码里是 if (obj == null) 还是用 Optional？提取后是否保持了同样的空值语义？
• 异常类型与包装：原来抛的是 BizException，提取后如果变成 RuntimeException，调用方的catch就失效了。

这三类细节在文本diff里往往看不出来，因为diff工具按行对比，不会理解"行为等价性"。

3.3 评审中被问"是不是过度设计"时，我怎么回答

我自己在做code review时也经常问别人这个问题："你抽这个方法是不是过度设计了？"被问到时别急着辩护，先自查三个点：

1. 调用点有几个？如果只有1个调用点，那这个方法大概率只是"把代码搬了个家"，没有消除重复，反而增加了一层跳转。
2. 方法名是否在表达业务语义？如果一个方法叫 getDataByType，那你其实是在用参数表达语义，这种抽象通常很弱。
3. 提取出来的方法是否让调用方更容易理解？如果调用方读代码时，需要点进去看方法实现才能理解业务逻辑，那提取就是失败的。

如果这三关都过了，就理直气壮地跟评审解释：这不是过度设计，这是把重复的逻辑收敛到一个命名清晰的抽象点。反过来，如果没过，别死撑，用IDE的 Inline Method 一键把方法内联回去，重新思考边界。重构嘛，本来就是可以反复调整的。

4. 从消除重复到定义业务语义：方法提取的上层用法

方法提取做到"消除重复"只是入门。真正有价值的是，通过提取，你会在代码里发现一些原本被埋没在重复逻辑里的"隐藏概念"。这是方法提取最有意思的地方。

4.1 方法名就是业务词汇表

提取方法时，"命名"这个动作本身就是一次领域建模。举个例子，两个地方都有"修改订单状态后通知关联系统"的逻辑。你如果把它提取成 notifyRelatedServices()，那代码读起来就是一段流程描述，还行。但如果你再想想业务上到底在做什么——其实是"发布订单状态变更事件"，那方法名改成 publishOrderStatusEvent(OrderStatus oldStatus, OrderStatus newStatus) 会更好。

好的方法名是业务的词汇表。后续新同学看代码时，不需要追着问"这段是干嘛的"，方法名已经把80%的语义讲清楚了。这也是为什么我强调，提取的时候不要随手起一个 processXXX、handleXXX 这种毫无信息量的名字——你失去的是一次让代码"开口说话"的机会。

4.2 提取前先想清楚方法的不变式

"不变式"听起来抽象，其实很具体。你提取一个方法时，应该能回答一个问题：调用这个方法前后，哪些业务状态保持不变，或者哪些状态被可靠地建立起来了？

拿 getWithCache 来说，它的不变式是：方法返回后，缓存中一定存在该key对应的数据（除非加载器返回null并抛异常）。这个不变式让每个调用方都可以放心依赖缓存。同样，提取 publishOrderStatusEvent 时，你可以定义：方法返回后，状态变更事件必然被记录到事件表，且重试至少一次。有了不变式，测试也好写，后续别人改你的方法，也知道不能轻易破坏这条规则。

4.3 函数式接口的参数化技巧与滥用边界

Java 8以后，方法参数可以是 Supplier、Function、Predicate 这些函数式接口，这让方法提取的表达能力变强了。拿前面的 getWithCache 举例，Supplier<T> loader 就是典型的参数化变化点。再复杂一点，你还可以把"key的生成规则"抽成 Function<T, String>：

java复制public <T> T getWithKey(Object domainId, Function<Object, String> keyBuilder,
                        Class<T> type, Supplier<T> loader, String notFoundMessage) {
    String cacheKey = keyBuilder.apply(domainId);
    // ...
}

但函数式接口不是用得越多越好。我自己有一条红线：一个方法签名里超过两个函数式参数，就要回头怀疑设计出了问题。因为每多一个函数式参数，调用方的可读性就下降一个档次——调用处全是Lambda嵌套Lambda，读起来比原来的重复代码还累。方法提取是为了让代码更像"大声朗读业务"，而不是为了把代码压缩成一行花哨的Lambda。

5. 提取过程中那些差点让我翻车的细节

方法提取这块，理论和步骤说完了，最后补充几个实操中容易翻车的细节。这些细节很少有人写在文档里，但每一个都对应着一次真实的线上问题。

5.1 受检异常：Supplier 与 Callable 的选择

Supplier.get() 方法声明里不抛受检异常。这意味着如果loader里有一段用 Thread.sleep() 或者调用JDBC API的代码，需要处理 InterruptedException 或 SQLException 时，你没法直接写进 Supplier 的 Lambda 里。两种选择：一种是把受检异常包装成RuntimeException——简单但丢了原始异常类型；另一种是用 Callable<T> 替代 Supplier<T>，因为 Callable.call() 声明 throws Exception。

我自己更倾向用 Callable，因为方法提取首先不能改变方法的异常契约。调用方原来catch的是 SQLException，提取后不该变成catch RuntimeException 再去解包。如果你不想让方法签名上挂着 throws Exception，那就定义一个自己的函数式接口：

java复制@FunctionalInterface
public interface DataLoader<T> {
    T load() throws Exception;
}

这样既保留了异常抛出的能力，接口语义也明确。

5.2 日志归属：提取后日志"串味"导致排查困难

这个问题很隐蔽。假设原来 loadProductData 里有一行 log.info("load product data, id={}", productId)，loadOrderData 里也有对应一行。提取后，如果你把日志打到了 getWithCache 里，变成 log.info("load data from cache, key={}", cacheKey)，那所有调用方产生的日志都长一个样。线上排查时，你看到一堆"from cache"的日志，根本分不清是哪个业务接口在调，只能顺着traceId一条条翻，效率极低。

我的经验是：基础设施方法里只打缓存命中率、耗时这种统一指标日志；业务日志留在调用方。这样既保留了公共方法的埋点能力，又不丢失业务上下文。

5.3 过度提取后抽象层次混乱的信号与急救方案

最后说说"提取过头"这件事。真实项目里，代码会经过多轮重构，每一轮都有人基于当时的理解提取方法。提多了以后，会出现一种症状：方法A调方法B，方法B调方法C，方法C调方法D，每个方法只有五六行，整条调用链拉得特别长。读代码变成了一场追索游戏，你追到最底层才明白最初那个操作到底在干什么。

我的急救方案很暴力：把这些只有四五行的过渡方法先用 Inline Method 内联回去，让代码"变胖"一点，然后再基于当前对业务的理解重新划分边界。内联不是倒退，它是清除冗余抽象层次的手段。过一阵子你会发现，有些方法确实该拆，有些方法当初就不该存在。

回到开头那个三处重复的缓存代码。我在那个版本里做的不是简单提取，而是借提取的机会重新定义了"缓存读取"这个公共概念，顺手把几个方法的日志规范也一并统一了。后来团队里再有人要加"加载物流数据"之类的接口，直接复用 getWithCache，十分钟搞定。这就是方法提取该有的效果——它不只是让代码变短，而是让代码里长出一个清晰的、可复用的业务概念。希望这篇记录能帮你在重构时少踩几个我踩过的坑。