Design patterns explained in Javascript

SingletonTest.getInstance() assumes SingletonTest is globally visible (or at least in the scope you care about), so therefore to call some method you do SingletonTest.getInstance().someMethod(). This is polluting the global namespace. Instead you can use the module pattern and use a global top-level namespace object: App.moduleObject.someMethod(). This is cleaner, requires less code and won't pollute the global namespace. just say no to classical patterns in js

The trouble with design patterns is that they're at the wrong level of abstraction. They're fine-grained enough to be described in a few pages and meaty enough to make the reader feel they've really learned something. But they're too coarse-grained and rigid to work the promised way, which is as primitives for software problem-solving. Treating these technical blobs as primitives leads to no end of trouble. People naively inline them into their programs because they have been told this is how it is done -- the OP says they are "proven solutions" (to what?) that can be "easily re-used" (how? ever notice they never show you that?) -- and the effect is like releasing a foreign species into an ecosystem. You end up doing the worst thing you can do to code, which is take it further away from the problem it is trying to solve. The gap between abstraction that precisely fits the problem and abstraction that sort of fits the problem is massive: it is the whole game. Out of that gap, complexity grows exponentially.

Patternistas say, "But they're not supposed to be inlined naively. They're supposed to be adapted to the problem." But if you're already good at that, you don't need patterns. The point of patterns is to be a body of knowledge about how to make programs. If that's true, patterns should make naive programmers better. If their effect is to make naive programs worse, then they aren't really a body of knowledge at all.

Mathematics, like software, is filled with recurring patterns and tricks that pop up in diverse contexts. Why doesn't math have "design patterns"? Because math culture understands that the only way to get good at math is to read theorems and solve problems. If a trick you've seen before is useful, use it; if not, drop it. The focus is always on the problem. Over time, you notice patterns, sure. But "patterns" are not the basis of teaching math, classical results are. I believe that software is like math this way. But the mathematicians have a luxury we do not: they don't need to grow their community by orders of magnitude in order to satisfy industrial demand. If you like math and have aptitude for it, the door is open; if not, see ya. Software, on the other hand, requires a massive work force, which raises the question of how to train it. Design patterns are a failed attempt to address that problem, which may not be solvable. Unfortunately, they confuse and delay the development of some good programmers in the process.

To those who have mentioned some patterns are indeed better suited to 'classical' programming languages, I completely agree with you - the reason I've included a mention of them is so that developers who may not have read the book by GoF get a little historic exposure to why those patterns were defined and where they fit in.

There will be a lot more JavaScript-centric content in the next version with a little less focus on the traditional patterns.

As I see it, the main benefit of design patterns is that they give developers a common vocabulary for different types of object composition. This can save time when reading code if an object's name or comments reference the design pattern(s) used.