Go语言中的Interface

先给你们拜个早年：狗年旺旺旺

最近在看Go语言的面向对象的知识点时，发现它的面向对象能力全靠 interface 撑着，并且它的 interface 还与咱们之前知道的 interface 彻底不一样。故而整个过程不断的思考为何要如此设计？这样设计给咱们带来了什么影响？

interface 我不懂你

Rob Pike 曾说：

若是只能选择一个Go语言的特 性移植到其余语言中，他会选择接口

被Go语言设计者如此看重，想来 interface 必定是资质不凡，颜值爆表。可是说实话，当我第一次读这部份内容的时候，我产生了如下三个问题：

1. 原来的 implement 方式产生了什么问题，我用的很差好的吗？
2. 若是不经过 implement 把接口与实现类强制关联起来，它怎么知道我实现的哪一个接口？
3. 这么干为实际编码带来了什么影响或者说好处？

带着这些问题我进行了一些比较与分析，Rob Pike 如此说，不多是想骗咱们都去用 Go，毕竟你们都是上太小学的，骗不了大家。

侵入式与非侵入式

在诸多的资料中，你们都提到 侵入式 与 非侵入式 这样的概念，我用代码来解释下这两个概念。

PHP 中的侵入式：

interface Person {
    public function getAge();
    public function getName();
}

class Student implements Person {
    private $age;

    private $name;

    public function getAge() {
        return $this->age;
    }
    
    public function getName() {
        return $this->name;
    }
}

复制代码

Go 中的非侵入式

type Person interface {
	GetAge() int
	GetName() string
}

type Student struct {
	age int
	name string
}

func (s Student) GetAge() int {
	return s.age
}

func (s Student) GetName() string {
	return s.name
}

func main() {
	var p Person= Student{20, "Elon"}

	fmt.Println("This person name is", p.GetName())
	fmt.Println("This person age is", p.GetAge())
}
复制代码

经过上面的代码我总结了如下问题：

1. 侵入式经过 implements 把实现类与具体接口绑定起来了，所以有了强耦合;
2. 若是我修改了接口，好比改了接口方法，则实现类必须改动；
3. 若是我但愿实现类再实现一个接口，实现类也必须进行改动；
4. 后续跟进者，必须了解相关的接口。

这几个问题是开发中常常遇到的问题，而 Go 非侵入式的方式完美解决了这几个问题。他只要实现了与接口定义相同的方法，就算实现了某个接口，最重要的，随着代码的增长，你的类结构不会像 Java 那样发生爆炸。由于你根本不用关心你实现了什么接口，你只须要关心你的类有什么方法，方法有什么功能。在实现类的时候也不须要像 Java、PHP 同样引入各类接口，有可能你定义类的时候，某个接口还不存在，接下来我单独说说该方式的意义。

interface 意义非凡

在我没有理解以前，我以为Go的接口很变扭，之前的码代码的思路都是：先设计好接口，再去作具体的实现。如今一个类你可能根本分不清他实现了那个接口。仍是上面的例子，稍微改一下

type Person interface {
	GetAge() int
	GetName() string
}

type Car interface {
	GetAge() int
	GetName() string
}

type Student struct {
	age int
	name string
}

func (s Student) GetAge() int {
	return s.age
}

func (s Student) GetName() string {
	return s.name
}
复制代码

这里有两个接口 Person、Car 他们有相同的方法，而 Student 实现了这两个方法，在 Go 里边就能够说他同时实现了这两个接口，不信你试试

func main() {
	var p Person= Student{20, "Elon"}

	fmt.Println("This person name is", p.GetName())
	fmt.Println("This person age is", p.GetAge())
	
	var c Car= Student{1, "BMW"}

	fmt.Println("This car name is", c.GetName())
	fmt.Println("This car age is", c.GetAge())
}
复制代码

这里只是为了说明问题，名字上看起来有点诡异(Student 居然能够是车？上车就是上 Student？)

这种能力带来的真正让人吃惊的地方是什么？今后之后我能够先写类了，我先根据实际状况把类的功能作好，在某个我具体须要使用的地方，我再定义接口。说的专业点：也就是接口是由使用方根据本身真实需求来定义，而且不用关心是否有其它使用方定义过。

这样子到底解决了什么开发中的问题？举个例子：咱们一个大团队在开发一个商城系统，m端、app端、pc端都有购物车的需求，底层根据不一样的需求已经实现了一个Cart类，经过该类能够获取购物车价格、数量等。例如：

type Cart struct {
	price float32
	num int
}

func (c Cart) GetPrice() float32 {
    return c.price
}

func (c Cart) GetNum() int {
    return c.num
}
复制代码

这个时候前端要进行调用了，他们能够自由定义接口名称用于接受，只须要关心本身的接口须要什么方法，Cart 是否所有实现了须要的方法，每个端彻底能够本身定义一个接口，接口名称、定义的方法顺序均可以不一样。

我以为这才是真正作到了：依赖于接口而不是实现，优先使用组合而不是继承

---

欢迎指正交流