17370845950

Go中适配器模式通过组合+接口隐式实现：用结构体字段持有被适配对象，手动实现目标接口方法并委托调用；不依赖继承，关键在于隐式满足接口契约。

适配器模式在 Go 里没有接口继承，怎么写？

Go 没有传统 OOP 的「类继承」和「接口继承」，所以不能像 Java 那样让适配器类 extends Target implements Adaptee。它的适配器本质是「组合 + 接口隐式实现」：用一个字段持有被适配对象，再通过结构体方法满足目标接口。

关键点在于：Go 接口是隐式实现的，只要结构体提供了接口要求的所有方法签名，就自动实现了该接口——不需要 implements 声明。

• 适配器结构体里嵌入或持有原对象（Adaptee），不继承，只组合
• 适配器自己实现目标接口（Target）的方法，内部转发/转换调用原对象
• 如果原对象已有部分匹配方法，可直接嵌入提升（type Adapter struct { *Adaptee }），但要注意方法名冲突和语义一致性

写一个文件读取器适配器：把 os.File 适配成自定义 Reader 接口

常见场景：已有 *os.File，但下游只接受你定义的 MyReader 接口，而它比 io.Reader 多一个 Path() 方法。这时就得写适配器桥接。

注意：别试图让 *os.File 直接实现 MyReader（无法修改标准库类型），而是封装一层。

type MyReader interface {
    Read(p []byte) (n int, err error)
    Path() string
}

type FileReaderAdapter struct {
    file *os.File
    path string
}

func NewFileReaderAdapter(f *os.File, path string) *FileReaderAdapter {
    return &FileReaderAdapter{file: f, path: path}
}

func (a *FileReaderAdapter) Read(p []byte) (int, error) {
    return a.file.Read(p) // 直接委托
}

func (a *FileReaderAdapter) Path() string {
    return a.path // 补充原类型没有的信息
}

这样下游就能安全传入 *FileReaderAdapter，完全满足 MyReader 接口，且不侵入原有逻辑。

什么时候该用嵌入（embedding）而不是显式字段？

当被适配对象的大部分方法你都想直接暴露，仅需调整少数几个时，嵌入更简洁；但必须小心「方法提升带来的意外行为」。

• 嵌入 *Adaptee 后，所有公开方法自动成为适配器的方法——包括你不希望暴露的（比如 Close()）
• 如果目标接口只要求 Read()，但嵌入后用户还能调 Write()，就破坏了接口契约
• 若只是轻量转换（如改返回值、加日志、转编码），推荐显式字段 + 手动委托，控制力更强

例如，适配一个返回 error 的旧函数为返回 *MyError 的新接口，就不能靠嵌入，必须手动包装：

func (a *LegacyAdapter) Do() *MyError {
    if err := a.legacy.Do(); err != nil {
        return &MyError{Msg: err.Error()}
    }
    return nil
}

容易踩的坑：空指针、生命周期和接口零值

适配器本身是普通结构体，如果字段没初始化就调用方法，会 panic；另外 Go 接口变量可为 nil，但调用其方法不一定 panic——取决于底层具体类型是否允许 nil 接收者。

• var r MyReader 是 nil 接口，此时 r.Read(...) 会 panic：「nil pointer dereference」（如果底层是 *FileReaderAdapter 且方法接收者是指针）
• 构造函数（如 NewXXXAdapter）必须校验依赖是否非 nil，尤其对 *os.File 这类资源句柄
• 不要在适配器里缓存不可复用的状态（如已关闭的 file），否则后续调用会失败

最稳妥的做法：所有适配器方法都做前置检查，或依赖构造函数保证字段有效性。

适配器模式在 Go 里不是语法糖，而是明确的组合意图表达。真正难的不是写法，是判断「哪里真的需要适配」——很多情况下，直接重构调用方接口，比套一层适配器更干净。