重构 on Orangex-position0的技术博客

纯函数带来的架构思考：Functional Core 与 Imperative Shell

Wed, 08 Apr 2026 10:00:00 +0800

一、🎯 背景 & 问题：当业务逻辑遇上副作用

作者作为一个 Java 后端开发，经常需要写这样的函数，不知你也是否写过这样的函数：

一个 createOrder 方法，既要计算订单金额、应用折扣规则，还要保存到数据库、打印日志。

这看起来是个很正常的业务函数，但当你想给"折扣计算"写单元测试时，却发现必须连接数据库才能运行测试。

这种"业务逻辑 + 副作用"混在一起的模式，带来了三个核心问题：

问题	表现
❌难以测试	必须依赖数据库/网络等外部系统
❌难以预测	函数行为依赖外部状态，相同输入不一定得到相同输出
❌难以复用	逻辑绑死在 I/O 上，换个场景就得重写

⚠️ 本质原因：纯计算和副作用混在一起，导致核心业务逻辑被 I/O 操作"绑架"。

💡 读完本文，你将学到：

纯函数的核心思想及其对架构设计的启发
Functional Core / Imperative Shell 模式：如何将纯计算与副作用分离
通过 Java 和 Rust 两个案例，掌握具体的重构方法

二、🧩 方案或原理：纯函数与架构分离

什么是纯函数（Pure Function）

纯函数是函数式编程的核心概念，指相同输入下始终返回相同输出，且不产生任何副作用的函数。

两个关键特征：

结果可预测（Determinism）：输入唯一决定输出，不依赖外部状态
无副作用（No Side Effects）：不修改外部变量、不操作 I/O、不影响外部世界

// 纯函数：相同输入 → 相同输出，无副作用
fn add(a: i32, b: i32) -> i32 {
 a + b
}

// 纯函数：只依赖输入，返回新值，不修改原数据
fn to_uppercase(s: &str) -> String {
 s.to_uppercase()
}

纯函数天然适合以下场景：基础计算、数据转换、集合处理、参数校验。它们的共同点是——只关心输入到输出的映射，不关心数据从哪来、到哪去。

什么是副作用（Side Effects）

副作用指函数在执行过程中，除返回值外带来的其他影响：

副作用类型	带来的影响
修改外部变量 / 全局状态	破坏可预测性，增加隐式依赖
I/O 操作（文件、网络、数据库）	不可控（延迟/失败），结果不可复现
控制台输出（print）	引入环境依赖，测试需要 mock
依赖外部状态（环境变量、配置）	行为不再由输入决定
使用时间 / 随机数	相同输入得到不同输出

副作用本身不是"坏东西"——没有副作用的程序无法与真实世界交互。问题在于，副作用和业务逻辑混在一起时，代码变得难以理解和测试。

核心思想：纯计算与副作用分离

这就引出了本文的核心架构模式：Functional Core / Imperative Shell。

┌───────────────────────────────────────────┐
│ Imperative Shell │
│ （命令式外壳 - 负责副作用） │
│ │
│ · 读取数据库 / 文件 │
│ · 调用 Functional Core 完成业务计算 │
│ · 保存结果到数据库 │
│ · 记录日志 │
│ │
│ ┌─────────────────────────┐ │
│ │ Functional Core │ │
│ │ （纯逻辑内核 - 只做计算）│ │
│ │ │ │
│ │ · 业务规则计算 │ │
│ │ · 权限判断 │ │
│ │ · 数据转换 │ │
│ │ · 校验逻辑 │ │
│ │ │ │
│ │ ✅ 无副作用 │ │
│ │ ✅ 可预测 │ │
│ │ ✅ 容易测试（无需 mock） │ │
│ └─────────────────────────┘ │
└───────────────────────────────────────────┘

Functional Core（纯逻辑内核）：

由纯函数组成，只负责业务计算
不访问数据库、不打印日志、不修改外部状态
相同输入 → 相同输出，可独立测试

