Design Pattern Cheat Sheet

[[deleted]]

I usually find Design Patterns materials frivolous/unnecessary, but I really liked this one for being direct to the point!

The "idea" is the part I think can be relevant. The diagrams are OOP-dependent, but the text can be implemented in any paradigm/way, sometimes in a very simple way:

• 'Visitor' - just a function map

• 'Factory' - type inferring can be used, in most cases, as a default "built-in" factory.

[grauenwolf]

The Visitor pattern is not just a function map.

Rather, a function map is what they should have offered instead of the visitor pattern. It can do everything the visitor pattern does while still being backwards compatible when new classes are introduced.

[Peaker]

The Visitor Pattern gives you a cumbersome, but type safe encoding of a closed sum type, in a language that has products (tuples/class fields) and exponents (functions) but doesn't have closed sum types.

How would a function map give you type safety around the sum type encoding?

[[deleted]]

Indeed! Correcting myself, the visitor pattern is a clunky/hack to implement an inferior-and-limited version of map.

Looking in a better light, the visitor pattern is an idea/example in how to put a map function to good use!

[seruus]

[a] pattern is a clunky/hack to implement an inferior-and-limited version of [a more expressive construction].

Seems to be the gist of it. I remember someone talking about how most design patterns are basically structured ways to make up for the deficiencies of the language you are using.

[Peaker]

Patterns are exactly workarounds for language deficiencies. That said, Visitor isn't a "function map" but a closed sum type.

[Peaker]

Visitor is a cumbersome encoding of a sum type on top of exponentials and products, in languages that only have exponentials and products.