17370845950

Go中应优先用interface+依赖注入替代硬编码依赖，将数据库、HTTP客户端等抽象为接口并作为参数传入构造函数，便于测试mock和环境切换；工厂函数统一创建复杂对象，策略模式用map[string]func封装算法分支，组合优于嵌套，通过embed接口实现横切逻辑复用。

用 interface + 依赖注入替代硬编码依赖

Go 没有类继承，但通过 interface 定义契约、用结构体实现、再把依赖作为参数传入，能轻松替换行为而不改调用方。硬编码 new(SomeService) 会锁死实现，导致相同逻辑在多个地方重复构造。

实操建议：

• 把可变部分（如数据库、HTTP 客户端、缓存）抽象为 interface，例如 type UserRepository interface { GetByID(id int) (*User, error) }
• 构造函数接收这些接口，而非具体类型： func NewUserService(repo UserRepository) *UserService
• 测试时直接传入 mock 实现；上线时注入真实 DB 或内存缓存实现 —— 同一份业务逻辑复用在不同环境

工厂函数统一创建复杂对象

当结构体初始化需要校验、默认值填充、资源预分配（如连接池），或存在多种变体（FileLogger / CloudLogger），裸写 &Logger{...} 会散落在各处，难以收敛和升级。

实操建议：

• 定义工厂函数，如 func NewLogger(cfg LoggerConfig) Logger，内部完成校验、默认值合并、资源初始化
• 若需多态创建，返回 interface{} 或更具体的接口，避免暴露具体类型
• 配置结构体用指针接收（func NewLogger(cfg *LoggerConfig)），方便 nil 判断和零值 fallback

策略模式用 map[string]func 封装算法分支

if/else 或 switch 处理支付方式、压缩算法、序列化格式时，新增一种实现就得改主逻辑，违反开闭原则，也容易漏掉某处的 case 分支。

实操建议：

• 定义统一输入输出签名的函数类型： type Processor func([]byte) ([]byte, error)
• 用 map[string]Processor 注册所有策略：processors["gzip"] = gzipProcess
• 运行时按 key 查找执行，新增策略只需注册，不碰调度代码
• 注意并发安全：注册应在 init 阶段或加锁，运行时查表是无锁的

组合优于嵌套：用 embed + 接口复用通用能力

想让多个结构体都具备重试、超时、日志打点能力，不要每个都重写 DoWithRetry 方法，也不要用匿名字段强行“继承”—— Go 的 embed 是编译期静态组合，必须配合接口才能动态替换行为。

实操建议：

• 把横切逻辑抽成独立结构体，实现明确接口（如 type Retrier interface { Do(fn func() error) error }）
• 在业务结构体中 embed 该接口字段：retrier Retrier，而不是 embed 具体类型
• 构造时注入不同实现（带 exponential backoff 的、mock 不重试的、测试用固定失败次数的）
• 避免 embed 具体类型（如 retrier *DefaultRetrier），否则又回到强耦合

type Service struct {
    retrier Retrier
    db      Database
}

func (s *Service) CreateUser(u User) error {
    return s.retrier.Do(func() error {
        return s.db.Insert(&u)
    })
}

真正难的不是写出某个模式，而是判断什么时候该收口、什么时候该开放；比如一个 Processor map 看似灵活，但如果策略之间共享状态或需要生命周期管理，就得退回到接口+依赖注入。复用率高不高，最终看的是变化点是否被隔离到最小、最易替换的单元里。