Imperative Shell（命令式外壳）：

负责与外界交互（I/O、事务、日志）
调用 Functional Core 完成业务计算
包含副作用（不可避免），但不承担复杂业务逻辑

💡 核心思想：不是消除副作用，而是隔离副作用，保护核心逻辑的可测试性。

三、🛠️ 使用步骤：重构"脏函数"

重构模板

将一个"业务逻辑 + 副作用"混合的函数，拆分为 FC/IS 结构，只需三步：

提取纯业务逻辑：将计算、校验等逻辑提取为独立函数（只依赖输入参数）
提取副作用逻辑：将数据库、I/O、日志等操作留在 Shell 中
Shell 调用 Core：在副作用函数中调用纯业务函数

案例1：Java - 创建订单

场景

输入：商品价格、数量、用户等级
输出：订单金额 + 折扣结果
同时需要：保存数据库 + 打日志

❌ 传统写法：逻辑 + 副作用混在一起

class OrderService {

 public double createOrder(double price, int quantity, int userLevel) {
 double total = price * quantity;

 // 折扣逻辑（业务计算）
 if (userLevel == 2) total *= 0.9;
 if (userLevel == 3) total *= 0.8;

 // 数据库写入（副作用）
 Database.save(total);

 // 日志（副作用）
 System.out.println("Order created: " + total);

 return total;
 }
}

问题：想测试"折扣计算"逻辑，必须先连接数据库。

✅ 重构后：FC/IS 分离

Step 1：提取 Functional Core（纯逻辑内核）

/**
 * 纯逻辑内核 - 只负责业务规则计算
 *
 * 特点：
 * - 只依赖输入参数
 * - 不访问数据库 / 不打印日志 / 不修改外部状态
 * - 相同输入 → 相同输出
 */
class OrderCore {

 /**
 * 计算订单最终价格（纯函数）
 */
 public static double calculateTotal(double price, int quantity, int userLevel) {
 double total = price * quantity;

 if (userLevel == 2) return total * 0.9;
 if (userLevel == 3) return total * 0.8;

 return total;
 }
}

Step 2：构建 Imperative Shell（命令式外壳）

/**
 * 命令式外壳 - 负责副作用和流程编排
 *
 * 职责：
 * - 调用纯函数完成业务计算
 * - 处理所有副作用（数据库 / 日志 / 外部交互）
 *
 * 不承担复杂业务逻辑，只做"编排"
 */
class OrderService {

 public double createOrder(double price, int quantity, int userLevel) {
 // 调用纯逻辑（核心计算）
 double total = OrderCore.calculateTotal(price, quantity, userLevel);

 // 副作用：持久化数据
 Database.save(total);

 // 副作用：记录日志
 System.out.println("Order created: " + total);

 return total;
 }
}

Step 3：测试纯逻辑，无需 mock

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class OrderCoreTest {

 @Test
 void 普通用户无折扣() {
 assertEquals(100.0, OrderCore.calculateTotal(50.0, 2, 1));
 }

 @Test
 void 二级会员九折() {
 assertEquals(90.0, OrderCore.calculateTotal(50.0, 2, 2));
 }

 @Test
 void 三级会员八折() {
 assertEquals(80.0, OrderCore.calculateTotal(50.0, 2, 3));
 }
}

测试无需数据库连接、无需 mock 框架，直接验证业务规则。

案例2：Rust - 文件单词统计

场景

实现一个 CLI 工具，读取文件内容并统计单词数量。

❌ 传统写法：逻辑 + I/O 混在一起

use std::fs;

fn count_words_in_file(path: &str) -> usize {
 // 副作用：读取文件
 let content = fs::read_to_string(path).unwrap();

 // 业务逻辑：统计单词
 let count = content.split_whitespace().count();

 // 副作用：打印结果
 println!("Word count: {}", count);

 count
}

问题：

