One-man lasagna: Talking about the type in the Go language

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

The world is complex. A person, a thing can have a variety of characteristics, and many individuals and multiple things can show a consistent character, from a micro point of view, that is, specific to the individual, requires that the individual is multi-functional diversity, can complete the more functions have more characteristics of the better. For example, a person can have a wife, a mother, strict teacher and passers-by identity, such as a number can indicate age, height, score and so on. From a macro point of view, from the perspective of management complexity, but also require a lot of individuals with consistency in order to reduce management costs, such as all kinds of motor vehicles can be "driving", all kinds of food can be "edible", all kinds of writing tools can "write". In other words: Microscopic on the face of a person, macro thousand people side.

Programming is essentially to solve human problems to meet human needs, so the real world needs to be mapped into programming languages, that is, in the programming language to establish a corresponding model. In the go language, it provides a good mechanism to build this model, namely type and interface. Type is a good way to achieve a person's face, and interface well support the thousand people side. The interface of the non-invasive duck type of go language has been discussed in a number of articles, here I mainly talk about my understanding of type.

We know that the go language can use the Type keyword to convert one type to another to keep the nature of the data intact, for example:

Type Age int

Type Height int

Type Grade int

The type is not just a typedef that corresponds to C + +, it is not used to define a series of aliases. More crucially, it defines a series of unrelated behavioral traits: through these unrelated behavioral characteristics, essentially the same thing shows the characteristics of different things: integers or integers, but the age is not the height nor the score. We can define the following different behaviors (represented as methods or functions) for age, Height, grade, respectively:

Func (a Age) old () bool {

Older than 50 years old

Return a > 50

}

Func (L Length) needticket () bool {

Higher than 120cm need to buy tickets

return L > 120

}

Func (g Grade) Pass () bool {

60 points Pass

Return g >= 60

}

See a common example of game programming: A team can include a number of players, the team can be joined to quit a series of game logic related to the behavior, but also according to the level of players to sort. The analysis is as follows:

1. The team can essentially be a slice

2. Join, exit team and Team sort is game logic related

3. In order to sort, the team needs to implement sort. Interface interface, this is game logic unrelated, it exists just to meet the requirements of the game logic ordered by rank.

The implementation is as follows:

Import "Sort"

Type Player struct {

Name string

Level int

}

Team Realization

Type Team []*player

Func (t *team) Join (P *player) {

*t = Append (*t, p)

}

Func (t *team) Quit (P *player) {

For I, V: = Range *t {

if V.name = = P.name {

Copy ((*t) [I:], (*t) [i+1:])

*t = (*t) [: Len (*t)-1]

Return

}

}

}

Func (t *team) Sort () {

Sort. Sort (Sortteam (*t))

}

Sort implementation

Type Sortteam Team

Func (t Sortteam) Len () int {

Return Len (t)

}

Func (t Sortteam) Swap (i, J int) {

T[i], t[j] = T[j], t[i]

}

Func (t Sortteam) Less (i, J int) bool {

Return T[i].level < T[j].level

}

As you can see, a slice can be a player team or sort. The implementation of the interface interface. Their data is still the same slice, but the different types correspond to the behavior characteristics are quite different. This is a good reflection of the different interpretations of the same data in the real world, from the point of view of code maintenance to the separation of different classes of logic to make the code clearer and easier to read and maintain.

We continue to carry forward the spirit of one's thousand faces. Add some demand this time: The team also has to be sorted by name. The implementation is as follows:

Import "Sort"

Team Realization

Type Player struct {

Name string

Level int

}

Type Team []player

Func (t *team) Join (P Player) {

Implementation ibid.

}

Func (t *team) Quit (P Player) {

Implementation ibid.

}

Func (t *team) Sortbylevel () {

Sort by level

Sort. Sort (Sortlevel (*t))

}

Func (t *team) Sortbyname () {

Sort by name

Sort. Sort (Sortname (*t))

}

Level sort

Type Sortlevel Team

Func (t Sortlevel) Len () int {

Return Len (t)

}

Func (t sortlevel) Swap (i, J int) {

T[i], t[j] = T[j], t[i]

}

Func (t sortlevel) Less (i, J int) bool {

Return T[i].level < T[j].level

}

Sort by name

Type Sortname Team

Func (t Sortname) Len () int {

Return Len (t)

}

Func (t sortname) Swap (i, J int) {

T[i], t[j] = T[j], t[i]

}

Func (t sortname) Less (i, J int) bool {

Return T[i].name < T[j].name

}

To sum up, the go language reveals the essence of things through the type keyword, that is, the same thing can have a completely different set of behavioral characteristics so that they behave like different things, and the appearance of a series of behavioral characteristics of the independent, to write clear easy to read and easy to maintain code to provide a good help. The go language is a thorough understanding and mastery of the nature of things, which is not visible in C + + languages.