Now I'm working on an old (+10 years) JS application. Similar patterns were implemented, but in this case it's not helpful at all. The code looks very corporate and Java EE style, with a ton of getters and setters (`getName() {}`, not `get name() {}`, factories, facades, adapters, etc, etc. It's usually completely unclear what the benefit of the pattern is, and code is more complicated, for instance because creating new instances of business objects is split into `Object.build` which calls `new Object`, with no guidelines at all what part of the initialization should be in `build` and what should be in the constructor.

The gist of my comment is that patterns can be useful, but usually they're overused and if you implement one without understanding why and without benefiting from faster understanding the code because the pattern is applied consistently over multiple instances, the result is worse than just implementing what you need in a readable way (YAGNI).

Almost 20 years ago.. damn.

https://creativecommons.org/2006/02/14/yahoodesignpatternlib...

https://web.archive.org/web/20060221111812/http://developer....

They had a great comparison of the different behaviors leaderboards could encourage in users.

Anyone has other sites like these to share?

- Domain-driven design, design patterns, and antipatterns

https://deviq.com/

- Refactoring and Design Patterns

https://refactoring.guru/

- Standard Patterns in Choice-Based Games

https://heterogenoustasks.wordpress.com/2015/01/26/standard-...

Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more complexity than they would have created had they not used design patterns.

There are situations where design patterns may be useful but they're much more rare than most people think. A lot of juniors seem to think that every problem requires them to apply a design pattern from their toolbox. They try to frame every problem within the constraints of design patterns that they know. This can create problems.

In fact, there are many coding patterns which are far simpler than 'design patterns' and much more useful, but nobody talks about them because they're too trivial to discuss. For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding. In general, knowing what data structure is most appropriate for various scenarios is a game changer... But still, don't abuse. Basic data structures like arrays are fine most of the time.

Anyway, it's good to absorb the wisdom behind some design patterns but you should not try to fit every problem to them and dont say stuff like "For this problem, I applied Design Pattern X" - If you do, senior engineers will know you're a junior. If you use a design pattern correctly, it will probably not look exactly like in the textbook. It's kind of hard to give it a name. It may be a mix of patterns. It's the principle that counts. Reality is too complex for rigid design patterns.

On the other hand, some design patterns are too common and obvious to deserve a name. For example, the factory pattern is super common... I use it all the time but it's so basic and obvious that I will sound like a total noob if I go around calling my function "socket factory pattern"... I will call it "Utility function to obtain a socket" or something. I will never refer to it as a factory pattern, it's a bit cringe.

https://en.wikipedia.org/wiki/Ralph_Johnson_(computer_scient...

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

https://norvig.com/design-patterns/design-patterns.pdf

https://medium.com/@letsCodeDevelopers/your-design-patterns-...

In A Pattern Language, each pattern is hyperlinked to other patterns in a kind of hierarchy, where larger patterns (like "house cluster") are broken down into smaller constituent parts ("main entrance") all the way to quite granular details ("low doorway").

This is because you can't just take a pattern on its own; it forms part of a larger whole.

Tech pattern books often focus on small recurring structures (e.g. "command pattern" from this site), but not how they help create some larger pattern, or in the other direction, what are the smaller patterns that help create them.

This sounds like a lot of hard work of course, which is why people don't do it.* I would love to see this accomplished though. If only I had an extra 36 hours in each day.

One thing that A Pattern Language is also great at is motivating each pattern with a specific problem or symptom. This site seems to do a decent job at that, though some problems seem... kind of weakly motivated. For example, the above mentioned "command pattern" is motivated by "what if we need to rename a method?" which... is pretty weak tbh.

*EDIT: also because fitting patterns into a whole, maybe unavoidably, will promote a perspective, or a way of building a whole system. A pattern book for web applications written from an HTMX point of view would be a very different book to one written from a React slant. Maybe one pattern language can accommodate both sets of technologies, or maybe not.

Module Pattern

Factory Pattern (factory functions)

Mediator / Middleware Pattern (as function pipelines)

Hooks Pattern (custom hooks, generalized)

Container / Presentational Pattern (implemented with function components + hooks)

Everything else is either neutral, UI-only, or fights POSD (Singleton, Mixin, etc.).

Patterns from that page you should treat skeptically for POSD

From Patterns.dev, for your POSD-style codebase I’d avoid or downplay:

Singleton Pattern → encourages global state and tight coupling. Patterns

Mixin Pattern → tends to increase interface surface and make dependencies opaque. Patterns

Observer Pattern → powerful, but event-based wiring can obscure data flow and increase “system complexity” (classic POSD warning). Patterns

its low quality, breadth but no depth

more important is to deeply understand the basics of working with immutable data. try writing applications with no for loops or forEach (and actually use the array methods as they are intended), no cloneDeep hacks and obviously no direct property mutation, always create a new object.

in real world you still use for loops plenty, but as a junior its good to see what its like to live without it for a while.

For example, prototype pattern is for languages that don't have a way to express interfaces/traits etc as something that can be attached to other language entities.

Anything that reliably shortens that loop is “good tech,” even if it’s ugly, uncool, or built on last decade’s stack.

It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example.

[1]: https://www.patterns.dev/vanilla/flyweight-pattern/

Edit: I forgot to give you kudos for all the effort it must have taken to create all this content, and I appreciate that you're making it available for free.

I was hoping for more high-level architecture based on war stories and experience. This is pretty basic stuff, which has it's value for people earlier in their journey, and does seem to have effort put in from a quick peruse

I tend to advocate for people to study design patterns. Not for the purpose that you will necessarily ever use most (or even any) of these exact patterns in your software, but just that you've strengthened your mental muscle for software design in general. I encounter lots of engineers who simply aren't able to think "outside the box" when building something new.

see the prototype, and observable pattern

they explain the basic concept, but in the only way you would never use it in real life

Singletons are just globals with extra steps, and have all the same problems globals have, just people (especially juniors) think they somehow are better.

In reality they’re worse because they conflate global access with enforced single instance. You almost never need to enforce a single instance. If you only want one of something, then create only one. Don’t enforce it unless it’s critical that there’s only one. Loggers are often given as an example of a “good” singleton and yet we often need multiple loggers for things like audit logs, or separating log types.

Instead of singletons, use dependency injection, use context objects, use service locators, or… just use globals and accept that they come with downsides instead of hiding behind the false sense of code quality that is a singleton.

I understand you can override modules in tests, and if you have a version of your app that runs in a different environment where you might replace a HTTP service with a different variant (like if an RPC service that normally performs HTTP requests, but in one case maybe you want to talk to specific process, worker or window using message passing).

I really really feel using constructor args is just a lot simpler in most cases. But I think there's a reason why people don't always do this:

1. Sometimes someone is using a framework that imposes a high level of inversion of control where you don't get to control how your dependencies are initialised.

2. (this was me when I was much younger) Someone dogmatically avoided using classes and thought they could get away with just data and functions, and then they realise there is some value in some shared instance of something and then they just undermine any functional purity. Don't get me wrong, functional purity is great, but there are parts of your apps that just aren't going to be functionally pure. And you don't need to go full OOP when you use classes.

----------------------------------------

Here are some examples of what I mean.

Here's one example, where I have an app defined in web components and I define the components for each part of the app before passing them into the skeleton. It's a more simple app and I avoid some shared state by different landmark components communicating by events.

https://github.com/AKST/analysis-notebook/blob/b3f082fc63c9b...

----------------------------------------

Here's another example, this app is built of multiple command line instructions that sometimes have their own version of services (singletons) with specific configuration, sometimes they are initialised in child processes.

https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69...

Because this app is doing a lot of scrapeing and I wanted to also child worker processes to do their own HTTP I was going to make a variant of my HTTP service which talked to a daemon process that tracked state for open connections to specific domains to avoid opening too many simultaneously and getting blocked by that host.

Updating the code that uses HTTP will be effortless, because it will continue to conform to the same API. I know this because I've already done this multiple times with HTTP scrapping in the app.

https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69...