Design Patterns Are Temporary, Language Features Are Forever
1–10 of 67 posts
Re: Design Patterns Are Temporary, Language Features Are Forever
#2[dead]
Re: Design Patterns Are Temporary, Language Features Are Forever
#3I haven't looked at patterns since the GOF days, so maybe they grew closer to Alexander's as they matured, but the original ones were very much ways to speak about things so they'd be politically palatable in an everything-is-an-object world.
You just wanted some data? "Flyweight". You just wanted some functions? "Strategy". etc.
Re: Design Patterns Are Temporary, Language Features Are Forever
#4I haven't looked at patterns since the GOF days, so maybe they grew closer to Alexander's as they matured, but the original ones were very much ways to speak about things so they'd be politically palatable in an everything-is-an-object world. You just wanted some data? "Flyweight". You just wanted some functions? "Strategy". etc.
An insightful comment, but to be fair many important GoF design patterns like Composite and Decorator are genuinely object oriented, leveraging polymorphism and interfaces to produce order and elegance.
Re: Design Patterns Are Temporary, Language Features Are Forever
#5I haven't looked at patterns since the GOF days, so maybe they grew closer to Alexander's as they matured, but the original ones were very much ways to speak about things so they'd be politically palatable in an everything-is-an-object world. You just wanted some data? "Flyweight". You just wanted some functions? "Strategy". etc.
An insightful comment, but to be fair many important GoF design patterns like Composite and Decorator are genuinely object oriented, leveraging polymorphism and interfaces to produce order and elegance.
Order and elegance?
Some people say that GoF patterns are just a way to cover up for OOP-centric language shortcomings.
Re: Design Patterns Are Temporary, Language Features Are Forever
#6I have a bug/hate relationship with the visitor pattern: how do I implement it without causing a stack overflow in languages without tail recursion optimization?
It always ends up in a loop with a lot of ifs inside.
Re: Design Patterns Are Temporary, Language Features Are Forever
#7I have a bug/hate relationship with the visitor pattern: how do I implement it without causing a stack overflow in languages without tail recursion optimization? It always ends up in a loop with a lot of ifs inside.
with a 'for' loop
Re: Design Patterns Are Temporary, Language Features Are Forever
#8I haven't looked at patterns since the GOF days, so maybe they grew closer to Alexander's as they matured, but the original ones were very much ways to speak about things so they'd be politically palatable in an everything-is-an-object world. You just wanted some data? "Flyweight". You just wanted some functions? "Strategy". etc.
It amused me that Alexander's _A Pattern Language_ was 90% about habitability and 10% about building whereas I had the feeling GoF was the opposite.
That is, I believe Alexander's version of design patterns would have things like "Intention Revealing Names" and code reviews focusing on "Clarity, Consistency, and Correctness (in that order)"--things that help subsequent developors live in and enjoy the code and design.
Re: Design Patterns Are Temporary, Language Features Are Forever
#9You don’t come across visitors every day, and they aren’t something to reach for instead of a simple switch, but if you are writing a Webpack or ESLint plugin or something like that, you might encounter them for traversing an AST. It’s not just an OO thing, either.
I learned the visitor pattern in pretty ideal circumstances: from a classmate, back in college, when we were writing a compiler together for a class project, and it was just what we needed.
The right conditions for a visitor are when you have a data structure with many different “node” types, and the traversal logic is not simple. In addition, you will be doing many different traversals. You might also be doing transformations on the structure. You might have a library running the traversals/transformations provided by the code that uses the library. There could be correctness or memory management considerations involved that you don’t want the client to have to worry about. You might want to “pipeline” multiple transformations, doing several manipulations in one traversal, in an efficient way. Common traversals might care about only certain types of nodes, like a particular lint rule might just be looking at string literals or references to global variables, but it needs to walk the entire syntax tree of a file of source code.
Re: Design Patterns Are Temporary, Language Features Are Forever
#10I have a bug/hate relationship with the visitor pattern: how do I implement it without causing a stack overflow in languages without tail recursion optimization? It always ends up in a loop with a lot of ifs inside.
Trampolines can help with that.