In the last video we saw that the Golang interface concept is all theory. Is the so-called light said not practice false handle, how to achieve it in the final analysis? Let’s move on:

Interface syntax format

Type Interface name interface{Method name 1 (Parameter list 1) Return value 1 Method name 2 (Parameter List 2) Return value 2... }Copy the code

Note that:

The method can be called by code other than the package when both the interface and method names are uppercase.

Here’s an example:

type Filewriter interface{
    Write([]byte) error
}
Copy the code

Implementing an interface

Golang requires a structure to inherit an interface as long as it implements all of its methods.

In other words, an interface provides a constraint on the list of methods that the inherited structure needs to implement.

For example: let’s define an interface Speaker:

// Speaker interface type Speaker interface {speak()}Copy the code

Define two constructs that inherit from Speaker Teacher and Student:

type Teacher struct {}

type Student struct {}
Copy the code

As required by Golang, all the methods in the Speaker interface need to be implemented, even if the interface is inherited. Because there is only method speak() in the interface Speaker, we only need to implement method speak() for Teacher and Student respectively to inherit the interface Speaker

// Teacher implements Speaker func (Teacher Teacher) say() {fmt.println ("Teacher speaking")} // Student implements Speaker func (student Student) say() { fmt.Println("Student speaking") }Copy the code

That implements all the methods in the interface, and that implements the interface.

Inheritance interface function

This might be a bit of a problem if the interface is just used to constrain the list of methods that the inherited structure needs to implement. It’s not mandatory (after all, you don’t implement all methods and don’t report errors like Java does), so it’s not mandatory

From an implementation point of view: the structure implements all the methods of the interface, that is, inheriting the interface, so it is really not mandatory to look at the constraints on how the interface can be written to the same type of structure.

But (there should be emphasis here) from the perspective of use: ** using the interface to achieve the object-oriented concept of polymorphism, look at the interface to the same kind of interface for external use in the call method constraints here is really very mandatory.

Here’s an example:

Package main import "FMT" // Speaker interface type Speaker interface {speak()} // Teacher implements Speaker type Teacher struct {} func (teacher) speak() {fmt.Println(" teacher speaking")} // Student implements Speaker type Student struct {} func (student Student) speak() { fmt.Println("Student speaking") } func (student Student) chat() { fmt.Println("Student Chatting ")} func main() {var teackerSpeaker teackerSpeaker = Teacher{// Instantiate Teacher and assign it to teackerspeaker.speak () // Successfully call method speak() output: Teacher speaking var studentSpeaker Speaker // Declare a Speaker variable studentSpeaker studentSpeaker = Student{} // instantiate StudentSpeaker student.speak () // Call method speak() successfully Student speaking // studentSpeaker. Chat () // Cannot call method chat() because there is no method chat()}Copy the code

As we can see from the code above, even though the Student structure implements the method chat, it cannot call the method chat after assigning to the Speaker variable of type.

This is what I mean when I say that using angles, polymorphism imposes constraints on methods that can be called by homogeneous structures