时间戳

首页 > 解决方案 > 同一个结构的多个接口

oop - 同一个结构的多个接口

问题描述

我正在学习 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(ne)
  temp      := getNightTemp(ne)

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

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

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

标签： oopgostruct

解决方案

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

推荐阅读