Re: Pro JavaScript Design Patterns by APress

rami_nassar — Thu, 28 May 2009 04:03:21 GMT

thanks bmains

Pro JavaScript Design Patterns by APress

bmains — Thu, 28 May 2009 02:13:27 GMT

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

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.

· Façade Pattern – The façade pattern simplifies common tasks by grouping them into a parent function. For example, there are various nuances in JavaScript that vary by browser. The façade 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.

Book Reviews

Re: Pro JavaScript Design Patterns by APress

Pro JavaScript Design Patterns by APress