📚 课程目录第2章接口隔离原则(ISP)

2. 接口隔离原则（ISP）

2.1 ISP 原则详解

接口隔离原则（Interface Segregation Principle, ISP）是 Robert C. Martin 提出的 SOLID 原则中的“I”。其核心思想是：客户端不应被迫依赖它不使用的方法。换句话说，一个接口应该只包含调用方真正需要的行为，而不是将大量不相关的方法塞进同一个接口中。

在 Go 语言中，接口是隐式实现的，这为 ISP 提供了天然的支持。但隐式实现并不意味着不会产生胖接口。如果设计者缺乏 ISP 意识，仍然会定义出包含大量方法的巨型接口，导致实现方被迫实现一堆无用的桩代码。

ISP 的本质： 接口的粒度应当与客户端的实际需求对齐。一个模块只应暴露它真正需要的最小行为集合，而不是将所有可能的方法打包在一起。

2.2 胖接口的危害

胖接口（Fat Interface）是指包含大量方法、职责不单一的接口。它在 Go 项目中会引发以下问题：

危害维度	具体表现	后果
实现负担	实现方必须为所有方法提供实现，即使其中大部分用不到	产生大量空方法或 panic 桩代码，增加维护成本
耦合度升高	调用方依赖了不需要的方法签名，接口变更时影响面扩大	任何方法修改都可能波及无关的调用方
测试困难	Mock 对象必须实现所有方法，即使测试只用到其中一两个	Mock 代码膨胀，测试用例可读性下降
语义模糊	接口名称难以概括所有方法，职责边界不清晰	新开发者难以理解接口的真正用途

典型反例： 定义一个 DataProcessor 接口，包含 Read()、Write()、Validate()、Transform()、Export()、Archive() 六个方法。如果某个客户端只需要读取数据，它仍然必须实现其他五个无用方法。这就是典型的胖接口。

2.3 Go 接口设计的最佳实践

Go 官方推荐“小接口”哲学。标准库中的 io.Reader、io.Writer、fmt.Stringer 都是只包含一个方法的接口。以下是 Go 中遵循 ISP 的具体实践：

接口方法数控制在 1~3 个：超过 3 个方法时，应审视是否职责过多。
按角色拆分接口：根据调用方的角色（生产者、消费者、校验者）定义不同的接口。
使用接口组合：通过小接口组合成更大的接口，而不是直接定义大接口。
在调用方一侧定义接口：Go 的隐式实现允许调用方只声明自己需要的方法集合。
避免“上帝接口”：不要试图用一个接口覆盖所有场景。

接口组合示例：

// 小接口定义
type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type Closer interface {
    Close() error
}

// 组合成更大的接口
type ReadWriter interface {
    Reader
    Writer
}

type ReadWriteCloser interface {
    Reader
    Writer
    Closer
}

2.4 胖接口重构案例

假设有一个遗留的 UserService 接口，包含了用户管理的所有操作：

// 胖接口：包含 7 个方法
type UserService interface {
    Create(ctx context.Context, user *User) error
    Get(ctx context.Context, id int64) (*User, error)
    Update(ctx context.Context, user *User) error
    Delete(ctx context.Context, id int64) error
    List(ctx context.Context, filter *Filter) ([]*User, error)
    SendWelcomeEmail(ctx context.Context, userID int64) error
    ExportToCSV(ctx context.Context, filter *Filter) ([]byte, error)
}

重构步骤：

识别客户端角色：分析调用方，发现存在三种角色——CRUD 操作者、通知发送者、数据导出者。
按角色拆分：将胖接口拆分为三个独立的小接口。
组合复用：对于需要全部功能的客户端，使用接口组合。

// 重构后：三个小接口
type UserRepository interface {
    Create(ctx context.Context, user *User) error
    Get(ctx context.Context, id int64) (*User, error)
    Update(ctx context.Context, user *User) error
    Delete(ctx context.Context, id int64) error
    List(ctx context.Context, filter *Filter) ([]*User, error)
}

type NotificationSender interface {
    SendWelcomeEmail(ctx context.Context, userID int64) error
}

type DataExporter interface {
    ExportToCSV(ctx context.Context, filter *Filter) ([]byte, error)
}

// 组合接口：仅当客户端需要全部功能时使用
type FullUserService interface {
    UserRepository
    NotificationSender
    DataExporter
}

重构收益： 现在，一个只需要发送通知的模块只需依赖 NotificationSender 接口，Mock 时也只需实现一个方法。测试代码量减少 70% 以上。

2.5 ISP 与 Mock 测试的关联

在 Go 的 Mock 隔离测试中，ISP 原则直接影响测试的简洁性：

小接口 = 小 Mock：每个 Mock 对象只需实现 1~2 个方法，代码量少，易于维护。
减少桩代码：胖接口的 Mock 需要为每个无用方法编写空实现或 panic 占位，这些代码在测试中毫无价值。
精准验证：小接口的调用验证更聚焦，测试用例只关心被测试模块实际调用的方法。

2.6 接口隔离的度量指标

在实际项目中，可以通过以下指标判断接口是否违反了 ISP：

指标	健康值	警告值	危险值
接口方法数	1 ~ 3	4 ~ 6	≥ 7
实现方空方法占比	0%	20% ~ 40%	> 40%
Mock 桩代码行数占比	< 10%	10% ~ 30%	> 30%
接口调用方数量	每个方法 2~5 个调用方	部分方法 0 调用方	大部分方法 0 调用方

实践建议： 在 Code Review 中，如果发现一个接口的实现方有超过 30% 的方法体是 return nil 或 panic("not implemented")，这通常是胖接口的强烈信号，应立即进行 ISP 重构。

2.7 本章小结

ISP 核心：客户端不应依赖它不使用的方法。
胖接口危害：实现负担、耦合升高、测试困难、语义模糊。
Go 最佳实践：小接口、按角色拆分、接口组合、调用方定义接口。
Mock 关联：小接口直接带来小 Mock，减少桩代码，提升测试质量。
度量指标：方法数、空方法占比、桩代码占比、调用方覆盖度。