Hacker News Reader

Comment by vblanco | Hacker News Reader

I believe thinking of design patterns as something you "use" is one of the biggest mistakes being marketed to new programmers. A lot of them are niche use or only really exist to cover lack of features in languages, such as the Singleton pattern that has no real use in Cpp because you can just put a global pointer instead. It makes people think more about the code than about the problem they are trying to solve to begin with and often ends with a lot more code than is needed to solve the problem for no real good reason. Ive seen a lot of young programmers being mislead considerably by articles like this, including myself.

I see design patterns books and articles as more of a bestiary than a toolkit. Their purpose is not to be a repository of prebuilt solutions (because patterns dont solve anything by themselves). Their main purpose is to give names to a good amount of very common code patterns so you can communicate about it with other programmers.

View on HN

I can't agree more. Design pattern resources often omit the fact that "design patterns are missing features of programming languages". It's not a piece of common knowledge yet (at least outside HN), and I hope people could talk about this more.

Take the visitor pattern as an example: Say we have M types, and each type has N operations. OO languages like Java are good at extending M - you add another class. But it sucks at extending N because the obvious way is to add the operation as a method in every type. Visitor pattern helps you invert the problem, make it easier to extend N while suck at extending M. In fact, the visitor pattern feels more or less like it reinvented the plain, old "function" - just write a function and handle each type in it and you just achieved the same things.

I find it's always more readable when I just use a function. There's no exhaustive type checking so it makes sense to use the visitor pattern in Java, but I often people still use the pattern in, say, TypeScript without a second thought.

What if we want to extend M and N at the same time? There's a sophisticated design pattern called object algebra [0]. In this case, it's pretty clear that features like type class in Haskell and traits in Rust could solve the problem in straightforward ways without wrestling it with design patterns.

[0] https://en.wikipedia.org/wiki/Expression_problem#Problem_Sol...

> A lot of them are niche use or only really exist to cover lack of features in languages (...)

This take is a reflection of a failure to understand the concept of design patterns, their usefulness, and their role in software engineering.

Design patterns are not features missing from a toolkit or language. This is perhaps the biggest miscomprehension regarding design patterns. It's immaterial if a language supports or not a given programming construct in it's core language or standard library. The whole point of design patterns is that they represent higher-level programming constructs that pop up often in implementations and are frequently used to address common problems.

Think about it for a second: do futures or promises or callbacks or sharex pointers cease to be design patterns or lose any usefulness if these features are supported by the core language? Is the observer pattern not a design pattern anymore in C# or Java once it was implemented into them as first/second class citizens?

Or do we understand what these techniques involve just by mentioning these keywords?

Clearly the main problem plaguing design patterns are those who feel entitled to criticize things they don't know and clearly failed to grasp even the basics.

>Design patterns are not features missing from a toolkit or language. This is perhaps the biggest miscomprehension regarding design patterns.

It's relatively popular opinion that some design patterns are used because some languages lack some features that can achieve similar stuff in "better" way.

So what's design pattern in your opinion?

For me design pattern is just approach to some specific problem, very often connected with some $implementation_example in order to communicate more effectively.

Design pattern's purpose is to improve communication by naming solutions to "common" problems.

> It's relatively popular opinion that some design patterns are used because some languages lack some features that can achieve similar stuff in "better" way.

You're confusing a couple of unrelated issues there. Just because you need to implement a design pattern if you want to use it with a language/framework that doesn't provide it's own implementation, quite obviously that does not mean that design patterns only exist if you implement them yourself. That's a terribly silly misconception, and demonstrates a misunderstanding of the very basics of what a design pattern is.

Just to be absolutely clear, even Wikipedia defines design patterns as "a general, reusable solution to a commonly occurring problem within a given context in software design", and a "description or template for how to solve a problem that can be used in many different situations." What exactly is there in the definition that ties this to an implementation?

>What exactly is there in the definition that ties this to an implementation?

In definition nothing, but I believe there are very popular implementations (mostly one) of given design pattern that people are aware of and associate with given design pattern

and I guess it may kinda improve communication? idk.

https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeature...

Reply on news.ycombinator.com