同一结构的多个接口

Question

我正在学习 Go 并想知道在某些情况下是否认为 Golang 中的好/好/典型（鼓励？）实践根据消费者代码将使用该结构做什么来创建多个interface变struct体？

我在质疑这一点，因为我有一个结构对象可以说在我的代码库中做了太多事情，我想添加一些测试并只模拟该结构的某些用法/消费者。说我有，

对于（人为的）示例，环境结构

// Environment/env.go

package env

type Environment struct {
  sunny bool,
  fullMoon bool,
  temp float64
  // ...
}

func (e *Environment) IsSunny() bool {
  return e.sunny
}

func (e *Environment) IsFullMoon() bool {
  return e.fullMoon
}

func (e *Environment) GetTemp() float64 {
  return e.temp
}

上述结构具有与一些环境条件（白天和黑夜时间）相关的属性和方法。

然后这个结构有多个消费者，但每个消费者interface只关心可用方法的一个子集：

// daytime.go

type DayEnv interface {
  IsSunny() bool
  GetTemp() float64
}

func getDaytime(de DayEnv) {
  sunStatus := getSunStatus(de)
  temp      := getDayTemp(de)

  fmt.Printf("Today is %s and temperature is %s", sunStatus, temp)
}

// func getSunStatus(de DayEnv) string {}
// func getDayTemp(de DayEnv) string {}

// nightTime.go

type NightEnv interface {
  IsFullMoon() bool
  GetTemp() float64
}


func getNighttime(ne NightEnv) {
  moonPhase := getMoonPhase(nightEnv)
  temp      := getNightTemp(nightEnv)

  fmt.Printf("Tonight the moon is %s and temperature is %s", moonPhase, temp)
}

// func getMoonPhase(ne NightEnv) string { }
// func getNightTemp(ne NightEnv) string { }

在我看来，虽然创建一个只关注结构方法子集的新接口使事情变得更加灵活，但拥有如此多（部分）重复的接口并根据需要或任何地方撒播它们也感觉相当懒惰或错误他们被消耗了。我意识到这个例子有点人为，但在更大的范围内（就像许多消费者一样），或者一个文件可能具有x相同结构的接口......这种方法有什么问题吗？

Answer 1

这种方式没有任何问题，Go 标准库经常使用它。例如，有许多结构体实现了 io.Reader、io.Writer、io.Closer 和 io.Seeker 的组合。这些结构的用户指定他们需要什么类型的接口并使用它。