同一结构的多个接口

Question

I'm learning Go and wondering in some cases if it is considered good/okay/typical (encouraged?) practice in Golang to create several interface variations for the same struct depending on what the consumer code will be doing with that struct?

I'm questioning this because I have a struct object that is arguably doing too much in my codebase and I want to add some tests and mock only certain usages/consumers of that struct. Say I have,

for a (contrived) example, an Environment 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
}

The above struct has properties and methods related to some of the environment conditions (day and night time).

Then there are multiple consumers of this struct, but each interface only cares about a subset of the available methods:

// 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 { }

It seems to me while making a new interface that is only concerned with a subset of the struct methods makes things more flexible, it also feels fairly lazy or wrong to have so much (partial) duplication of interfaces and to sprinkle them as need or wherever they are consumed. I realize this example is a bit contrived, but on a larger scale (like many, many consumers), or perhaps one file has x interfaces for the same struct... is there anything wrong with this approach?

Answer 1

There is nothing wrong with this approach, and Go standard library uses it often. For instance, there are many structs that implement a combination of io.Reader, io.Writer, io.Closer, and io.Seeker. The users of those structs specify what type of interface they need and use that.