Hi All, in case someone is in interest of the subject I repost here what I have found in the internet some time ago. >>I apologize for being so intrusive. >>I will only provide links to educational resources, in case it would be interesting for anyone. >>GitHub - AlexanderGrom/go-patterns: Design patterns in Golang <https://github.com/AlexanderGrom/go-patterns> (in russian) >>Go Patterns · GitBook (tmrts.com) <http://tmrts.com/go-patterns/> >>GitHub - PacktPublishing/Go-Design-Patterns-for-Real-World-Projects: Go: Design Patterns for Real-World Projects, by Packt <https://github.com/PacktPublishing/Go-Design-Patterns-for-Real-World-Projects> >>Patrones de Diseño en Go (designpatternsingo.com) <http://www.designpatternsingo.com/> (in spanish)
But I would like to stress one thing. Due to absence in GO dynamic dispatching some of the patterns must be implemented, say as they must be in GO. :-) Thank you. понедельник, 1 апреля 2024 г. в 19:20:17 UTC+3, Ionenet SA: > I think many of you are confusing things. Many GOF patterns are still the > basis of today's programming. For example, the way that React or Vue manage > states, whatever you are using Pinia or Redux, they are no more than the > Observer pattern combined with the Proxy. And they are now native in > vanilla JavaScript. The observer is at the basis of event driven > programming. The Model-View-Controller itself is another combination of GOF > patterns. All the lambda functionality is an application of the Strategy > pattern and there are plenty of examples in modern programming that they > are nothing more than patterns. All the Martin Fowler's patterns are > nothing more than a combination of GOF patterns. The entire functionality > of history and ctrl+z/ctrl+y functionality is nothing more than a > combination of State/Memento. So I disagree completely about the idea that > patterns are to overcome Java limitations. The fact that some modern > languages natively implement a pattern in the form of a construct (for > example lambda functions to implement strategy) does not make the patterns > useless, but rather illustrate their usefulness. > > So, while some patterns are useless today, while some others are natively > implemented in many languages, including PHP, knowing them is still very > useful to understand how things work and where they come from. Otherwise > you will get submerged by a myriad of fancy names (in Laravel's style) and > you have to figure out and finally learn the same wheel with a different > name and the incorrect way. > > Think about it. > > On Wednesday, March 19, 2014 at 2:15:02 PM UTC-4 DV wrote: > >> My interpretation of what was said above was more along the lines that >> some of the patterns in the gang-of-four book exist not because they're >> good patterns in themselves, but that they exist because the languages they >> were designed for have various shortcomings and a certain type rigidness >> that doesn't exist in Go, so why bother using them? >> >> Some sort of AbstractFactoryOfFactoryFactories is always present in every >> non-trivial Java project I've ever seen, but almost nobody bothers with it >> in Go. If that pattern is difficult to implement in Go (it might be, I >> never tried) what does that tell us about Go? That Go is bad at >> implementing bad/unnecessary patterns? I can live with that, definitely. >> The more important question though is - why even bother with that "pattern" >> in Go? >> >> I think we need to look at the problems, and try to solve them in Go, not >> look at a problem, take an existing Java solution and then translate it to >> Go. >> >> 19/20 "patterns" I've seen about Go are about concurrency and how to use >> goroutines, channels, select, etc. to solve common concurrency problems, *in >> Go*. They're not abstract UML diagrams about problems that may not even >> exist in Go or other languages, which is what the GoF book is to me - >> answers to questions that nobody is asking. >> >> >> On Wednesday, March 19, 2014 11:16:43 AM UTC-6, Robert Johnstone wrote: >>> >>> I think that you misunderstood my point. My point was that since >>> languages differ in their level of abstraction, the level of abstraction >>> for the design patters will also vary. Judging the quality of a language >>> based on the level of abstraction of its design patterns is just as odd an >>> idea as judging the language based its level of abstraction directly. >>> >>> Beyond the above, it's not clear why patterns should be said to raise >>> the level of abstraction in one case and lower it in another. >>> >>> >>> On Wednesday, 19 March 2014 11:25:56 UTC-4, Péter Szilágyi wrote: >>>> >>>> Hi, >>>> >>>> Take care not to mix up design patterns and levels of abstractions. >>>> Although we could argue that building function calls on top of assembly is >>>> a "pattern", it is one that raises the level of abstraction. The design >>>> patterns of GoF on the other hand do not provide higher abstractions, only >>>> control flow limits within the existing abstraction layer. >>>> >>>> Cheers, >>>> Peter >>>> >>>> >>>> On Wed, Mar 19, 2014 at 5:18 PM, Robert Johnstone <r.w.jo...@gmail.com> >>>> wrote: >>>> >>>>> Different languages target different levels of abstraction. Following >>>>> the idea below, the existence are design patterns in assembly to handle >>>>> function calls means that no one should need to program in assembly any >>>>> more. >>>>> >>>>> >>>>> >>>>> On Wednesday, 19 March 2014 08:12:07 UTC-4, Benjamin Measures wrote: >>>>>> >>>>>> On Wednesday, 19 March 2014 01:33:16 UTC, Robert Johnstone wrote: >>>>>> >>>>>>> On Monday, 17 March 2014 07:59:28 UTC-4, Rob 'Commander' Pike wrote: >>>>>>>> >>>>>>>> The Visitor Pattern, like many patterns in the "Gang of Four"[...]: >>>>>>> >>>>>>> such are the lengths one must stretch to achieve simple goals. >>>>>>>> >>>>>>> >>>>>> >>>>>> This comment is a little ironic, given that there was a blog post on >>>>>>> golang.org recently describing design patterns for concurrency in >>>>>>> Go. Whatever the deficiencies of C++, I'm not certain that the >>>>>>> existence >>>>>>> of design patterns prove anything. >>>>>> >>>>>> >>>>>> It is not the mere existence of these patterns but "the lengths one >>>>>> must stretch to achieve simple goals." It is the gymnastics one must >>>>>> perform [to work against language restrictions] to solve a simple >>>>>> problem. Popular patterns tend to typify the worst of these: for a >>>>>> pattern >>>>>> to become popular the problem must be trivial. The singleton pattern is >>>>>> a >>>>>> prime example, since the problem can be sumarised in 5 words: restrict >>>>>> instantiations to one object. >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d3bc2a2a-4739-49e6-bc03-b544b17ccdecn%40googlegroups.com.
