Pro JavaScript Design Patterns (Recipes: a Problem-Solution Ap) [ペーパーバック]

Design patterns, and particularly their application in dynamic languages can be a controversial topic, and every now and again another round of blog posts bubbles up appalled at the way a new group of programmers have become infatuated with design patterns. Applied without care design patterns can quickly lead to over-engineered code that seems designed as much to draw on as many of the established patterns as possible as to solve the intended problem. But if applied with care, and with consideration of how a pattern applies in the context of your chosen language they can be a helpful way to draw on the wisdom of the coders that came before you, and make your code easier to understand to those who may inherit it.

Written by Dustin Diaz (of Google) and Ross Harmes (of Yahoo), Pro Javascript Design Patterns builds on experience of building complex, high profile javascript applications. That experience shows as each pattern is introduced with solid examples and sample code and then refined to provide looser-coupling, more flexibility and/or better performance.

Early on in the book I was concerned that some of the solutions could become too heavy and the early introduction of interfaces hinted at something akin to the early approaches to pattern usage in PHP, which often looked more like an attempt to turn PHP into Java than a way to use PHP's own features better. As the book goes on the usefulness of those interfaces, particularly for large development teams, becomes clear and most of those concerns are allayed, especially as the authors offer pros and cons for the use of each pattern and are clearly focussed on how these patterns can help produce more robust solutions.

Most of the patterns will have a fairly immediate impact for developers new to them, and even for those who have used them in other contexts it is helpful to see how they have been applied in JavaScript. Most modern JavaScript libraries rely on several of these patterns to abstract out handling of different browser quirks or adding new event types, and even if you rely heavily on one or more of the major libraries this guide may well help you understand their internals better.

I've sometimes been skeptical of books claiming to be targeted at an advanced target. Labels like "pro" are often handed out far too easily. But in this case it seems deserved. While the book does a good job of quickly introducing approaches to object-oriented programming in JavaScript, that's based on an assumption of a solid knowledge of the language and of OO development in at least one language. If you're a newcomer to JavaScript or just looking for a way to add a few fancy features to your web pages this isn't be book for you. But if you have some serious JavaScript development experience and are needing a way to tighten up your code to make it more modular and more maintainable, this book is well worth your time.

Disclaimer: I was sent a copy of this book for review by the publisher.

This book is a "JavaScript for Programmers" book. It's very detailed and advanced. I wouldn't classify it as a "JavaScript for Web Weenies" or a "JavaScript for Stupid UI Tricks" book at all. If you don't know OOP concepts in another language already, this book really might be too much for you and could frustrate you. This book is good if you are a server-side programmer and you want to know how to push JavaScript about as far as it can go (at this point). If you are a web programmer/designer with a light understanding of OOP concepts and you want to "go deep", this book could be ok, but I would try to learn OOP from another language first because this book would read better with that background knowledge. Also, I am recommending that you already know OOP from another language because you can really shoot yourself in the foot with JavaScript because it's *so* flexible and the authors prove this well! I think it's probably a good idea to know when you're going off in the weeds and JavaScript really doesn't provide many boundaries where other languages have stricter controls on what you can do.

This book shows that when used by an experienced person, JavaScript is no joke. Seriously.

When you read the book, "Pro JavaScript Design Patterns" from Ross Harmes and Dustin Diaz, it's clear that Ross and Dustin have a strong understanding of JavaScript, its strengths, and its limitations. JavaScript has a lot of stengths, in that it supports dynamic typing at runtime, public and private typing of members, flexible coding style , and existing support of class/object development. Its weaknesses, such as support for other constructs, like explicit namespaces or interface support, the writers attempt to make up for by showing potential workarounds to the issue.

The first three chapters setup some of the more complex topics: flexibility and mutability of objects, dynamic typing, structuring of classes and how to assign methods to an object's prototype. Another important subject is the differentiation between public and private members, and how these members are scoped and accessed in the class's instance.

