Interface in the Go language

This is a creation in Article, where the information may have evolved or changed.

First of all, to worship an early age: the dog of the years Wang Wang

Recently, when looking at the object-oriented knowledge of the go language, it was found that its object-oriented ability depended on interface, and its interface was completely different from the interface we knew before. So the whole process is constantly thinking, why design? What impact does this design have on us?

Interface, I don't understand you.

Rob Pike once said:

If only one feature of the go language can be selected to be ported to another language, he chooses the interface

By Go language designer so value, want to interface must be the qualification uncommon, Yan value explosion table. But to be honest, when I first read this part of the story, I had the following three questions:

1. The original implement way produced what problem, I use bad good?
2. implementHow does it know which interface I implement without forcing the interface to be associated with the implementation class?
3. What is the effect or benefit of doing this for actual coding?

With these questions I carried out some comparisons and analysis, Rob Pike so to speak, it is impossible to deceive us all go with go, after all, we are all on the primary school, can not deceive you.

Intrusive and non-intrusive

In many of the materials, we have mentioned the concept of intrusive and non-intrusive , and I use the code to explain the two concepts.

Intrusive in 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;    }}

Non-intrusive in 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())}

I have summed up the following questions through the code above:

1. By binding the implements implementation class to the specific interface, the intrusive type has strong coupling;
2. If I modify the interface, such as changing the interface method, the implementation class must be changed;
3. If I want to implement a class to implement an interface, the implementation class must also be changed;
4. Follow-up followers must be aware of the relevant interfaces.

These problems are frequently encountered in development, and the Go non-intrusive approach solves these problems perfectly. As long as he implements the same method as the interface definition, even if an interface is implemented, most importantly, as the code increases, your class structure will not explode like Java. Because you don't have to care what interface you implement, you just need to care about what your class has and how it functions. In the implementation of the class does not need to like Java, PHP as the introduction of a variety of interfaces, it is possible that when you define a class, an interface does not exist, then I say the meaning of the way alone.

Interface means extraordinary.

Before I understand, I feel that the interface of Go is very twisted, the previous code of thought is: First design the interface, then to do the specific implementation. Now a class you may not even know he realized that interface. Or the above example, change it a little bit.

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}

Here are two interfaces Person , Car they have the same method, and Student implemented the two methods, in go inside can say he also implemented the two interfaces, do not believe you try

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())}

This is just to illustrate the problem, the name looks a bit strange (Student unexpectedly can be a car?) On the bus is Student? )

What is the real surprise that this ability brings? Since then I can write class, I first according to the actual situation to do the function of the class, in a specific I need to use the place, I define the interface. The point of specialization: that is, the interface is defined by the consumer according to its own real needs, and does not care whether there are other users defined.

What exactly does this look like to solve in the development problem? For example: We have a large team in the development of a mall system, M-side, app-side, PC-side have shopping cart requirements, the bottom of the different requirements have been implemented a cart class, through which can get shopping cart price, quantity and so on. For example:

type Cart struct {    price float32    num int}func (c Cart) GetPrice() float32 {    return c.price}func (c Cart) GetNum() int {    return c.num}

This time the front-end to make calls, they can freely define the interface name for acceptance, only need to care about the interface of their own methods, whether the Cart all implement the required method, each end can define an interface, interface name, the method of the definition of the order can be different.

I think that's what really happened:依赖于接口而不是实现，优先使用组合而不是继承

Welcome to communicate