想测试"单词统计"逻辑，必须依赖真实文件
逻辑绑死在文件 I/O 上，换数据来源就得重写

✅ 重构后：FC/IS 分离

Step 1：提取 Functional Core（纯逻辑内核）

/// 统计字符串中的单词数量（纯函数）
///
/// - 只依赖输入参数 content
/// - 不进行 I/O 操作
/// - 相同输入 → 相同输出
fn count_words(content: &str) -> usize {
 content.split_whitespace().count()
}

Step 2：构建 Imperative Shell（命令式外壳）

use std::fs;

fn run(path: &str) {
 // 副作用：读取文件
 let content = fs::read_to_string(path)
 .expect("Failed to read file");

 // 调用纯函数（核心逻辑）
 let count = count_words(&content);

 // 副作用：输出结果
 println!("Word count: {}", count);
}

Step 3：测试纯逻辑

#[cfg(test)]
mod tests {
 use super::*;

 #[test]
 fn 统计普通文本() {
 assert_eq!(count_words("hello world rust"), 3);
 }

 #[test]
 fn 空字符串返回零() {
 assert_eq!(count_words(""), 0);
 }

 #[test]
 fn 处理多余空白() {
 assert_eq!(count_words(" hello world "), 2);
 }
}

测试无需文件系统，直接验证计算逻辑。

四、💡 示例 / 踩坑

识别非纯函数

在实践中，学会识别哪些操作是不纯的，是正确应用 FC/IS 模式的前提。以下都是非纯函数的常见形式：

// 修改外部状态 - 依赖并修改全局变量
let mut total = 0;
fn add_to_total(x: i32) { total += x; }

// 依赖外部状态 - 行为由环境变量决定
fn get_env_port() -> String {
 std::env::var("PORT").unwrap_or("3000".to_string())
}

// 依赖时间 - 每次调用结果不同
fn get_timestamp() -> u64 {
 SystemTime::now()
 .duration_since(UNIX_EPOCH)
 .unwrap()
 .as_secs()
}

// 控制台输出 - 产生外部可观察行为
fn log_and_add(a: i32, b: i32) -> i32 {
 println!("calculating...");
 a + b
}

它们的共同特征：函数的行为不完全由输入决定。

常见陷阱

⚠️ 陷阱	表现	✅ 正确做法
过度追求纯函数	试图让所有函数都变纯，导致代码复杂度暴增	只隔离核心业务逻辑，I/O 操作交给 Shell
边界划分不清	不知道哪些逻辑属于 Core，哪些属于 Shell	判断标准：是否依赖外部状态？是否可预测？
Shell 承担业务逻辑	Shell 中又混入了计算逻辑	Shell 只做编排和 I/O，计算全交给 Core
忽略副作用传染性	在 Core 中调用了不纯函数，导致 Core 也不纯	Core 中的所有调用链都必须是纯的

什么时候适合使用 FC/IS 模式？

适合使用的场景：
├── 业务逻辑较复杂，需要频繁测试
├── 函数中混合了计算和 I/O 操作
└── 多个场景复用同一套计算逻辑

不一定需要的场景：
├── 简单的 CRUD 操作（逻辑简单，收益不大）
├── 纯 I/O 转发（没有业务计算）
└── 一次性脚本（不需要长期维护）

五、📋 总结

核心要点回顾

纯函数的本质：相同输入 → 相同输出，无副作用。它是可预测、可测试、可组合的基石
FC/IS 模式的核心思想：不是消除副作用，而是隔离副作用，保护核心逻辑
重构方法：提取纯逻辑为 Functional Core，将副作用留在 Imperative Shell，Shell 调用 Core

与方法拆分的关系

本文的 FC/IS 模式和"方法拆分"重构（重构实战：打破依赖关系的两种核心方法）是一脉相承的：

方法拆分：在同一类内分离纯逻辑与副作用（微观层面）
FC/IS 模式：将纯逻辑和副作用分到不同的模块/类（架构层面）

