3 ms·

Your critique of design patterns is driven by the exact same thing that causes people to copy inappropriate implementations from one language to another: you bo

by thom 7y ago

Your critique of design patterns is driven by the exact same thing that causes people to copy inappropriate implementations from one language to another: you both believe design patterns have something to do with the technical means instead of the design choice. The strategy pattern has nothing to do worth first class functions. It has to do with designs in which you delegate a decision to the consumer of an API. The moment I start seeing the majority of projects in dynamic languages do that instead of passing around a massive bag of options in every API call, I’ll believe that these languages have grown out of the need for specific named components of software design.

bcoates 7y ago
Dynamic languages don't generally favor using a function/class over a plain-old-struct, so there's no conceptual advantage to calling class GetNoCacheDefaultCookieJarStrategy { ... } fetch('https://google.com', new GetNoCacheDefaultCookieJarStrategy()) over const my_usual_fetch_opts = {...} fetch('https://google.com/', my_usual_fetch_opts) There are almost no uses of the strategy pattern that aren't equivalent to a trivial first-class function like a filter predicate or equivalent to a trivial plain-old-key-value-options-object, so the non-pattern version is stylistically preferred in the 99% case where it's not actually necessary.
- mr_crankypants 7y ago
  I submit that a filter predicate is an instance of the strategy pattern. The biggest difference between the two approaches is that one makes for a much less interesting UML diagram, so nobody ever really bothered to declare it a Design Pattern® and stick it in a long-winded book that we force college students to read. http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
- thom 7y ago
  Once again, this completely fails to capture what is useful about the design decision to allow user supplied strategies. Literally this week I wanted to change the retry logic in an HTTP library but I’m out of luck because it’s just a bag of options, none of which do what I want. Whether it’s a function or an object is irrelevant. We’re taking about design decisions, not code.

by thom 7y ago

bcoates 7y ago

Dynamic languages don't generally favor using a function/class over a plain-old-struct, so there's no conceptual advantage to calling class GetNoCacheDefaultCookieJarStrategy { ... } fetch('https://google.com', new GetNoCacheDefaultCookieJarStrategy()) over const my_usual_fetch_opts = {...} fetch('https://google.com/', my_usual_fetch_opts) There are almost no uses of the strategy pattern that aren't equivalent to a trivial first-class function like a filter predicate or equivalent to a trivial plain-old-key-value-options-object, so the non-pattern version is stylistically preferred in the 99% case where it's not actually necessary.

mr_crankypants 7y ago
I submit that a filter predicate is an instance of the strategy pattern. The biggest difference between the two approaches is that one makes for a much less interesting UML diagram, so nobody ever really bothered to declare it a Design Pattern® and stick it in a long-winded book that we force college students to read. http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
thom 7y ago
Once again, this completely fails to capture what is useful about the design decision to allow user supplied strategies. Literally this week I wanted to change the retry logic in an HTTP library but I’m out of luck because it’s just a bag of options, none of which do what I want. Whether it’s a function or an object is irrelevant. We’re taking about design decisions, not code.