4 ms·
Most of the design patterns exist because of limitations in programming languages, especially java/c++/c#. The strategy pattern disappears when you can store fu
by javcasas 5y ago
Most of the design patterns exist because of limitations in programming languages, especially java/c++/c#. The strategy pattern disappears when you can store functions in data structures. The abstract factory pattern disappears when you can pass functions as parameters. The builder pattern disappears when your progamming language has named parameters. The observer pattern is callbacks with additional steps. The mediator pattern disappears with support on variants of functional reactive programming. The iterator pattern disappears by using your favourite version of generators (or just go hardcore like Haskell and do foldable/traversable).
IMO GoF has been obsolete for the last 20 years (50 years if you consider that languages like ML, Lisp and friends already existed then).
- valenterry 5y agoStoring functions in datastructures with the purpose of applying a different logic depending on context/configuration but with the same goal _is_ the strategy pattern. It doesn't matter if you call it like that or not.
- javcasas 5y agoDo we have a special name for storing numbers in data structures? Do we have special names for storing strings in data structures? Do we have special names for storing lists in data structures? Do we have special names for storing source code as strings in data structures? Do we have special names for storing abstract syntax trees as data structures? Do we have special names for storing compiled code as data structures? Do we have special names for storing pairs of compiled code and related memory in data structures? Why do we need special names for storing functions in data structures? When I filter the list of numbers it's not a strategy pattern. Neither is when I filter the string list, or the AST list, or the compiled code+closure list. But, somehow, if it's a function list then it's a strategy pattern. Free your mind of unnecessary labels.
- valenterry 5y ago> Do we have a special name for storing numbers in data structures? Yes, we do. For instance, if I store numbers that describe a limit, I'll call it a limit. And it will give a hint how it is used. Do I call all numbers in a data structure limit? Of course not - the same is true for functions in datastructures. > Why do we need special names for storing functions in data structures? Well, it is helpful. There are many reasons to store functions in datastructures. For example to do mappings, to cache/memoize them or even to create interpretable datastructures, using free monads. But the strategy pattern describes the situation where there are multiple functions and they all serve the same purpose and have the same interface (and thus are interchangeble) and usually one is chosen and applied - but it is expected to be different ones, depending on the context. Do we really need a name for that or use it in code? I don't know. But that's not the my point - which is that the concept doesn't go away just because it is easier to use it. > When I filter the list of numbers it's not a strategy pattern. Neither is when I filter the string list, or the AST list, or the compiled code+closure list. Sure, if you don't change the way you filter then it's not a strategy pattern. > But, somehow, if it's a function list then it's a strategy pattern. Now you have lost me. Maybe we disagree because we are talking about a different thing?. A list of functions does not make a strategy pattern. And very often, strategies are implemented using inheritance (or composition) without any lists being involved. At least that's how I remeber the pattern when I saw it (in the pure functional programming world we indeed rarely call it like that) and how it's written in the GoF book.
- javcasas 5y agoYou have a bunch of functions in a list. You choose one of these functions via some criteria, and run it with some provided parameters. Why it is so different to having a bunch of numbers in a list and choosing one of these numbers via some criteria, then doing one of the allowed operations for that number? Bear in mind with the function I'm doing exactly the same: do one of the allowed operations for it (invoke the function).
- valenterry 5y agoDifferent functions can expect different arguments. For numbers, they are all the same. That's a difference! Well, you can argue that there are also different numbers and you can do devision only by some of them. But in fact, if you were to separate them and wrap them to do things differently, then this would get closer to the strategy pattern.
- dragonwriter 5y ago> Most of the design patterns exist because of limitations in programming languages, especially java/c++/c#. No. The implementation of some DPs is trivial in some languages, but the DPs don't disappear. The idea of DPs primarily as boilerplate implementation recipes rather than solution concepts with rationales comes from the limitations of Java, etc.,. not the DPs themselves.