The Strategy Pattern in JavaScript(weblog.bocoup.com)
weblog.bocoup.com
The Strategy Pattern in JavaScript
http://weblog.bocoup.com/the-strategy-pattern-in-javascript
6 comments
I'm surprised the author didn't mention the use case where I've seen this most often: animation easing. In every JS library I've seen, the strategy pattern was used for easing functions.
Good point! I don't have much experience with animation libraries, but maybe if I look at some source code I can get a stronger real-world use case for the article...
Sorry, but (coming from a 40-years-of-software-development grizzled veteran), I don't see any new pattern here. Just good old-fashioned modularity.
Perhaps I missed the point?
Perhaps I missed the point?
I can't say I completely disagree.
When I was putting this together, I kind of felt like I was writing a general article on one method of exploiting polymorphism--not necessarily the Strategy pattern specifically. Honestly, I'm still not sure.
What I do know is that JavaScript has a number of features that make OOP significantly more informal--namely dynamic typing, object literals, and first-class functions. I'm thinking of implementing more patterns in JS in the future to try and get a better grasp on this...
I think jbwyme is getting at this with his comment http://news.ycombinator.com/item?id=2680408 (specifically "Then, if needed, use a prototype to set defaults"). Using the prototype is not really necessary at all, but it adds some amount of formality to what is otherwise a ragtag collection of objects.
When I was putting this together, I kind of felt like I was writing a general article on one method of exploiting polymorphism--not necessarily the Strategy pattern specifically. Honestly, I'm still not sure.
What I do know is that JavaScript has a number of features that make OOP significantly more informal--namely dynamic typing, object literals, and first-class functions. I'm thinking of implementing more patterns in JS in the future to try and get a better grasp on this...
I think jbwyme is getting at this with his comment http://news.ycombinator.com/item?id=2680408 (specifically "Then, if needed, use a prototype to set defaults"). Using the prototype is not really necessary at all, but it adds some amount of formality to what is otherwise a ragtag collection of objects.
You definitely missed this part in the second paragraph:
"This leads many seasoned programmers to respond with, “well, duh” when first confronted. Design patterns are derived from scrutiny of best practices in the real world (not your old CS prof’s black cauldron)."
"This leads many seasoned programmers to respond with, “well, duh” when first confronted. Design patterns are derived from scrutiny of best practices in the real world (not your old CS prof’s black cauldron)."
Try jQuery Condom, which allows you to make namespaces jQuery Plugins on the fly and override jQuery functionality without touching the global namespace (modularity).
https://github.com/kuroir/jQuery-Condom
https://github.com/kuroir/jQuery-Condom
Tell me if I have this straight: this pattern basically says to create a generic object with properties and handlers to allow for simple iteration, creation, etc. like you would with an interface. Then, if needed, use a prototype to set defaults?
Pretty much. I'm using this pattern in the following way:
SomeComponent.prototype.views = { home: { template: '/path/to/template', render: function(tmpl) { this.element.html(Mustache.to_html(tmpl, this.data)); } } };
I then have SomeComponent inherit the prototype of Component which has a generic render method. When I call the render method on any given component, it will have some logic to figure out which view it is in, then call the render method specific to that view with the correct template, that it fetches the content of under-the-hood.
Having consistent and expected behavior in your code is a huge win.
SomeComponent.prototype.views = { home: { template: '/path/to/template', render: function(tmpl) { this.element.html(Mustache.to_html(tmpl, this.data)); } } };
I then have SomeComponent inherit the prototype of Component which has a generic render method. When I call the render method on any given component, it will have some logic to figure out which view it is in, then call the render method specific to that view with the correct template, that it fetches the content of under-the-hood.
Having consistent and expected behavior in your code is a huge win.
Funny, this looks precisely like basic object-oriented programming.
In Python, at least, this pattern is called the "dispatch dictionary" and relies on the ability of Python to store just about anything as dictionary values. It is considered to be Python's answer to the question, "Why is there no switch/case in Python?"