title: Multiple interfaces for the same struct
body: <p>I'm learning Go and wondering in some cases if it is considered good/okay/typical (encouraged?) practice in Golang to create several <code>interface</code> variations for the same <code>struct</code> depending on what the consumer code will be doing with that struct?</p>
  <p>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,</p>
  <p>for a (contrived) example, an Environment struct</p>
  <pre class="lang-golang prettyprint-override"><code>// 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
  }
  </code></pre>
  <p>The above struct has properties and methods related to some of the environment conditions (day and night time).</p>
  <p>Then there are multiple consumers of this struct, but each <code>interface</code> only cares about a subset of the available methods:</p>
  <pre class="lang-golang prettyprint-override"><code>// daytime.go
  
  type DayEnv interface {
    IsSunny() bool
    GetTemp() float64
  }
  
  func getDaytime(de DayEnv) {
    sunStatus := getSunStatus(de)
    temp      := getDayTemp(de)
  
    fmt.Printf(&quot;Today is %s and temperature is %s&quot;, sunStatus, temp)
  }
  
  // func getSunStatus(de DayEnv) string {}
  // func getDayTemp(de DayEnv) string {}
  </code></pre>
  <pre class="lang-golang prettyprint-override"><code>// nightTime.go
  
  type NightEnv interface {
    IsFullMoon() bool
    GetTemp() float64
  }
  
  
  func getNighttime(ne NightEnv) {
    moonPhase := getMoonPhase(ne)
    temp      := getNightTemp(ne)
  
    fmt.Printf(&quot;Tonight the moon is %s and temperature is %s&quot;, moonPhase, temp)
  }
  
  // func getMoonPhase(ne NightEnv) string { }
  // func getNightTemp(ne NightEnv) string { }
  </code></pre>
  <p>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 <code>x</code> interfaces for the same struct... is there anything wrong with this approach?</p>