i = t // cannot use t (type T) as type Interface in assignment: T does not implement Interface (M2 method has pointer receiver)
}
复制代码
在这个例子中，我们定义了一个接口类型 Interface 以及一个自定义类型 T。Interface 接口类型包含了两个方法 M1 和 M2，代码中还定义了基类型为 T 的两个方法 M1 和 M2，但它们的 receiver 参数类型不同，一个为 T，另一个为 *T。在 main 函数中，我们分别将 T 类型实例 t 和 *T 类型实例 pt 赋值给 Interface 类型变量 i。
运行一下这个示例程序，我们在 i = t 这一行会得到 Go 编译器的错误提示，Go 编译器提示我们：T 没有实现 Interface 类型方法列表中的 M2，因此类型 T 的实例 t 不能赋值给 Interface 变量。
可是，为什么呢？为什么 *T 类型的 pt 可以被正常赋值给 Interface 类型变量 i，而 T 类型的 t 就不行呢？如果说 T 类型是因为只实现了 M1 方法，未实现 M2 方法而不满足 Interface 类型的要求，那么 *T 类型也只是实现了 M2 方法，并没有实现 M1 方法啊？
有些事情并不是表面看起来这个样子的。了解方法集合后，这个问题就迎刃而解了。同时，方法集合也是用来判断一个类型是否实现了某接口类型的唯一手段，可以说，“方法集合决定了接口实现”。
3.2 类型的方法集合
Go 中任何一个类型都有属于自己的方法集合，或者说方法集合是 Go 类型的一个“属性”。但不是所有类型都有自巴基斯坦的方法呀，比如 int 类型就没有。所以，对于没有定义方法的 Go 类型，我们称其拥有空方法集合。
接口类型相对特殊，它只会列出代表接口的方法列表，不会具体定义某个方法，它的方法集合就是它的方法列表中的所有方法，我们可以一目了然地看到。
为了方便查看一个非接口类型的方法集合，这里提供了一个函数 dumpMethodSet，用于输出一个非接口类型的方法集合：
func dumpMethodSet(i interface{}) {
dynTyp := reflect.TypeOf(i)
if dynTyp == nil {
fmt.Printf("there is no dynamic type\n")
return
}
n := dynTyp.NumMethod()
if n == 0 {
fmt.Printf("%s's method set is empty!\n", dynTyp)
return
}
fmt.Printf("%s's method set:\n", dynTyp)
for j := 0; j < n; j++ {
fmt.Println("-", dynTyp.Method(j).Name)
}
fmt.Printf("\n")
}
复制代码
下面我们利用这个函数，试着输出一下 Go 原生类型以及自定义类型的方法集合，看下面代码：
type T struct{}
func (T) M1() {}
func (T) M2() {}
func (*T) M3() {}
func (*T) M4() {}
func main() {
var n int
dumpMethodSet(n)
dumpMethodSet(&n)
var t T
dumpMethodSet(t)
dumpMethodSet(&t)
}
复制代码
运行这段代码，我们得到如下结果：
int's method set is empty!
*int's method set is empty!
main.T's method set:
- M1
- M2
*main.T's method set:
- M1
- M2
- M3
- M4
复制代码
我们看到以 int、*int 为代表的 Go 原生类型由于没有定义方法，所以它们的方法集合都是空的。自定义类型 T 定义了方法 M1 和 M2，因此它的方法集合包含了 M1 和 M2，也符合我们预期。但 *T 的方法集合中除了预期的 M3 和 M4 之外，居然还包含了类型 T 的方法 M1 和 M2！
不过，这里程序的输出并没有错误。
这是因为，Go 语言规定，*T 类型的方法集合包含所有以 *T 为 receiver 参数类型的方法，以及所有以 T 为 receiver 参数类型的方法。这就是这个示例中为何 *T 类型的方法集合包含四个方法的原因。
这个时候，你是不是也找到了前面那个示例中为何 i = pt 没有报编译错误的原因了呢？我们同样可以使用 dumpMethodSet 工具函数，输出一下那个例子中 pt 与 t 各自所属类型的方法集合：
type Interface interface {
M1()
M2()
}
type T struct{}
func (t T) M1() {}
func (t *T) M2() {}
func main() {
var t T
var pt *T
dumpMethodSet(t)
dumpMethodSet(pt)
}
复制代码
运行上述代码，我们得到如下结果：
main.T's method set:
- M1
*main.T's method set:
- M1
- M2
复制代码
通过这个输出结果，我们可以一目了然地看到 T、*T 各自的方法集合。
我们看到，T 类型的方法集合中只包含 M1，没有 Interface 类型方法集合中的 M2 方法，这就是 Go 编译器认为变量 t 不能赋值给 Interface 类型变量的原因
在输出的结果中，我们还看到 *T 类型的方法集合除了包含它自身定义的 M2 方法外，还包含了 T 类型定义的 M1 方法，*T 的方法集合与 Interface 接口类型的方法集合是一样的，因此 pt 可以被赋值给 Interface 接口类型的变量 i。
到这里，我们已经知道了所谓的方法集合决定接口实现的含义就是：如果某类型 T 的方法集合与某接口类型的方法集合相同，或者类型 T 的方法集合是接口类型 I 方法集合的超集，那么我们就说这个类型 T 实现了接口 I。或者说，方法集合这个概念在 Go 语言中的主要用途，就是用来判断某个类型是否实现了某个接口。
四、选择 receiver 参数类型的第三个原则
理解了方法集合后，我们再理解第三个原则的内容就不难了。这个原则的选择依据就是 T 类型是否需要实现某个接口，也就是是否存在将 T 类型的变量赋值给某接口类型变量的情况。
理解了方法集合后，我们再理解第三个原则的内容就不难了。这个原则的选择依据就是 T 类型是否需要实现某个接口，也就是是否存在将 T 类型的变量赋值给某接口类型变量的情况。
如果 T 类型需要实现某个接口，那我们就要使用 T 作为 receiver 参数的类型，来满足接口类型方法集合中的所有方法。
如果 T 不需要实现某一接口，但 *T 需要实现该接口，那么根据方法集合概念，*T 的方法集合是包含 T 的方法集合的，这样我们在确定 Go 方法的 receiver 的类型时，参考原则一和原则二就可以了。
如果说前面的两个原则更多聚焦于类型内部，从单个方法的实现层面考虑，那么这第三个原则则是更多从全局的设计层面考虑，聚焦于这个类型与接口类型间的耦合关系。
五、小结
在实际进行 Go 方法设计时，我们首先应该考虑的是原则三，即 T 类型是否要实现某一接口。如果 T 类型需要实现某一接口的全部方法，那么我们就需要使用 T 作为 receiver 参数的类型来满足接口类型方法集合中的所有方法。
如果 T 类型不需要实现某一接口，那么我们就可以参考原则一和原则二来为 receiver 参数选择类型了。也就是，如果 Go 方法要把对 receiver 参数所代表的类型实例的修改反映到原类型实例上，那么我们应该选择 *T 作为 receiver 参数的类型。否则通常我们会为 receiver 参数选择 T 类型，这样可以减少外部修改类型实例内部状态的“渠道”。除非 receiver 参数类型的 size 较大，考虑到传值的较大性能开销，选择 *T 作为 receiver 类型可能更适合。 方法集合在 Go 语言中的主要用途就是判断某个类型是否实现了某个接口。方法集合像“胶水”一样，将自定义类型与接口隐式地“粘结”在一起，