Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design patterns explained in Javascript

addyosmani.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Design patterns explained in Javascript

#11

Post by simplezeal »

legacye wrote: post #8

Hey guys - Addy (author of this mini-book here). Although the current edition is very much targeted at beginners, I'm working on a significantly more detailed version this summer which will also be released for free. 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…

I have to say, it's refreshing to see a Readability like template being used on a web page - no clutter of ads, sidebars, and other distractions.

Great job!

Re: Design patterns explained in Javascript

#12

Post by funksta »

jcampbell1 wrote: post #5

I really think the module pattern is an anti-pattern. The positive benefits of public/private methods, are more than offset by the performance penalty of having each instance of the an object have it's own methods, rather than sharing through the prototype.

My understanding (and the article reflects this) is that the "module pattern" generally refers to a function that is executed immediately after definition; ie: var module = (function() { ... })().

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.

Re: Design patterns explained in Javascript

#14

Post by masklinn »

gruseom wrote: post #6

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. 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'…

> Why not the "Function Pattern"?

Pretty sure it exists in assemblies.

Re: Design patterns explained in Javascript

#15

Post by gnaritas »

gruseom wrote: post #6

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. 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'…

> The point of patterns is to be a body of knowledge about how to make programs.

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.

Re: Design patterns explained in Javascript

#16

Post by T_S_ »

gruseom wrote: post #6

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. 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'…

I agree with your first part entirely. As for the comments about math I look at it this way. Math can usefully be described as a nothing but a bunch of design patterns, discovered and built in just the way you say. Look at the way addition and multiplication morph into a ring, once you learn a little math. Dynamic programming algorithms then work for any ring.

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.

Re: Design patterns explained in Javascript

#17

Post by gruseom »

T_S_ wrote: post #16
gruseom wrote: post #6

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. 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'…

I agree with your first part entirely. As for the comments about math I look at it this way. Math can usefully be described as a nothing but a bunch of design patterns, discovered and built in just the way you say. Look at the way addition and multiplication morph into a ring, once you learn a little math. Dynamic programming algorithms then work for any ring. The frustrating thing for programmers is that these patte…

The equivalent to a mathematical result in programming is not a design pattern, it's a program, algorithm, or data structure. Design patterns a la GoF (and the OP) are pseudo-formalisms. They're not well-defined enough to be comparable to math; not even close.

Re: Design patterns explained in Javascript

#18

Post by gruseom »

gnaritas wrote: post #15
gruseom wrote: post #6

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. 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'…

> The point of patterns is to be a body of knowledge about how to make programs. 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.

People always say this, but it's not true in practice. Any of these terms that are meaningful can easily be defined in a simple phrase. "Singleton" is an object with only one instance. "Observer" is code that gets called when something changes. (Actually, I think most people who haven't been influenced by GoF say "publish/subscribe" or "handle an event".) Moreover, this is a problem in search of a solution. I don't see programmers having difficulty communicating with each other because of a lack of standard technical vocabulary. 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.

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.

Re: Design patterns explained in Javascript

#19

Post by DougWebb »

T_S_ wrote: post #16
gruseom wrote: post #6

The idea that removing duplication is a design pattern (the "DRY Pattern") seems silly to me. Why not the "Function Pattern"? How about the "Line of Code Pattern"? That one sure pops up a lot. 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'…

I agree with your first part entirely. As for the comments about math I look at it this way. Math can usefully be described as a nothing but a bunch of design patterns, discovered and built in just the way you say. Look at the way addition and multiplication morph into a ring, once you learn a little math. Dynamic programming algorithms then work for any ring. The frustrating thing for programmers is that these patte…

Derivative of a data structure? I never heard of that before, though I'm familiar with derivatives in calculus. How do you calculate the derivative of a data structure? I'm guessing that you start by eliminating values that are constant with respect to some variable, but I'm not sure how you'd reduce the rest. How common is it to have values in a data structure that are non-linearly related to a variable?

Re: Design patterns explained in Javascript

#20

Post by cdsanchez »

Lately, instead of using the module pattern by invoking a function immediately and returning an object, I've taken to just using an anonymous function/constructor with the new operator -- properties defined under "this" will be public and any other variables will be private (obviously). I prefer it over the typical "module pattern" because I believe it looks just a tad bit cleaner compared to the explicit object definition.
Post reply on HN