Patterns.dev

I would put it slightly differently: Patterns (including anti-patterns) happen whether you call them such or not. Any developer will sooner or later come up with patterns like Adapter or Builder or Composite or Iterator. In that sense, patterns are not invented, but discovered. The benefit of design patterns is to be able to communicate these discovered patterns, and to define agreed names for them, so that you don't have to describe the pattern each time you talk to another developer, but can refer to it by a well-understood name. (Or when not yet well-understood, can refer to the corresponding pattern description.) It extends the language we use to talk about software design.

The point of design patterns is less about the individual patterns, than about having "design pattern" as a general concept of coding patterns relevant to software design, that you name and describe because they keep reoccurring.

A lot of patterns only make sense in languages like C# or Java, which are inflexible by design. You have two hierarchical trees (inheritance and namespaces) that you have to work around. With something simpler like C, Go, JavaScript, you don’t have those obstacles and a solution can be way simpler to implement.

This is a common thing I see when developers that come from an OOP enterprise environment familiar with Java, C#, etc. do JavaScript, they try to use all the same patterns, default to classes for everything. It just doesn't fit the language.

design patterns are a language, it's just that the programming language they're being implemented in doesn't support them natively.

e.g. observer pattern in java is what, [array of functions].forEach() in js? not worth calling that by name. another example, singletons - in Python, it's just a module (caveats apply obviously, but if we apply them, some also apply in java).

this is why designing a minimal language to make it 'simple' is misguided: you'll end up having to reinvent the design pattern language anyway. there are good reasons to design a simple language, but simple for the sake of simple is missing the point.

Not quite the same thing, but there's this incredible (open source) project called The Component Gallery that is basically just a repository of UI components across 93 (currently) different design systems. It's an incredible resource if you're building a component from scratch and either want some design inspo or technical advice. Many of the design systems have thorough guidelines for a11y/ARIA best practices that I've learned a ton from

https://component.gallery/

Amen! The terms "accordion" and "carousel" were really codified by the pattern library. Establishing a common vernacular definitely accelerates things.

Oh, the second link is amazing. I love the old web, and that brought a lot of nostalgia.

YUI was ahead of its time as well

we often forget how great Yahoo engineering was back in the day, sad it was destroyed by bad management and horrible business cases prioritization

for some reason I remember him being related to YUI, but I learned JS from Douglas Crockford, one of the best lectures from the old days of JS.

Here be dragons. People trying to pattern-match their problems to design patterns can waste a lot of time and effort over many years. Use responsibly.

I posted this elsewhere in this thread:

https://component.gallery/

Great meta resource for building UI components.

- Java Design Patterns

https://java-design-patterns.com/

The OG site for patterns is of course the Portland Pattern Repository. I believe Ward Cunningham invented wiki for this purpose initially!

https://c2.com/ppr/

I’ll make a plug for aep.dev, which is a collection of API design best practices and assorted tooling

Microsoft's cloud design patterns are quite well-written IMO, if you're into that kind of thing

https://learn.microsoft.com/en-us/azure/architecture/pattern...

I think it is difficult to oversell the bob nystrom game patterns book

https://gameprogrammingpatterns.com/contents.html

+1 for refactoring.guru, find it really useful whenever i want to refactor some pre-existing code. Only wish they had a physical book!

I see it as a common vocabulary to talk about tools. It's simpler to say "I made a singleton" than to describe it.

Just like we have words for a nail, a screw, a hammer. If you had to say "I used a tool that I find works well with nails", that would be annoying and ambiguous.

Now of course, if you quickly screwed something with your swiss-army knife and a junior came and told you that this is wrong, because you should always use a proper screwdriver, and therefore you should rent a car and drive 30min to go buy it right now, you would kindly tell them to fuck off. Doesn't mean that there is no value in the concept of a screwdriver itself.

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

This is a "hash join" in relational databases. You can see it in the query planner output of at least postgres.

I wouldn't say it's cringe. A factory is a factory. Calling it that in the code may not be the best idea, but having the shared vocabulary is nice. Basically, patterns work well when they're descriptive rather than prescriptive.

There are two cases that are unique though: state machines and visitors are so much things on their own, that you'll use those names almost every time you run into the pattern.

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

Isn't this called 'dynamic programming'? It's actually a habit people should pick up when grinding leetcode.

For your example, if both lists are small enough, the constant factor on the cost of creating the hashmap eliminates any advantage you could have. Anyway, it's not like most places were I've seen a nested loop used for search the developer had cared. Today I am in a bad mood.

I have to touch some of the most unnerving modules in a legacy project and everything is a trap. Lot's of similar repeated code with ugly patterns and some big brain trying to hide the ugliness with layers and layers of indirections and inheritance, and calling it clean because there is a factory class. The biggest joke? each implementation have a different interface for key methods, so later you to check what instance got created.