延伸方向

领域驱动设计（DDD）：Functional Core 可以对应领域层（Domain Layer），Imperative Shell 对应基础设施层（Infrastructure Layer）
六边形架构（Hexagonal Architecture）：核心业务逻辑不依赖外部，通过端口与适配器与外界交互
Effect Systems：在类型系统层面追踪副作用（如 Haskell 的 IO Monad）

💡 实践建议：下次写一个包含计算和 I/O 的函数时，先问自己——“能不能把计算逻辑提取出来，让它不依赖任何外部系统？”

重构实战：打破依赖关系的两种核心方法

Tue, 24 Mar 2026 10:00:00 +0800

一、🎯 背景 & 问题：你的代码为什么难以测试？

在日常开发中，我们经常会遇到这样的困境：

你想给一个 checkout 方法写单元测试，但发现它内部调用了数据库；你想测试 registerUser 方法，但发现它会真的发送邮件…

这些问题的共同特征是：测试依赖外部系统（数据库、网络、第三方服务），导致：

问题	表现
测试运行慢	每次都要连接真实数据库/网络
测试结果不稳定	外部系统的状态不可控
无法独立测试核心逻辑	被副作用绑架

⚠️ 本质原因：代码"设计耦合严重"——业务逻辑与副作用混在一起，形成了难以分割的依赖关系。

本文目标：通过两种实用的重构方法，让你的代码从"依赖具体实现"转变为"依赖抽象 + 可替换实现"，从而获得可独立测试的纯业务逻辑。

💡 读完本文，你将学到：两种常用的变更代码思路（如何解耦）

二、🧩 方案概述：解耦的核心思想

打破依赖关系的本质是 解耦（Decoupling）。

简单来说，就是让代码从：

调用方 --> 直接依赖具体实现

变成：

调用方 --> 依赖抽象接口 --> 可替换的具体实现（真实/测试）

本文介绍两种核心方法：

方法	核心思想	适用场景
🔧 方法拆分	将纯业务逻辑与副作用操作分离	单方法内部混杂多种职责
🔄 依赖倒置	通过接口抽象依赖，引入中介层	类与类之间的强耦合

三、🛠️ 实现步骤

🔧 方法1：方法拆分（逻辑隔离）

核心概念：

📌 纯业务逻辑：可直接测试的计算、校验等（无副作用）
🌊 副作用操作：依赖外部系统的操作（数据库、网络、I/O）

重构目标：将大方法中的"纯业务逻辑"和"副作用操作"拆分，让核心逻辑可单独测试。

原始代码：测试被数据库绑架

public class OrderService {

 public int checkout(Order order) {
 // ① 业务逻辑：计算价格
 int total = 0;
 for (Item item : order.getItems()) {
 total += item.getPrice();
 }

 // ② 副作用：访问数据库（不可控）
 Database db = new Database();
 db.save(order);

 return total;
 }
}

问题：想测试"价格计算"，必须先连接数据库。

重构后：职责分离

public class OrderService {

 public int checkout(Order order) {
 // 1️⃣ 只负责流程编排（orchestration）
 int total = calculateTotal(order);
 save(order);
 return total;
 }

 /**
 * 纯函数：无副作用，可单独测试
 * 通过提炼方法将纯逻辑分离出来
 */
 int calculateTotal(Order order) {
 int total = 0;
 for (Item item : order.getItems()) {
 total += item.getPrice();
 }
 return total;
 }

 /**
 * 副作用方法：隔离数据库依赖
 * 将副作用集中到单独方法中
 */
 private void save(Order order) {
 new Database().save(order);
 }
}

单元测试：无需数据库

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class OrderServiceTest {

 @Test
 void testCalculateTotal() {
 // 准备测试数据
 Order order = new Order(List.of(
 new Item(10),
 new Item(20)
 ));

 // 执行测试 - 不依赖数据库
 int result = new OrderService().calculateTotal(order);

 // 验证结果
 assertEquals(30, result);
 }
}

