JavaScript: Function Invocation Patterns
JavaScript has been described as a Functional Oriented Language (this as opposed to Object Oriented Language). The reason is because functions in JavaScript do more than just separate logic into execution units, functions are first class citizens that also provide scope and the ability to create objects. Having such a heavy reliance upon functions is both a blessing and a curse: It's a blessing because it makes the language light weight and fast (the main goal of its original development), but it is a curse because you can very easily shoot yourself in the foot if you don't know what you are doing. One concern with JavaScript functions is how different invocation patterns can produce vastly different results. This post explains the four patterns, how to use them and what to watch out for. The four invocation patterns are: Method InvocationFunction InvocationConstructor InvocationApply And Call Invocation Unfortunately, there is more than one pattern that can be used to invoke functions.
Partial Application in JavaScript
Partially applying a function is a, particularly, interesting technique in which you can pre-fill-in arguments to a function before it is ever executed. In effect, partially applying a function returns a new function which you can call. This is best understood through an example: String.prototype.csv = String.prototype.split.partial(/,\s*/); var results = "John, Resig, Boston".csv(); alert( (results[1] == "Resig") + " The text values were split properly" ); In the above case we’ve taken a common function – a String’s .split() method – and have pre-filled-in the regular expression upon which to split. Function.prototype.curry = function() { var fn = this, args = Array.prototype.slice.call(arguments); return function() { return fn.apply(this, args.concat( Array.prototype.slice.call(arguments))); }; }; This is a good case of using a closure to remember state. Now, this style of partial application is perfectly useful, but we can do better.
Strategy Design Pattern in Javascript - Trifling Whims
I love the Strategy design pattern. I try to use it as much as I can. In its essence, the Strategy pattern uses delegation to decouple algorithms from the classes that use them. There are a few benefits to this. It prevents using big conditionals to decide which algorithm to use for the given type of object. It separates concerns, thus reducing the complexity of the clients and it promotes composition over subclassing. To implement Strategy, there are usually two participants: The Strategy an object that encapsulates an algorithm. The Client (or Context) an object that can use any Strategy, in a plug-and-play manner. Here is how I use the Strategy pattern in Javascript, and how it is used in the wild to break libraries into small, plug-and-play packages. Strategy as a function A function provides a great way to encapsulate an algorithm and can be used as a Strategy. Let's illustrate this with an example. In the example above, Greeter is the Client, and there are three Strategies. Reflection
Learning JavaScript Design Patterns
Design patterns are reusable solutions to commonly occurring problems in software design. They are both exciting and a fascinating topic to explore in any programming language. One reason for this is that they help us build upon the combined experience of many developers that came before us and ensure we structure our code in an optimized way, meeting the needs of problems we're attempting to solve. Design patterns also provide us a common vocabulary to describe solutions. In this book we will explore applying both classical and modern design patterns to the JavaScript programming language. Target Audience This book is targeted at professional developers wishing to improve their knowledge of design patterns and how they can be applied to the JavaScript programming language. Some of the concepts covered (closures, prototypal inheritance) will assume a level of basic prior knowledge and understanding. Acknowledgments Credits Reading Patterns are not an exact solution. Creational Design Patterns
List Out of Lambda
If you ignore the practical issues of computers like size, weight, cost, heat, and so on, what do you really need in a programming language? Let’s play around with this question. To understand this post you’ll need a basic understanding of how functions in Javascript work. If you can look at this code and understand what it prints, you’re good to go: var x = 10; var f = function(y) { console.log(x); console.log(y);} var g = f; f(1);g(2); This blog post is a thought exercise. I’m going to use Javascript for the examples. If you’ve already seen this kind of thing before (maybe you’ve gone through The Little Schemer or SICP) you may want to just skim the code here and look for anything new. The Little Schemer: If you haven’t seen anything like this, then you’re in for a treat! Finally: if you get stuck, don’t worry. Lists Let’s get started. var names = ["Alice", "Bob", "Candice"]; What if Javascript didn’t come with arrays included? List Out of If That’s it!