I want to keel myself. Anyone could assist me in a seppuku?

the actual software design patterns, unbiased by language/particular-usage, are subtle. i would go as far as say that there are also "design-patterns"-usage patterns.. and those might be even more subtle. e.g. what is/constitutes "interpreter", and when to use one, and when/if one is being used behind-the-scenes. Sometimes it is a single piece that is easily pinpointable. Sometimes a whole (sub)system behaves like one (e.g. event-sourcing stuff) but it's not easily cut into this is this, that is that.

But anyway, this site seems javascript/frontend wanna-bees oriented.. please don't take those tutorials as mantras-to-follow-at-any-rate. See if you can take the knowledge and move on.

A very good book, besides the GoF one, is the "Organisational patterns book by James Coplien, Neil Harrison" [1]. It contains some of the GoF *plus* all the non-technical ones, and they are bundled together - as software making is not just the coding.. i have the list of those patterns essences (patlets) extracted, here the link - https://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patle...

edit: it's from ~2003-5 and images are missing. May need to scan them from the book. Closest i found is [2], at least to get some idea

[1] http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/

[2] https://www.scrumbook.org/book-outline/history-of-the-patter...

What about the social / communication aspect ? Having a common vocabulary of pattern may help reduce cognitive load when reading others code. Just a soft opinion because I assume it's the reason frameworks and conventions help teamwork. Less per-context custom solutions.

> Very useful pattern but I don't believe it has a name.

This is an instance of “use the right data structure for the job”. To me it has little to do with architectural design (where design patterns live), but it has to do with algorithmic design.

My experience is that they are best discovered independently as a way to abstract code, and let them come naturally to solve a problem. So for most things in Dev, if you do something prematurely you might end up with a good solution for a non existing problem.

Like many things they shine when use appropriately.

Here's an excerpt from APL showing what I mean about the connections to the other patterns. This isn't the whole pattern, there's a lot between the problem statement and summary. Annotations in brackets are mine.

---

Short Passages (132)

[Context, or pre-links]

The Flow Through Rooms (131) describes the generosity of light and movement in the way that rooms connect to one another and recommends against the use of passages. But when there has to be a passage in an office or a house and when it is too small to be a Building Thoroughfare (101), it must be treated very specially, as if it were itself a room. This pattern gives the character of these smallest passages, and so completes the circulation system laid down by Circulation Realms (98) and Building Thoroughfare (101) and The Flow Through Rooms (131).

[Problem statement]

Long, sterile corridors set the scene for everything bad about modern architecture. In fact, the ugly long repetitive corridors of the machine age have so far infected the word "corridor" that it is hard to imagine that a corridor could ever be a place of beauty, a moment in your passage from room to room, which means as much as all the moments you spend in the rooms themselves.

[Pattern contents here]

[Pattern summary]

Keep passages short. Make them as much like rooms as possible, with carpets or wood on the floor, furniture, bookshelves, beautiful windows. Make them generous in shape, and always give them plenty of light; the best corridors and passages of all are those which have windows along an entire wall.

[Elaboration, or post-links]

Put in windows, bookshelves, and furnishings to make them as much like actual rooms as possible, with alcoves, seats along the edge - Light on Two Sides of Every Room (159), Alcoves (179), Window Place (180), Thick Walls (197), Closets Between Rooms (198); open up the long side into the garden or out onto balconies - Outdoor Room (163), Gallery Surround (166), Low Sill (222). Make interior windows between the passage and the rooms which open off it - Interior Windows(194), Solid Doors With Glass(237). And finally, for the shape of the passages, in detail, start with The Shape of Indoor Space (191)

What does POSD stand for?

The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript.

In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once.

Let's not turn the singleton pattern into forbidden knowledge.

[1]: https://www.patterns.dev/vanilla/singleton-pattern/#tradeoff...

Why pose DI as replacing singletons when they're used together all the time? Injecting dependencies to create a singleton repository or service class, which is shared across requests.

Singletons are globals and should be treated the same as every other global (that is, used sparingly and with care).

Worse is that singletons enfurece a single instance which is almost always unnecessary. It’s trivial to only create as many instances as you need.

Yes, I have to admit my interest was piqued by the banner, and I then scrolled down, saw the first example was singletons, and closed the tab.

Off the top of my head, rails (currentattributes), Laravel (facades) especially, and most iOS apps use singletons quite well. It’s all in moderation and depends highly on how it’s used, much like every other design pattern.

I think people just don’t like Singletons because they’ve been especially misused in the past but I guarantee the same argument stands for any other design pattern.

although this article does get me thinking of documenting the “patterns” i use, and why.