关键收益：calculateTotal 现在是一个纯函数（Pure Function）——给定相同输入永远返回相同输出，且没有副作用，非常容易测试。

⭐ 测试优势：无需任何 Mock 框架，直接调用即可验证

🔄 方法2：引入中介（依赖倒置）

当依赖关系跨越类边界时，方法拆分就不够用了。这时需要引入一个**中介（接口）**来替代具体实现，让依赖"可替换"。

这就是 依赖倒置原则（Dependency Inversion Principle） 的实践：

📌 高层模块不应依赖低层模块，两者都应依赖抽象
📌 抽象不应依赖细节，细节应依赖抽象

原始代码：硬编码依赖

public class UserService {
 // ❌ 硬编码依赖具体实现（强耦合）
 private RealEmailSender emailSender = new RealEmailSender();

 public void registerUser(String email) {
 // ... 业务逻辑：验证邮箱格式、检查重复等 ...

 // ❌ 副作用：真实发送邮件
 emailSender.sendWelcomeEmail(email);
 }
}

测试困境：测试 registerUser 时会真的发送邮件，既慢又有副作用。

重构步骤

Step 1：定义抽象（接口）

/**
 * 抽象：定义"发送邮件"的能力，而不是具体实现
 */
interface EmailProvider {
 void send(String to, String subject, String content);
}

Step 2：提供真实实现（生产环境使用）

/**
 * 真实实现：生产环境发送真实邮件
 */
class RealEmailSender implements EmailProvider {

 @Override
 public void send(String to, String subject, String content) {
 // 实际发送邮件（网络请求）
 // 调用邮件服务商 API 等
 }
}

Step 3：业务类依赖抽象

public class UserService {

 // ✅ 依赖抽象（接口）而不是具体类
 private final EmailProvider emailProvider;

 /**
 * 通过构造函数注入依赖（Dependency Injection）
 * 调用方决定使用哪个实现
 */
 public UserService(EmailProvider emailProvider) {
 this.emailProvider = emailProvider;
 }

 public void registerUser(String email) {
 // ... 业务逻辑 ...

 // ✅ 调用抽象，不关心具体如何发送
 emailProvider.send(email, "欢迎注册", "欢迎加入我们！");
 }
}

Step 4：创建测试用的 Fake / Stub 实现

/**
 * 测试用实现：只记录调用，不执行真实操作
 */
class FakeEmailSender implements EmailProvider {

 // 记录发送的邮件，用于验证
 private final List<EmailRecord> sentEmails = new ArrayList<>();
 private boolean isCalled = false;

 @Override
 public void send(String to, String subject, String content) {
 // ✅ 不做真实操作，只记录
 sentEmails.add(new EmailRecord(to, subject, content));
 isCalled = true;
 }

 public boolean wasEmailSentTo(String email) {
 return sentEmails.stream()
 .anyMatch(e -> e.to().equals(email));
 }

 // 记录类
 record EmailRecord(String to, String subject, String content) {}
}

单元测试：完全隔离外部依赖

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class UserServiceTest {

 @Test
 void registerUser_shouldSendWelcomeEmail() {
 // 1️⃣ 创建测试替身（Test Double）
 FakeEmailSender fakeEmailSender = new FakeEmailSender();

 // 2️⃣ 注入测试替身
 UserService userService = new UserService(fakeEmailSender);

 // 3️⃣ 执行被测方法
 userService.registerUser("user@example.com");

 // 4️⃣ 验证行为（而不是结果）
 assertTrue(fakeEmailSender.wasEmailSentTo("user@example.com"));
 }
}

关键收益：

🚀 测试速度快：没有网络请求
✅ 测试可重复：结果不受外部服务状态影响
🔍 验证行为：可以精确验证 EmailProvider.send() 是否被调用

四、💡 实战示例 & 踩坑指南

