Shulou(Shulou.com)06/02 Report--

This article focuses on "how to be a GE language programmer". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to be a GE language programmer".

History 1: do you believe that you can use Go for object-oriented programming?

After a trip to Go applications, you may start to think, "how can I make this language more like an object-oriented programming language?" Because you are used to this kind of programming, you want to make robust code, you want polymorphism.

Then you say, "there must be a way to do it!" Then you find structural embedding, which cleverly delegates methods from closed objects to embedded objects without repeating code. This is amazing!

Of course, you will soon find that this does not really solve the problem. Because structure embedding only allows delegated method calls, it looks like you are doing polymorphic method scheduling, but the relationship is not IS-A, but HAS-A. The receiver of method calls is not a closed object, but always an embedded object of delegated method calls.

So, do you understand not to try to do object-oriented programming in Go?

History 2: do you believe goroutines will solve all the problems?

Before using it, you were bewitched by "you can easily run concurrent code through goroutines". All you have to do is use the Go keyword and run all function or method calls at the same time. At this point, you will naturally think of improving the efficiency of the code to a limited extent by letting the code run concurrently. The goroutines is created automatically through function calls, even without the caller realizing it. Yes, it does make all the code run at the same time, but it makes the code more complex.

Go allows users to create millions of goroutine without sacrificing too much efficiency, so should you really use goroutine? You should know that parallel code is more difficult to maintain and debug than code that flows in a single thread. When accessing multiple goroutine at a time, do you want to consider whether the shared objects are synchronized correctly? Is the order of execution absolutely correct? Did goroutine actually quit when it was no longer needed?

Therefore, goroutine is not * *, be sure to use it when necessary, and try not to use goroutine after the user.

And because you hide this fact by making your function calls automatically create goroutines, callers don't even need to be aware of this.

History 3: do you think interfaces will take the place of object-oriented programming to solve all problems?

After you finally realize that objects cannot use polymorphism, it suddenly occurs to you that you can take advantage of the functionality provided by the interface, which supports API, so you can use it to write more robust code.

So now when you write the library, you define all the interfaces, export only the interfaces and have a private structure that can be encapsulated into perrrrfect. It also gives you more flexibility to switch between the underlying implementations, because now you have successfully separated API from its implementation.

Although the interface gives you a lot of power, it is not a solution. In object-oriented programming, it still doesn't provide true polymorphism, and you're limited to the fact that interfaces can only define API, and you can't associate all the data with it.

Of course, it makes sense to export only interfaces in certain scenarios, and interfaces are a good method when the amount of code is relatively small. But if the amount of code is large, you have to write a lot of extra code.

If you want to make limited use of the interface, you can use it in some types of interchange.

Experience 4: do you believe channel can solve all the problems?

After you have gone through twists and turns and tried many ways to save the country, you may have a flash of inspiration one day, "wait a minute, and channel."

Channel implicitly handles concurrent access, and you believe that channel can cleverly handle synchronization, return values, and use various channel select statements for traffic control.

Yes, channel is useful, and in line with your original intention, it provides a primitive for passing values between goroutine. However, slowly you will find that there will be a lot of problems using channel's Go language, such as timeouts, blocking I / O, synchronization problems, and so on.

So, you have to understand that channel is a very concise structure, but misusing it can lead to more complex and difficult code to debug.

"History 5": "well, the Go language is so general, it's not as powerful as everyone says it is."

"Why? why on earth is it? it's so painful to write Go code that it never allows me to write it my own way." After trying various methods, you find that none of them can solve the problem of polymorphism and concurrency, and you even begin to doubt the reasonableness of the existence of Go. You feel that you have been deprived of all the good structures and tools provided by other languages.

You think it is absolutely necessary to use more powerful tools to express abstract ideas, but Go just doesn't cut it.

However, you forget that all languages are restrictive, and you can't just want the language to run the way you want it to, regardless of why the author designed the language in the first place.

History 6: you begin to realize that you are imagining the first five stages.

At this stage, you basically give up all kinds of clever tricks and decide to write Go code according to the way most standard libraries are written.

At this time, you still have such an idea: I don't want to accept the method of Go language. But at this point, everything starts to get interesting.

While I had to give up object-oriented programming to embrace the Go language, I also had to accept the fact that it was too difficult to write concurrent code. I have always believed that the focus of a language is to get programmers to write more concise code, so a language should be enough to write and execute complex code, but to make the final code simpler by removing some key tools.

"History 7": feathering into Immortals

At this stage, you have fully accepted Go, and you can write everything in Go, including Perl / Ruby / Python content. You begin to realize that there are no more mistakes bothering you; you have to use goroutines and channel

Because you are Gopher;, you will be honored that the Go language allows you to write code in this way.

Congratulations, you are now a GE language programmer!

At this point, I believe you have a deeper understanding of "how to be a GE language programmer". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.