Speaking of classes, there are a couple of different ways to setup class definitions and inheritance. The first option is prototypical inheritance, where the derived class inherits the members of the base class. Other options are mixin classes, using a helper method to copy over class definitions from one object to another. This book, with great detail, discusses the differences between the two options.
The book continues to discuss the following design patterns, and implements in full JavaScript. The concepts in the first four chapters, discussed above, are reused in the design pattern process. Each chapter highlighted below has an explanation, example (or several), guide on when to implement, pros, cons, and summary.

* Singleton Pattern - While not following the exact traditional pattern that you would see in other server-based environments, like the .NET framework, the Singleton pattern implemented in JavaScript provides a central accessible object to the application. The book also covers the subject of lazy instantiation and brancing of internal members (one example cited was to vary method implementation by browser).
* Chaining - More commonly seen in the JQuery library, chaining is the creation of a central object that gets returned from every method call. Within the prototype of every (or at least most) method is a call to return that same object. This way, the object can call one method after the other, after the other, in a more convenient fashion.
* Factory Pattern - The factory pattern provides a way to create the correct object using some sort of identifier (string, enum, object, etc.). The factory pattern instantiates an object that inherits from the same base class type, and thus the factory is responsible for its instantiation.
* Bridge Pattern - This pattern bridges multiple classes together that implement a similar functionality. It's a way to break out logical components into different objects, and follow more closely the Singular Responsibility pattern.
* Composite Pattern - This pattern requires that a particular set of objects all implement the same interface,regardless of whether a specific function is used within that object or not. The pattern is made up of leaf elements (elements at the bottom of the structure), and composite elements (which have one or more composite/leaf elements). The example used to illustrate this pattern is displaying of individual elements (textboxes and such), versus displaying composite elements.
* Faade Pattern - The faade pattern simplifies common tasks by grouping them into a parent function. For example, there are various nuances in JavaScript that vary by browser. The faade pattern facilitates working around these nuances by creating a central object with a method that checks browser type, and calls the correct method. From then on, the developer has to call this one method, instead of handling the various JavaScript nuances.
* Adapter Pattern - The adapter pattern provides a common interface across disparate interfaces that provide differing implementations. For instance, suppose you had to integrate various web service implementations. Each implementation would have a different implementation; the adapter pattern can accommodate this by providing one common interface, which this object then interacts with the web service.
* Decorator Pattern - The decorator pattern can be used to modify the behavior of its target. Decorators can be strung together to continually alter its behavior in some way, providing that each decorator alters the object appropriately. The chapter also explains what to watch out for when implementing this pattern, such as the order the patterns are created and processed.
* Flyweight Pattern - This pattern provides a caching to reuse commonly used elements, to make the underlying processes run faster. The system would first check the cache to see if the object exists before instantiating it.
* Proxy Pattern - A proxy provides access control to its underlying object's methods calls. It implements the same methods as its target, and can be a way to optimize usage of resources (especially expensive ones). This isn't necessarily related to just security in this regard. There are three types of proxies: virtual proxy, remote proxy, and protection proxy.
* Observer Pattern - The observer pattern uses subscribers and publishers. The publisher publishes to its subscriber that some event happened, and the subscriber can react to it in some way. One approach is through the use of a delegate that the publisher can call.
* Command Pattern - A command is some action that occurs within the application. A command provides a specific interface that varying command objects implement. The command can then be executed and perform its underlying action: this may be copy, paste, undo, or other operations.
* Chain of Responsibility Pattern - The chain of responsibility pattern is similar to some of the above patterns: it uses a chaining approach, which consists of firstly the sender, followed by a series of receivers that will process or ignore the request. It's a complex design pattern that the book describes very well.

Most of the chapters are explained very well; some of the examples didn't make the most sense to me as I didn't fully grasp some of the patterns. It's clear the authors know a lot more about design patterns than I do. However, don't let that detract you from the book because reading it again and trying it out yourself will help you to grasp the fundamentals. Alternatively, most of the examples are clear, concise, and to the topic at hand.

The book is a small book, consisting of many chapters (nicely broken out so I was able to do one a day). It has a lot of power to the punch for its size, which makes it a great book, and a great overview of design patterns in the JavaScript world, a world much different than most server-based languages.