Go language and Object-Oriented Programming

I have been learning the go language for almost two months. I feel quite happy in this process. I have been turning over the English documents and writing small programs. I always feel that there are a lot of things I don't understand, however, these confusions seem to be indispensable. I thought slowly and finally found a solution, which may not be the best, but I will continue to modify it as I continue to understand it.

Because Java is deeply rooted in my knowledge system, even though I hate something in the Java System. For those who have worked on Java, to learn any new language, they will first ask whether it is an object-oriented language. When I first came into contact with go for a few days, my master asked me if go is an object-oriented language. I blinked, because I have not figured out whether it is. Object-oriented thinking is a good method (I think so ). In strict terms, go is not an object-oriented language. However, many of the methods refer to some object-oriented ideas. Although go is closer to C, developers engaged in Java are still familiar.

Object-oriented features: encapsulation, inheritance, and polymorphism.

Encapsulation: In my own understanding, encapsulation is to assemble some features together. Other objects or classes can use this whole, but not necessarily know the implementation details. This also involves the visibility issue. In Java, the keyword privat, public, and protected is used to determine the access permission. In go, the following method is used: Use case to determine whether the upper case is visible outside the package. The lower case struct or function can only be used in the package. (The keyword of Go is less or less. It can be said that it is mean, which is also a reason for its conciseness ). In Java, each class has its attributes and methods. In go, there is no class concept. Like C, there is a struct concept. Different from the C language, you can define a method that is only used for this struct. The example is much clearer.

// lxy project lxy.gopackage lxyimport "strconv"type Student struct {    Name string    Age  int}func (s *Student) SetName(name string) {    s.Name = name}func (s *Student) GetName() string {    return s.Name}func (s *Student) SetAge(age int) {    s.Age = age}func (s *Student) GetAge() int {    return s.Age}func (s *Student) String() string {    return "name is " + s.Name + ",age is " + strconv.Itoa(s.Age)}

Let's talk about the format defined by the function in go.

Func (ptype)
Funcname (a type) (btype ){}

The red func is the key word for defining the function. It is immutable. The green part is optional. Of course, if this part is available, it is not a function, but a method. This implementation method is equivalent to the definition. This method is only used for instances of this type. The purple part indicates the return value of the function. This is a bit strange. To the languages we are familiar with, both Java and C will put the return value in front of the function name, but go puts it to the end. In addition, functions in go can have 0-N return values and can specify the return value name.

The struct student encapsulates two methods: name and age, which are familiar with including the struct which can be used outside the package. Then several methods are defined for this struct. Let's take a look at the call in the main function.

package mainimport (    "fmt"    "lxy")func main() {    ss := new(lxy.Student)    ss.SetName("lxy")    ss.SetAge(20)    fmt.Println(ss.String())}

In go, to call the content in another package, you must first import. In go, all the content will be defined or used in a specific package. The usage is the package name (method or global variable)

Inheritance: In go, there is no clear description of the inherited keywords. I am using it. I am not sure whether it is a true inheritance. Let alone simulate inheritance. Let's look at the example.

package mainimport (    "fmt"    "lxy")type director struct {    lxy.Student    Name string}func (di *director) GetName() string {    fmt.Println("get director name")    return di.Name}func main() {    ss := new(lxy.Student)    ss.SetName("lxy")    ss.SetAge(20)    dd := new(director)    dd.Name = "director"    dd.Student = *ss    fmt.Println(dd.GetName())fmt.Println(dd.Student.GetName())fmt.Println(dd.GetAge())}

I just added another struct in the package where the main function is located. It contains student and is anonymous. This is actually an inheritance. The Director instance can directly call all methods in student, such as the last statement. In this example, Director contains the getname method and name attribute, which are exactly the same as student, because this does not appear in the same level (what is the same lever? In this example, the name and lxy. Student In ctor are the same level), so the highest level is called. If the variable name or method name is at the same level, it must be explicitly specified. For example

Type a struct {

A int

B string

}

Type B struct {

A int

C string

}

Type C struct {

A

B

}

Call var cc c; CC. A is wrong, because the compiler does not know whether it is the attribute of A or B. It must be specified as CC. a. A or CC. b. A

Polymorphism: What should we say about this concept? There are many different implementation methods for interfaces. For example, an interface method is called. If the cat implements this interface, the result will be "meow"; if the dog implements this method, the result will be "Wang "..... There are also interfaces in go, but the implementation method is a little strange. I 'd like to talk about them in a few minutes, but I 'd like to give an example:

// lxy project lxy.gopackage lxyimport "strconv"type IPeople interface {    SetName(string)    GetName() string}type Student struct {    Name string    Age  int}type Teacher struct {    Name   string    Course string}func (s *Student) SetName(name string) {    s.Name = name}func (t *Teacher) SetName(name string) {    t.Name = name}func (s *Student) GetName() string {    return s.Name}func (t *Teacher) GetName() string {    return t.Name}func (s *Student) SetAge(age int) {    s.Age = age}func (s *Student) GetAge() int {    return s.Age}func (s *Student) String() string {    return "name is " + s.Name + ",age is " + strconv.Itoa(s.Age)}func (t *Teacher) SetCourse(course string) {    t.Course = course}func (t *Teacher) GetCourse() string {    return t.Course}

The red part of the Code defines an interface ipeople, which includes two methods. In the above code, we can draw a conclusion that both teacher and student have implemented the ipeople interface. We haven't seen it yet. Because both teacher and student implement the ipeople method. In go, you do not need to display whether a struct declares an interface. As long as it includes methods in the interface, the Go compiler considers this struct has implemented this interface. Even if the interface and struct are not in the same package, they are considered to have implemented this interface. See the main function:

package mainimport (    "fmt"    "lxy")type director struct {    lxy.Student    Name string}func (di *director) GetName() string {    fmt.Println("get director name")    return di.Name}func (di *director) SetName(name string) {    di.Name = name}func main() {    ss := new(lxy.Student)    ss.SetName("lxy")    ss.SetAge(20)    dd := new(director)    dd.Name = "director"    dd.Student = *ss    var ii lxy.IPeople    ii = dd    ii.SetName("test")    fmt.Println(ii.GetName())}

One struct can implement multiple interfaces, and one interface can also be implemented by multiple struct, which is the same as the well-known object-oriented language. An interface is a very important structure in the go language and has far-reaching significance in Java. For details, refer to go's learning materials.

 

That's all I think and know. Although it's not strictly object-oriented, it's at least what it looks like.