3、接口隔离原则：Go中接口定义的最佳实践、面向接口编程、小接口设计

接口隔离原则（Interface Segregation Principle, ISP）是SOLID原则中的“I”。在Go语言中，这条原则被语言本身的设计哲学推向了极致——Go不要求显式声明实现关系，任何类型只要实现了接口的所有方法，就自动满足该接口。这种“隐式实现”机制，使得小接口设计成为Go工程实践的基石。

3.1 为什么Go天生适合接口隔离

传统面向对象语言（如Java、C#）中，接口通常需要显式声明 implements，导致接口一旦定义，修改成本极高。Go的隐式接口解除了这种耦合：

Go的隐式实现让“接口隔离”从设计建议变成了自然习惯——你不需要提前定义庞大的接口，而是随着需求演化，逐步提取出最小粒度的行为契约。

3.2 小接口设计：1~3个方法是最佳实践

Go标准库中充斥着经典的小接口范例：

// io.Reader — 只做一件事：读取
type Reader interface {
    Read(p []byte) (n int, err error)
}

// io.Writer — 只做一件事：写入
type Writer interface {
    Write(p []byte) (n int, err error)
}

// io.Closer — 只做一件事：关闭
type Closer interface {
    Close() error
}

// 通过组合构建更强大的接口
type ReadWriter interface {
    Reader
    Writer
}

小接口设计的核心原则：

• 单一职责：每个接口只描述一个行为维度
• 方法数量：1~3个方法，超过3个考虑拆分
• 命名即契约：接口名直接表达能力（如 Storer、Logger、Notifier）
• 组合优于继承：通过接口嵌入构建复杂行为

3.3 面向接口编程：依赖倒置与Mock隔离

面向接口编程的核心是“依赖倒置原则”（Dependency Inversion Principle, DIP）：高层模块不应该依赖低层模块，两者都应该依赖抽象（接口）。

在Go中，这意味着：

• 业务逻辑层依赖接口，不依赖具体实现
• 具体实现（如数据库、外部API）注入到业务层
• 测试时用Mock实现替换真实依赖

// 定义小接口
type UserRepository interface {
    FindByID(id string) (*User, error)
    Save(user *User) error
}

// 业务层只依赖接口
type UserService struct {
    repo UserRepository
}

func NewUserService(repo UserRepository) *UserService {
    return &UserService{repo: repo}
}

func (s *UserService) GetUser(id string) (*User, error) {
    return s.repo.FindByID(id)
}

// 生产环境：真实数据库实现
type PostgresUserRepo struct { /* ... */ }
func (p *PostgresUserRepo) FindByID(id string) (*User, error) { /* 真实查询 */ }
func (p *PostgresUserRepo) Save(user *User) error { /* 真实写入 */ }

// 测试环境：Mock实现
type MockUserRepo struct {
    users map[string]*User
}
func (m *MockUserRepo) FindByID(id string) (*User, error) {
    user, ok := m.users[id]
    if !ok {
        return nil, ErrNotFound
    }
    return user, nil
}
func (m *MockUserRepo) Save(user *User) error {
    m.users[user.ID] = user
    return nil
}

3.4 接口隔离原则在Mock隔离中的价值

下面的SVG图展示了接口大小对Mock隔离的影响对比：

3.5 接口组合：从原子接口构建复杂行为

小接口的真正威力在于组合。Go通过接口嵌入（embedding）实现零成本的接口组合：

// 原子接口
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
}

// 业务层组合示例
type UserService interface {
    Reader
    Writer
    Closer
}

接口组合的优势：

• 按需取用：消费者只依赖自己需要的原子接口
• 零侵入：新增组合接口不影响已有实现
• 测试灵活：可以只Mock需要的部分

3.6 实战：从大接口重构为小接口

假设你接手了一个遗留系统，其中有一个庞大的 OrderService 接口：

// 反模式：大接口
type OrderService interface {
    CreateOrder(order *Order) error
    GetOrder(id string) (*Order, error)
    UpdateOrder(order *Order) error
    CancelOrder(id string) error
    CalculateTotal(id string) (float64, error)
    SendConfirmation(id string) error
    GenerateInvoice(id string) ([]byte, error)
    ArchiveOrder(id string) error
}

重构步骤：

1. 识别行为维度：查询、写入、计算、通知、归档
2. 提取原子接口：每个维度一个接口
3. 组合业务接口：按需组合

// 重构后：小接口
type OrderReader interface {
    GetOrder(id string) (*Order, error)
}

type OrderWriter interface {
    CreateOrder(order *Order) error
    UpdateOrder(order *Order) error
    CancelOrder(id string) error
}

type OrderCalculator interface {
    CalculateTotal(id string) (float64, error)
}

type OrderNotifier interface {
    SendConfirmation(id string) error
}

type OrderArchiver interface {
    ArchiveOrder(id string) error
    GenerateInvoice(id string) ([]byte, error)
}

// 按需组合
type FullOrderService interface {
    OrderReader
    OrderWriter
    OrderCalculator
    OrderNotifier
    OrderArchiver
}

3.7 接口隔离与Mock隔离的协同效应

下面的SVG图展示了接口隔离如何直接降低Mock隔离的复杂度：

3.8 接口定义的最佳实践清单