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

31–35 of 35 posts

Re: Design patterns explained in Javascript

#31

Post by omaranto »

lmkg wrote: post #26
T_S_ wrote: post #16

Earlier quoted context omitted.

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…

> Math can usefully be described as a nothing but a bunch of design patterns, discovered and built in just the way you say. 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 t…

Besides many theorems math does have design patterns; Tim Gowers in his essay "The two cultures in mathematics" argues that part of the reason mathematicians in other fields sometimes think there's not much to combinatorics is that they ate used to having widely applicable insights implemented as theorems whereas combinatorics tends to have them as design patterns.

Re: Design patterns explained in Javascript

#32

Post by InclinedPlane »

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.

This is why I think a book like "Refactoring" is actually more important than the GoF book, because it beats "Design Patterns" at its own game. When someone reads about software design patterns they learn a lot of cool things but ultimately they are still left in a muddle, and as often as not they don't have the slightest clue when and where to use, or not use, which patterns. Worse yet, they can't even use the concepts to talk about real software since so much real software uses undocumented patterns.

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.

Re: Design patterns explained in Javascript

#34

Post by Flenser »

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…

Could you link up every item in the table of contents and have more cross links in the text. I like reading things like this on my kindle (using the Readability chrome extension) and anything that makes it easier to navigate would be appreciated.

Re: Design patterns explained in Javascript

#35

Post by gnaritas »

InclinedPlane wrote: post #32
gnaritas wrote: post #15

Earlier quoted context omitted.

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

This is why I think a book like "Refactoring" is actually more important than the GoF book, because it beats "Design Patterns" at its own game. When someone reads about software design patterns they learn a lot of cool things but ultimately they are still left in a muddle, and as often as not they don't have the slightest clue when and where to use, or not use, which patterns. Worse yet, they can't even use the conce…

Check out "Refactoring to Patterns"; great book shows you both, i.e. how to refactor with a goal pattern in mind to simplify things.
Post reply on HN