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/5f5c65c3-4954-44db-aa37-5239b20bd99en%40googlegroups.com.
