Hacker News Reader

Comment by rr808 | Hacker News Reader

This is great. I always thought that GoF patterns is largely obsolete in 2022, it would be nice if the author agreed and has a list of GoF patterns that really dont make sense any more. Builder was one I thought should be included but OP seems to think its relevant (though different).

View on HN

Luciano Ramalho in his book "Fluent Python" mentioned that some (most?) of the GoF patterns are unneeded in a dynamic language like Python. I see [0] he is favorable to this site's author, so it is probably worth a look.

[0] https://twitter.com/ramalhoorg/status/960746929025142784?s=2...

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).

> 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.

Storing 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.

Do 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.

> 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.

You 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).

Different 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.

I found the quote. He says Peter Norvig wrote that "16 out of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern" and that Python shares some of the dynamic features of these languages such as first-class functions. I wonder if making GoF patterns simpler or even "invisible" in C++ using functions or callable-objects is implicitly not allowed because of the static typing of the language or if it just wasn't considered by the authors.

How did you happen to see that? That tweet is perfectly relevant, it's byond uncanny that you had it at the ready.

Coincidence. I was trying to find the reference to Ramalho's comment about GoF and found his comment in a random search.

Interesting, thanks for sharing. Is the opposite also true, that when a language is statically typed, design patterns are likely to be needed?

It depends on the language expresiveness, not on it being static/dynamic types. Dynamic languages tend to have less limitations to expresiveness (no typechecker in the middle) and then you have programming languages with static types and decent typecheckers that don't require design patterns because they are still very expressive.

In terms of obsolete GoF patterns, Flyweight is my nomination. It's not that it's useless, is just that in an era of 64 MB of RAM, it makes sense that people might need to know about it, but in an era of 64 GB of RAM the need is diminished to the point that only the people who have those problems need to worry about it.

And if you do have those problems, it isn't even necessarily what you would reach for first. Though it's at least on the list.

I think I've used flyweight in exactly one production system, and it was a trading system. Lots of transactions (easily tens or hundred of millions in a given day in a single process), lots of duplicated instrument data. Perfect use case for flyweight. But, yeah. It's a fairly rare use case. Good to know about, but not necessarily one you need to keep fresh in mind, ready for use.

Builder patterns work very well for generation of templates. I use them a fair amount when dealing with Amazon's CDK as it helps with fixing a lot of readability issues.

I see people claim that GoF patterns are obsolete, and that builder is one of the ones that are old hat, but for making configurations readable it can be the best solution.

What's the advantage of:

t = TemplateBuilder() .withFoo(foo) .withBar(bar) .excludeBaz() .build()

over:

t = Template(foo=foo, bar=bar, baz=none)

I think the builder pattern is more useful when you have sets of parameters that make sense together, but may be mutually exclusive with others. A more compelling example would be an IP address builder that supported different versions.

    ipv4 = IPAddress().v4("127.0.0.1").build()
    ipv6 = IPAddress().v6("::1").build()

Trying to perform something like this in Python with merely a constructor on an IPAddress type would lead to a not-so-obvious interface (such as use X set of named args to construct a v4 address or use Y set of named args to construct a v6 address, but using X & Y in the same constructor is a runtime error). This is my contrived example for where the builder pattern might make sense.

With your example, I don't see any compelling advantage to use the builder pattern. In fact, I'd argue as-is, the builder is unnecessary, is more verbose, adds additional complexity, and you should just use the constructor with named args instead.

The point behind the builder pattern is to perform nontrivial initialization that is hard/difficult/impossible to perform in a normal constructor a la C++, C#, Java, etc. If you're not performing nontrivial initialization, you've just introduced extra verbosity and complexity for no gain, so don't use the pattern then. This is, of course, just my opinion.

For example, if you see code that has a lot of overloaded constructors followed by an `init` function that must be called after construction, or code with a lot of overloaded `init`-type functions, only one of which shall be called; the builder pattern might make sense there.

    ipv4 = IPAddress.v4("127.0.0.1")
    ipv6 = IPAddress.v6("::1")

KISS.

You do not have to use the same class for V4 or V6.

I'm well aware. I chose the example to somewhat mirror what happens at the native posix level with addresses. It's the same structure, but can only be built in specific ways. Probably should have actual stated something to take effect.

I agree there's not much point using this kind of simple builder if you have named function parameters, but the GoF builder pattern has a couple of additional features which can still be useful. In the GoF examples the construction process is more complicated (maybe the order in which construction steps take place is significant, and maybe parts of the construction might be conditional), and the same construction algorithm can be used to produce different types of object. If I remember correctly, the main example in the GoF book is a builder for creating documents by adding a title, subtitle, paragraphs, etc, and the document being constructed might be a UI representation, an RTF file, HTML, etc.

> maybe the order in which construction steps take place is significant

That is just horrible...

> maybe parts of the construction might be conditional

No builder pattern needed for that, just use optional arguments and/or an option/nullable type.

I was talking about complex configurations with repetitive, not extremely basic named parameters. Think about a loadbalancer or an API Gateway that is going to loop through and generate several lambdas and their security groups.

I'll post an example in a bit of what I mean, but using a builder lets me use functions to break down the template into readable pieces.

And I'm not saying that it is impossible, I'm talking about readability.

Reply on news.ycombinator.com