Go语言中的Interface

2024年5月23日 161次阅读 来源: 大愚Talk

先给大家拜个早年：狗年旺旺旺

最近在看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 是否全部实现了需要的方法，每一个端完全可以自己定义一个接口，接口名称、定义的方法顺序都可以不同。

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

欢迎指正交流

    原文作者：大愚Talk
    原文地址: https://segmentfault.com/a/1190000013280677
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