3. 接口设计原则：最小接口原则、接口隔离原则(ISP)、单一职责在接口中的体现

在 Go 业务模块的边界接口契约设计中，接口的粒度与职责划分直接决定了系统的可维护性、可测试性和演进能力。本章聚焦三个核心原则：最小接口原则、接口隔离原则（ISP）以及单一职责原则在接口中的体现。这三者共同构成了“小而专”的接口设计哲学，是避免“胖接口”和“无效依赖”的关键约束。

3.1 最小接口原则：只暴露调用方真正需要的行为

最小接口原则（Least Knowledge Principle 在接口层面的应用）要求：一个接口只包含调用方当前场景下真正需要的方法，不多不少。过度暴露的方法会形成隐式契约负担，增加实现方的耦合风险。

3.1.1 违反最小接口的典型反例

// 反例：一个“万能”的订单接口
type OrderService interface {
    Create(ctx context.Context, order *Order) error
    Cancel(ctx context.Context, orderID string) error
    Pay(ctx context.Context, orderID string) error
    Refund(ctx context.Context, orderID string) error
    Query(ctx context.Context, orderID string) (*Order, error)
    Export(ctx context.Context, start, end time.Time) ([]Order, error)
    Notify(ctx context.Context, orderID string) error
}

上述接口中，Export 和 Notify 方法对于“创建订单”的调用方而言是多余的。调用方被迫依赖一个更大的接口，导致实现方必须为不需要的方法提供空实现或 panic 占位。

3.1.2 遵循最小接口的改进方案

// 按调用场景拆分
type OrderCreator interface {
    Create(ctx context.Context, order *Order) error
}

type OrderCanceller interface {
    Cancel(ctx context.Context, orderID string) error
}

type OrderQuerier interface {
    Query(ctx context.Context, orderID string) (*Order, error)
}

type OrderExporter interface {
    Export(ctx context.Context, start, end time.Time) ([]Order, error)
}

3.2 接口隔离原则（ISP）：客户端不应被迫依赖它们不使用的方法

接口隔离原则（Interface Segregation Principle）是 Robert C. Martin 提出的 SOLID 原则之一。它与最小接口原则高度相关，但更强调“按客户端角色”进行接口切分。ISP 的核心主张是：多个面向特定客户的接口，优于一个面向通用场景的胖接口。

3.2.1 ISP 在业务模块中的典型应用

以“用户管理”模块为例，不同客户端对用户服务的需求完全不同：

• 管理后台：需要创建用户、禁用用户、重置密码、查询所有用户。
• 登录服务：只需要验证密码、获取用户基本信息。
• 个人中心：只需要更新个人信息、修改密码。

// 违反 ISP：一个接口服务所有客户端
type UserService interface {
    Create(ctx context.Context, user *User) error
    Disable(ctx context.Context, userID string) error
    ResetPassword(ctx context.Context, userID string) error
    ListAll(ctx context.Context) ([]User, error)
    Authenticate(ctx context.Context, username, password string) (*User, error)
    GetProfile(ctx context.Context, userID string) (*User, error)
    UpdateProfile(ctx context.Context, user *User) error
    ChangePassword(ctx context.Context, userID, oldPwd, newPwd string) error
}

// 遵循 ISP：按客户端角色拆分
type UserAdmin interface {
    Create(ctx context.Context, user *User) error
    Disable(ctx context.Context, userID string) error
    ResetPassword(ctx context.Context, userID string) error
    ListAll(ctx context.Context) ([]User, error)
}

type UserAuthenticator interface {
    Authenticate(ctx context.Context, username, password string) (*User, error)
    GetProfile(ctx context.Context, userID string) (*User, error)
}

type UserProfileManager interface {
    GetProfile(ctx context.Context, userID string) (*User, error)
    UpdateProfile(ctx context.Context, user *User) error
    ChangePassword(ctx context.Context, userID, oldPwd, newPwd string) error
}

3.3 单一职责在接口中的体现：一个接口只描述一个职责维度

单一职责原则（Single Responsibility Principle, SRP）在接口层面的含义是：一个接口应该只描述一个职责维度的行为契约，不应该将不同变化方向的行为耦合在同一个接口中。判断标准是：如果接口中的方法因为不同的原因而需要修改，则说明该接口承担了多个职责。

3.3.1 职责耦合的识别方法

3.3.2 从“大接口”到“单一职责接口”的演进

// 职责耦合的接口：同时承担“存储”和“通知”两个职责
type OrderRepository interface {
    Save(ctx context.Context, order *Order) error
    FindByID(ctx context.Context, orderID string) (*Order, error)
    SendConfirmation(ctx context.Context, orderID string) error
    SendShippingUpdate(ctx context.Context, orderID string, status string) error
}

// 遵循 SRP：拆分为两个职责独立的接口
type OrderStore interface {
    Save(ctx context.Context, order *Order) error
    FindByID(ctx context.Context, orderID string) (*Order, error)
}

type OrderNotifier interface {
    SendConfirmation(ctx context.Context, orderID string) error
    SendShippingUpdate(ctx context.Context, orderID string, status string) error
}

3.4 三原则的关系与综合应用

最小接口原则、接口隔离原则和单一职责原则在 Go 接口设计中形成递进关系：

• 最小接口原则 是“度”的约束：接口方法数量以调用方实际需求为准。
• 接口隔离原则 是“切分方式”：按客户端角色切分接口，避免胖接口。
• 单一职责原则 是“内聚性”要求：接口内部的方法应属于同一个变化维度。

3.5 实战检查清单

在 Go 业务模块的接口设计评审中，可以使用以下清单快速评估接口质量：

1. 接口方法数量：是否超过 5 个？如果是，考虑是否违反了最小接口原则。
2. 调用方分析：当前接口是否被多个不同角色的客户端使用？如果是，考虑按 ISP 拆分。
3. 变化原因分析：接口中的方法是否因为不同的业务原因而需要修改？如果是，考虑按 SRP 拆分。
4. 空实现检查：是否存在实现方为某些方法提供了 panic 或 return nil 的空实现？如果是，说明接口过胖。
5. 测试 mock 复杂度：mock 当前接口需要为多少个方法提供桩代码？超过 3 个通常意味着接口需要拆分。