Design patterns explained in Javascript
addyosmani.com
addyosmani.com
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.
Great job!
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.
The frustrating thing for programmers is that these patterns don't often seem to be directly useful in computer science. Oops, I mean programming.
I think that is changing thanks to functional languages. One of the most mind blowing CS lessons I learned in the past few years was how to calculate the derivative of a data structure and what to use it for, using plain old calculus rules. Now that might seems useless or crazy if you haven't studied algebraic data types. But these are readily seen to be useful once you learn a little math (and Haskell). In a few years I believe that FP will be credited for the wholesale import of mathematical design patterns into everyday programming. The Haskell and related communities are still small enough that they have only scratched the surface.
Well, kinda-sorta. It depends on how you define a design pattern, and how you generalize that definition to mathematics. The way that I define design patterns, I would disagree.
I define design patterns as "an abstracted, re-usable piece of functionality that cannot be made into a library." I think that the non-libraribility is the defining feature of design patterns: it's why you have to learn to implement them, instead of just linking to them like most other forms of re-usable functionality[1]. As soon as you can figure out how to factor that functionality into a library (or template or inheritable class or interface or whatever), it's no longer a design pattern.
When I look at mathematics, I would consider that to be mostly a collection of libraries rather than design patterns. Theorems, obviously, are more like libraries because you can simply plug in the antecedents and get out the sequents without looking at the proof. There are also things like design patterns, techniques that you can apply in related domains. However, mathematicians have a pathological urge to turn these techniques into theorems by proving properties about what they will do and when they can be applied. The result is that math tends to have many libraries but few surviving design patterns at any point.
[1] Note that this definition is language-dependent. It also dovetails somewhat with the "design patterns are evidence of an underpowered language" line of thought, but is distinct because it deals with extensible functionality rather than built-in functionality.
But it seems to me that FP forces you to look at programming in terms of what you are doing to transform data. In that case I can't see why having enough libraries won't do the job.
See e.g. http://www.haskell.org/haskellwiki/Zipper
And, yes, automatic derivation of zippers is mind blowing, when you encouter it for the first time.
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.
No, the point of patterns is to standardize the language about what everyone already does so programmers can actually discuss what they do with each other in a meaningful way.
No, design patterns come with considerably greater baggage than that. They invariably come with template code and a lot of language about when and how to apply the pattern. They're not trying to be a glossary, but a cookbook. Basically, the failed OO mantra of "reuse" took refuge at the meta level where it's impossible to disprove.
It is true in practice, try talking to programmers who don't know about design patterns and you'll find communication about architecture difficult. Maybe you haven't met enough of these programmers, but there's a shit ton of them in the corporate world.
> If there isn't a term for something, you just make one and say what you mean by it. That's what we've always done and it's what programmers not under the influence of "design patterns" always still do.
Yes, and it doesn't work well when you don't have a common vocabulary; you spend all your time trying to grok their little custom names for everything.
Everything else you said is what happens when people mis-apply patterns and think they're code templates, they're not and were never intended to be.
I think much of this is because "Design Patterns" itself is too raw and too language-centric and too sterile. It's too much of a catalog and not enough advice on why you'd want to use a design pattern and where, and the tradeoffs of doing so.
In contrast, "Refactoring" builds up a robust, pragmatic, and practical set of models and terminology for software design and construction, and for making changes to such. It also provides a lot of good rules of thumb and general guidelines for when to know whether a particular refactoring is worthwhile or not. It's very much the level of glue that is missing between the airy almost architecture astronaut level of patterns and the muddy, ugly trenches where real code gets written and re-written.
On the whole, someone who's read both "Refactoring" and the GoF patterns book is much more likely to have stepped up their level of coding and increased the sophistication of their models and vocabulary for talking about, reasoning about, designing, and constructing code, whereas someone who has only read about patterns is as likely to be a danger to the codebase as a help.
Pretty sure it exists in assemblies.
See http://www.c2.com/cgi/wiki?AreDesignPatternsMissingLanguageF...
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
I'm guessing you're referring to Crockford's pattern (IIRC he calls it a "functional constructor" in JS:tGP), which is generally the same, but the function is instead executed when an object is instantiated with it.
It's a small distinction, but your drawbacks don't apply to the module pattern as I understand it, since the function is only executed once.