Skip to content
This repository was archived by the owner on Mar 1, 2021. It is now read-only.

Commit 91e99f4

Browse files
committedAug 29, 2012
testing ssh
1 parent 4d6294a commit 91e99f4

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed
 

Diff for: ‎README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,6 @@ It occurred to me that I’ve always wanted to go through the Gang of Four book
4040

4141
I know there are a lot of people out there who aren’t too keen on design patterns but that’s not to say that they shouldn’t be used or studied. There’s a lot of code out there that starts with jQuery.click() or addEventListener or .on() and all of them are implementations of the Observer pattern. Finding this reusable approach is the main point of patterns and along with it comes a shared vocabulary that can be passed on to other developers. Rather than saying “Let’s defer the methods of our object that are subject to change to well encapsulated algorithms.” We can just say “A Strategy pattern might be nice here.”
4242

43-
Patterns should be used with caution as not everything fits so neatly into their paradigms. It’s often said that a beginner never met a pattern he didn’t like. In my experiences I’ve been burned by pattern overuse and at other times they have legitimately saved my ass. It’s also true that many patterns don’t really work or aren’t appropriate for particular languages. For instance, the GoF book was written primarily for languages which shared features of C++ and SmallTalk. I totally agree with this sentiment but I feel like along the way we’ll discover what does and doesn’t make sense in a dynamic language like JS and hopefully we can toss in some new patterns of our own. Already to the list I’ve added Promises which I use quite frequently and find to be a wonderful alternative to JavaScript’s oft seen pyramid of callbacks. Again, this is all about learning and experimenting. In my opinion a good understanding of design patterns is a threshold that needs to be crossed at some point in your career. I’m committed to doing this twice a week for the next several weeks so hopefully by the end of it we’ll have a useful resource that others can benefit from. Stay tuned!
43+
Patterns should be used with caution as not everything fits so neatly into their paradigms. It’s often said that a beginner never met a pattern he didn’t like. In my experiences I’ve been burned by pattern overuse and at other times they have legitimately saved my ass. It’s also true that many patterns don’t really work or aren’t appropriate for particular languages. For instance, the GoF book was written primarily for languages which shared features of C++ and SmallTalk. I totally agree with this sentiment but I feel like along the way we’ll discover what does and doesn’t make sense in a dynamic language like JS and hopefully we can toss in some new patterns of our own. Already to the list I’ve added Promises which I use quite frequently and find to be a wonderful alternative to JavaScript’s oft seen pyramid of callbacks. Again, this is all about learning and experimenting. In my opinion a good understanding of design patterns is a threshold that needs to be crossed at some point in your career. I’m committed to doing this twice a week for the next several weeks so hopefully by the end of it we’ll have a useful resource that others can benefit from. Stay tuned!
4444

4545
[http://robdodson.me/blog/2012/08/03/javascript-design-patterns/](http://robdodson.me/blog/2012/08/03/javascript-design-patterns/)

0 commit comments

Comments
 (0)
This repository has been archived.