综合案例：订单处理服务

让我们看一个更复杂的例子，结合两种方法：

/**
 * 重构后的订单处理服务：完全可测试
 */
public class OrderProcessor {

 private final PaymentGateway paymentGateway;
 private final InventoryService inventoryService;

 // 通过构造函数注入所有外部依赖
 public OrderProcessor(PaymentGateway paymentGateway,
 InventoryService inventoryService) {
 this.paymentGateway = paymentGateway;
 this.inventoryService = inventoryService;
 }

 public OrderResult process(Order order) {
 // 1️⃣ 纯业务逻辑：验证订单
 validateOrder(order);

 // 2️⃣ 纯业务逻辑：计算总价
 BigDecimal total = calculateTotal(order);

 // 3️⃣ 副作用：检查库存（通过抽象）
 if (!inventoryService.isAvailable(order)) {
 return OrderResult.outOfStock();
 }

 // 4️⃣ 副作用：处理支付（通过抽象）
 PaymentResult payment = paymentGateway.charge(order.getCustomerId(), total);

 // 5️⃣ 纯业务逻辑：根据支付结果处理
 return buildResult(order, payment);
 }

 // 可独立测试的纯方法
 void validateOrder(Order order) {
 if (order == null || order.getItems().isEmpty()) {
 throw new IllegalArgumentException("订单无效");
 }
 }

 // 可独立测试的纯方法
 BigDecimal calculateTotal(Order order) {
 return order.getItems().stream()
 .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
 .reduce(BigDecimal.ZERO, BigDecimal::add);
 }

 // 可独立测试的纯方法
 private OrderResult buildResult(Order order, PaymentResult payment) {
 return payment.isSuccess()
 ? OrderResult.success(order.getId())
 : OrderResult.paymentFailed(payment.getErrorMessage());
 }
}

常见陷阱 & 解决方案

⚠️ 陷阱	表现	✅ 解决方案
接口过大	一个接口包含十几个方法，实现困难	遵循接口隔离原则，拆分为小接口
过度设计	简单场景也强行引入接口	先有测试需求再抽象，避免过早优化
Mock 滥用	测试全是 Mock，失去实际意义	优先用 Fake，核心业务逻辑用真对象
依赖隐藏	在方法内部 `new` 依赖对象	所有依赖通过构造函数注入

测试策略选择

┌─────────────────────────────────────────────────────────┐
│ 纯业务逻辑（calculateTotal, validateOrder） │
│ └── 直接测试，无需任何 Mock/Fake │
├─────────────────────────────────────────────────────────┤
│ 外部依赖（EmailProvider, PaymentGateway） │
│ ├── 集成测试：使用真实实现（连接测试环境） │
│ └── 单元测试：使用 Fake/Stub 实现 │
├─────────────────────────────────────────────────────────┤
│ 协调/编排逻辑（checkout, process） │
│ └── 使用 Fake 验证交互行为 │
└─────────────────────────────────────────────────────────┘

五、📋 总结

核心要点回顾

为什么要打破依赖：让代码可测试、可维护，将业务逻辑与副作用分离

两种核心方法：

🔧 方法拆分：在同一类内分离纯逻辑与副作用
🔄 引入中介：通过接口实现类间的依赖倒置

关键原则：

依赖抽象，而非具体实现
构造函数注入依赖
优先使用可独立测试的纯函数

重构决策流程

开始
 │
 ▼
方法内部混杂了业务逻辑和副作用？ ──是──▶ 方法拆分（提炼纯函数）
 │否
 ▼
类依赖了具体实现导致难以测试？ ────是──▶ 引入中介（依赖倒置）
 │否
 ▼
结束（代码已足够清晰）

💡 实践建议：下次写代码时，先问自己——“这个方法能脱离数据库运行测试吗？“如果不能，也许就是重构的时候了。

六、📚 参考

程序员的README (豆瓣) - 第二章的部分内容