Object-oriented Go language

This is a creation in Article, where the information may have evolved or changed. Learn go language almost nearly two months, feel this process is quite happy, turn over English materials, write small procedures, always feel that there are many things do not understand, step by step down, but found that these confusion seems to be indispensable. Thinking slowly, and finally finding a solution, may not be the best, but I will continue to revise as I know it.

Because Java stuff is ingrained in my knowledge system, although I now hate something in the Java system. For anyone who has ever worked in Java, to learn any new language, the first question is whether it is an object-oriented language. Just a few days into the go, my master asked me if go was an object-oriented language and I was evasive because I hadn't figured out whether it was. Object-oriented thinking is a great way to do it (and I think it is, for now). Go is not strictly an object-oriented language, but many of these approaches are drawing on some object-oriented ideas, although go is closer to C, but from the object-oriented, Java developers are not unfamiliar.

The three main features of object-oriented: encapsulation, inheritance, polymorphism.

Encapsulation: In my own understanding, encapsulation is the assembly of certain features together, other objects or classes can use this whole, but do not necessarily know its implementation details. This involves the question of whether it is visible. In Java, you have the privat,public,protected keyword to determine access permissions. In go, a prescribed method is used: Use case to determine that uppercase is visible outside the package, and lowercase structs or functions can only be used within the package. (The keyword of Go is so small, it can be said to be stingy, which is a reason for its brevity). Java, each class has its properties and methods, in go, there is no concept of class, and C, like the concept of a struct. Unlike the C language, you can define a method that is used only for this struct. It would be a lot clearer to see an example.


[Java] View plaincopy
Lxy Project Lxy.go
Package Lxy
Import "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 of function definition in go.

Func (PType) funcName (a type) (btype) {}

The red func is the keyword that defines the function, is immutable, the green part is optional, of course, if there is this part, it is not a function, but a method. This implementation is equivalent to the definition, and this method is used only for instances of this type. The purple section represents the return value of the function. This is a little strange. The familiar language, whether Java or C, puts the return value in front of the function name, and go puts it to the end. Also, functions in go can have 0-n return values, and you can specify the name of the return value.

The structure student encapsulates two methods, name and age, both of which are familiar including structures that can be used outside the package. It then defines several methods for the structure. Take a look at the call in the main function.

[Java] View plaincopy
Package Main
Import (
"FMT"
"Lxy"
)
Func Main () {
SS: = new (Lxy. Student)
Ss. SetName ("Lxy")
Ss. Setage (20)
Fmt. PRINTLN (ss. String ())
}

In go, to invoke the contents of another package, you need to import first. In go, everything is defined or used in a particular bundle. Use the package name. (method or global variable)

Inheritance: In go, does not explicitly explain the inheritance of the keyword, I use, I am not sure whether the true meaning of inheritance, let's call it simulation inheritance. Or look at an example.

[Java] View plaincopy
Package Main
Import (
"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 ())

}

Or just the code, I just add a struct in the package where the main function is located, it contains the student, and it is anonymously included, which is actually an inheritance. An instance of director can call all methods in student directly, such as the last statement. The handling of some conflicts includes: In this case, the director contains the GetName method and the name attribute, which is exactly the same as in student because it does not appear at the same level (what is the same lever?). In this example, the name and Lxy.student in the director are the same level), so the highest level is called. If the same level contains the same variable name or method name, it must be clearly specified. Like what

Type A struct{

a int

B string

}

Type B struct{

a int

C string

}

Type C struct{

A

B

}

At this point the call to Var cc c;cc.a is wrong, because the compiler does not know whether a or B is a property, this need to indicate that CC. A.A or CC.B.A?

Polymorphism: The concept of how to say, the interface of a variety of different ways of implementation. such as an interface method: called. If the cat implements this interface, the result will be "meow Meow"; The dog realizes this method, the result will be "bark" ... there is also an interface in go, but its implementation is more strange, gossip less, or take examples to say things:

[Java] View plaincopy
Lxy Project Lxy.go
Package Lxy
Import "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 consists of two methods. The above code, we can draw a conclusion that both teacher and student implement the interface ipeople. I don't see it yet. Because both teacher and student implement the two methods of interface ipeople. In go, it is not necessary to show whether a struct declares an interface, as long as it includes the method in the interface, the go compiler thinks the struct implements this interface. This interface is considered to be implemented even if the interface is not in the same package as the struct. Look at the main function:

[Java] View plaincopy
Package Main
Import (
"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 ())
}

A struct can implement multiple interfaces, and an interface can be implemented by more than one struct, which is the same as a well-known object-oriented language. Interface is a very important structure in the go language, and its significance is far more profound than in Java. Specifically, you can refer to the learning materials of go.



Almost, I think and know this, although not the strict object-oriented, but at least to achieve the spirit of the likeness.