4、依赖隔离原则：单一职责原则在Mock中的应用、接口隔离原则、依赖反转与Mock的配合

在微服务架构中，服务间的依赖关系错综复杂。Mock 工具的核心价值不仅在于模拟外部服务，更在于通过依赖隔离，将被测单元从复杂的依赖网络中解耦出来。本章将深入剖析三大设计原则——单一职责原则（SRP）、接口隔离原则（ISP）和依赖反转原则（DIP）——如何指导 Mock 的落地实践，确保每个 Mock 桩件职责清晰、接口精简、依赖方向正确。

4.1 单一职责原则在Mock中的应用

单一职责原则（Single Responsibility Principle, SRP）要求一个模块或类只应有一个引起它变化的原因。在 Mock 场景中，这意味着一个 Mock 对象只应模拟一个外部依赖的单一行为，而非大而全的“万能 Mock”。

下表对比了 SRP 合规与违规的 Mock 设计差异：

实践建议： 为每个外部依赖接口创建独立的 Mock 工厂类，每个工厂类只负责一种依赖的模拟。例如：UserServiceMockFactory 只负责模拟用户服务，内部再按场景拆分为 mockNormalUser()、mockAdminUser()、mockUserNotFound() 等方法。

// 符合 SRP 的 Mock 工厂示例
public class PaymentGatewayMockFactory {
    public static PaymentGateway mockSuccess() {
        PaymentGateway mock = mock(PaymentGateway.class);
        when(mock.charge(any())).thenReturn(new PaymentResult("SUCCESS", "txn_001"));
        return mock;
    }

    public static PaymentGateway mockTimeout() {
        PaymentGateway mock = mock(PaymentGateway.class);
        when(mock.charge(any())).thenThrow(new TimeoutException("Gateway timeout"));
        return mock;
    }

    // 每个方法只负责一种场景，职责单一
}

4.2 接口隔离原则：精简Mock的契约边界

接口隔离原则（Interface Segregation Principle, ISP）强调客户端不应被迫依赖它不使用的接口。在 Mock 治理中，ISP 要求被 Mock 的接口应足够小、足够专一，避免 Mock 对象承载大量无关方法。

当接口过于臃肿时，Mock 框架需要为每个未使用的方法提供默认实现（如 Mockito 的 when().thenReturn()），这不仅增加了 Mock 配置的复杂度，还容易因接口变更导致 Mock 编译失败。

ISP 落地的三个关键步骤：

1. 识别胖接口： 检查被 Mock 的接口是否包含超过 3 个不相关的方法组（如订单操作、支付查询、邮件发送混在一起）。
2. 按角色拆分： 将胖接口拆分为多个角色接口，每个接口只包含一个业务维度的操作。
3. 按需 Mock： 测试用例只 Mock 其真正依赖的角色接口，其他接口无需配置。

// 符合 ISP 的接口拆分与 Mock 示例
// 拆分后的角色接口
public interface IOrderCreation {
    Order createOrder(CreateOrderRequest request);
}

public interface IPaymentQuery {
    PaymentStatus getPaymentStatus(String orderId);
}

// 测试用例只 Mock 需要的接口
public class OrderServiceTest {
    @Mock
    private IOrderCreation orderCreation;  // 只 Mock 创建订单接口

    @InjectMocks
    private OrderService orderService;

    @Test
    public void testCreateOrder() {
        when(orderCreation.createOrder(any())).thenReturn(new Order("ORD-001"));
        Order result = orderService.createOrder(new CreateOrderRequest());
        assertEquals("ORD-001", result.getId());
        // 无需关心 IPaymentQuery 的 Mock 配置
    }
}

4.3 依赖反转与Mock的配合

依赖反转原则（Dependency Inversion Principle, DIP）要求高层模块不应依赖低层模块，二者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。在 Mock 治理中，DIP 是Mock 能够生效的底层架构保障。

当代码直接依赖具体实现类（如 new HttpClient()）时，Mock 框架无法注入替代对象。只有通过接口或抽象类定义依赖，并采用依赖注入（DI）方式将具体实现注入，Mock 才能无缝替换真实实现。

DIP + Mock 的最佳实践：

• 面向接口编程： 所有外部依赖（数据库、消息队列、第三方 API）都通过接口定义，实现类通过构造函数或 Setter 注入。
• 使用 DI 容器： 生产环境使用 Spring、Guice 等容器注入真实实现；测试环境注入 Mock 实例。
• 避免静态方法调用： 静态方法无法被 Mock 框架（如 Mockito）直接替换，应封装为可注入的实例方法。

// 符合 DIP 的代码结构（支持 Mock）
public class OrderService {
    private final IHttpClient httpClient;  // 依赖抽象

    // 通过构造函数注入，测试时可传入 Mock 实例
    public OrderService(IHttpClient httpClient) {
        this.httpClient = httpClient;
    }

    public Order createOrder(CreateOrderRequest request) {
        String response = httpClient.post("/orders", request);
        return parseOrder(response);
    }
}

// 测试代码
public class OrderServiceTest {
    @Mock
    private IHttpClient httpClient;  // Mock 抽象接口

    @InjectMocks
    private OrderService orderService;

    @Test
    public void testCreateOrder() {
        when(httpClient.post(anyString(), any())).thenReturn("{\"id\":\"ORD-001\"}");
        Order result = orderService.createOrder(new CreateOrderRequest());
        assertEquals("ORD-001", result.getId());
    }
}

4.4 三大原则的协同治理矩阵

SRP、ISP、DIP 并非孤立的原则，它们在 Mock 治理中形成互补的三角关系：