Essential java script design patterns

Essential JavaScript Design Patterns http://addyosmani.com/resources/essentialjsdesign...

Essential JavaScript Design
Patterns
Volume 1.5.1

Tweet 5,803

A book by Addy Osmani

Copyright © Addy Osmani 2012. Last updated March 19th, 2012.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 unported
license. You are free to remix, tweak, and build upon this work
non-commercially, as long as you credit Addy Osmani (the copyright holder)
and license your new creations under the identical terms. Any of the above
conditions can be waived if you get permission from the copyright holder. For
any reuse or distribution, you must make clear to others the license terms of
this work. The best way to do this is with a link to the license.

Preface

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.
This can be significantly simpler than describing syntax and semantics when

1 de 184 22/03/12 11:43


we're attempting to convey a way of structuring a solution in code form to
others.

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. If you find yourself needing
to read further about these topics, a list of suggested titles is provided for
convenience.

If you would like to learn how to write beautiful, structured and organized
code, I believe this is the book for you.

Acknowledgements
I will always be grateful for the talented technical reviewers who helped review
and improve this book, including those from the community at large. The
knowledge and enthusiasm they brought to the project was simply amazing.
The official technical reviewer's tweets and blogs are also a regular source of
both ideas and inspiration and I wholeheartedly recommend checking them
out.

Alex Sexton (http://alexsexton.com, @slexaxton)
Andrée Hansson (http://andreehansson.se/, @peolanha)
I would also like to thank Rebecca Murphey (http://rebeccamurphey.com,
@rmurphey) for providing the inspiration to write this book and more
importantly, continue to make it both available on GitHub and via O'Reilly.

Finally, I would like to thank my wonderful wife Ellie, for all of her support
while I was putting together this publication.

Credits

2 de 184 22/03/12 11:43


Whilst some of the patterns covered in this book were implemented based on
personal experience, many of them have been previously identified by the
JavaScript community. This work is as such the production of the combined
experience of a number of developers. Similar to Stoyan Stefanov's logical
approach to preventing interruption of the narrative with credits (in JavaScript
Patterns), I have listed credits and suggested reading for any content covered
in the references section.

If any articles or links have been missed in the list of references, please accept
my heartfelt apologies. If you contact me I'll be sure to update them to include
you on the list.

Reading
Whilst this book is targeted at both beginners and intermediate developers, a
basic understanding of JavaScript fundamentals is assumed. Should you wish
to learn more about the langage, I am happy to recommend the following titles:

JavaScript: The Definitive Guide by David Flanagan
Eloquent JavaScript by Marijn Haverbeke
JavaScript Patterns by Stoyan Stefanov
Writing Maintainable JavaScript by Nicholas Zakas
JavaScript: The Good Parts by Douglas Crockford

Table Of Contents

Introduction
What is a Pattern?
'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three
The Structure Of A Design Pattern
Writing Design Patterns
Anti-Patterns
Categories Of Design Pattern
Summary Table Of Design Pattern Categorization
An Introduction To Design Patterns
Creational Pattern
Constructor Pattern

3 de 184 22/03/12 11:43


Singleton Pattern
Module Pattern
Revealing Module Pattern
Observer Pattern
Mediator Pattern
Prototype Pattern
Command Pattern
DRY Pattern
Facade Pattern
Factory Pattern
Mixin Pattern
Decorator Pattern
Patterns In Greater Detail
Observer (Publish/Subscribe)
MVC & MVP Structural Patterns
Decorator Pattern
Namespacing Patterns
Flyweight Pattern
Module Pattern
Examples Of Design Patterns In jQuery
Module Pattern
Lazy Initialisation
Composite Pattern
Wrapper Pattern
Facade Pattern
Observer Pattern
Iterator Pattern
Strategy Pattern
Proxy Pattern
Builder Pattern
Prototype Pattern
Modern Modular JavaScript Design Patterns
Bonus: jQuery Plugin Design Patterns
Conclusions
References

Introduction

4 de 184 22/03/12 11:43


One of the most important aspects of writing maintainable code is being able to
notice the recurring themes in that code and optimize them. This is an area
where knowledge of design patterns can prove invaluable.

In the first part of this book, we will explore the history and importance of
design patterns which can really be applied to any programming language. If
you're already sold on or are familiar with this history, feel free to skip to the
chapter 'What is a Pattern?' to continue reading.

Design patterns can be traced back to the early work of a civil engineer named
Christopher Alexander. He would often write publications about his experience
in solving design issues and how they related to buildings and towns. One day,
it occurred to Alexander that when used time and time again, certain design
constructs lead to a desired optimal effect.

In collaboration with Sarah Ishikawra and Murray Silverstein, Alexander
produced a pattern language that would help empower anyone wishing to
design and build at any scale. This was published back in 1977 in a paper titled
'A Pattern Language', which was later released as a complete hardcover book.

Some 30 years ago, software engineers began to incorporate the principles
Alexander had written about into the first documentation about design
patterns, which was to be a guide for novice developers looking to improve
their coding skills. It's important to note that the concepts behind design
patterns have actually been around in the programming industry since its
inception, albeit in a less formalized form.

One of the first and arguably most iconic formal works published on design
patterns in software engineering was a book in 1995 called 'Design Patterns:
Elements Of Reusable Object-Oriented Software'. This was written by Erich
Gamma, Richard Helm, Ralph Johnson and John Vlissides - a group that
became known as the Gang of Four (or GoF for short).

The GoF's publication is considered quite instrumental to pushing the concept
of design patterns further in our ﬁeld as it describes a number of development
techniques and pitfalls as well as providing twenty-three core Object-Oriented
design patterns frequently used around the world today. We will be covering
these patterns in more detail in the section ‘Categories of Design Patterns’.

In this book, we will take a look at a number of popular JavaScript design
patterns and explore why certain patterns may be more suitable for your

5 de 184 22/03/12 11:43


projects than others. Remember that patterns can be applied not just to vanilla
JavaScript, but also to abstracted libraries such as jQuery or Dojo as well.
Before we begin, let’s look at the exact deﬁnition of a ‘pattern’ in software
design.

What is a Pattern?

A pattern is a reusable solution that can be applied to commonly occurring
problems in software design - in our case - in writing JavaScript-powered
applications. Another way of looking at patterns are as templates for how you
solve problems - ones which can be used in quite a few different situations.

So, why is it important to understand patterns and be familiar with them?.
Design patterns have three main benefits:

1. Patterns are proven solutions: They provide solid approaches to
solving issues in software development using proven solutions that
reflect the experience and insights the developers that helped define
and improve them bring to the pattern.
2. Patterns can be easily re-used: A pattern usually reflects an out of
the box solution that can be adapted to suit your own needs. This
feature makes them quite robust.
3. Patterns can be expressive: When you look at a pattern there’s
generally a set structure and ‘vocabulary’ to the solution presented that
can help express rather large solutions quite elegantly.

Patterns are not an exact solution. It’s important that we remember the role of
a pattern is merely to provide us with a solution scheme. Patterns don’t solve
all design problems nor do they replace good software designers, however, they
do support them. Next we’ll take a look at some of the other advantages
patterns have to oﬀer.

Reusing patterns assists in preventing minor issues that can cause
major problems in the application development process. What this
means is when code is built on proven patterns, we can afford to spend less

6 de 184 22/03/12 11:43


time worrying about the structure of our code and more time focusing on the
quality of our overall solution. This is because patterns can encourage us to
code in a more structured and organized fashion so the need to refactor it for
cleanliness purposes in the future.
Patterns can provide generalized solutions which are documented in a
fashion that doesn't require them to be tied to a specific problem. This
generalized approach means that regardless of the application (and in many
cases the programming language) you are working with, design patterns can
be applied to improve the structure of your code.
Certain patterns can actually decrease the overall file-size footprint of
your code by avoiding repetition. By encouraging developers to look more
closely at their solutions for areas where instant reductions in repetition can
be made, e.g. reducing the number of functions performing similar processes
in favor of a single generalized function, the overall size of your codebase can
be decreased.
Patterns that are frequently used can be improved over time by harnessing
the collective experiences other developers using those patterns contribute
back to the design pattern community. In some cases this leads to the creation
of entirely new design patterns whilst in others it can lead to the provision of
improved guidelines on how specific patterns can be best used. This can
ensure that pattern-based solutions continue to become more robust than
ad-hoc solutions may be.

We already use patterns everyday

To understand how useful patterns can be, let's review a very simple selection
problem that the jQuery library solves for us everyday.

If we imagine that we have a script where for each DOM element on a page
with class "foo" we want to increment a counter, what's the simplest efficient
way to query for the list we need?. Well, there are a few different ways this
problem could be tackled:

1. Select all of the elements in the page and then store them. Next, filter this list
and use regular expressions (or another means) to only store those with the
class "foo".
2. Use a modern native browser feature such as querySelectorAll() to select all of
the elements with the class "foo".
3. Use a native feature such as getElementsByClassName() to similarly get back the

7 de 184 22/03/12 11:43


desired list.
So, which of these is the fastest?. You might be interested to know that it's
actually number 3 by a factor of 8-10 times the alternatives. In a real-world
application however, 3. will not work in versions of Internet Explorer below 9
and thus it's necessary to use 1. where 3. isn't supported.

Developers using jQuery don't have to worry about this problem, as it's luckily
abstraced away for us. The library opts for the most optimal approach to
selecting elements depending on what your browser supports.

It internally uses a number of different design patterns, the most frequent
one being a facade, which provides a simple set of interfaces to a more
complex body of code. We're probably all familiar with $(elem) (yes, it's a
facade!), which is a lot easier to use than having to manually normalize cross-
browser differences.

We'll be looking at this and more design patterns later on in the book.

'Pattern'-ity Testing, Proto-Patterns &
The Rule Of Three

Remember that not every algorithm, best practice or solution represents what
might be considered a complete pattern. There may be a few key ingredients
here that are missing and the pattern community is generally weary of
something claiming to be one unless it has been heavily vetted. Even if
something is presented to us which *appears* to meet the criteria for a
pattern, it should not be considered one until it has undergone suitable periods
of scrutiny and testing by others.

Looking back upon the work by Alexander once more, he claims that a pattern
should both be a process and a ‘thing’. This deﬁnition is obtuse on purpose as
he follows by saying that it is the process should create the ‘thing’. This is a
reason why patterns generally focus on addressing a visually identiﬁable
structure i.e you should be able to visually depict (or draw) a picture
representing the structure that placing the pattern into practice results in.

In studying design patterns, you may come across the term ‘proto-pattern’

8 de 184 22/03/12 11:43


quite frequently. What is this? Well, a pattern that has not yet been known to
pass the ‘pattern’-ity tests is usually referred to as a proto-pattern. Proto-
patterns may result from the work of someone that has established a particular
solution that is worthy of sharing with the community, but may not have yet
had the opportunity to have been vetted heavily due to it’s very young age.

Alternatively, the individual(s) sharing the pattern may not have the time or
interest of going through the ‘pattern’-ity process and might release a short
description of their proto-pattern instead. Brief descriptions of this type of
pattern are known as patlets.

The work involved in fully documenting a qualiﬁed pattern can be quite
daunting. Looking back at some of the earliest work in the ﬁeld of design
patterns, a pattern may be considered ‘good’ if it does the following:

Solves a particular problem: Patterns are not supposed to just capture
principles or strategies. They need to capture solutions. This is one of the most
essential ingredients for a good pattern.
The solution to this problem cannot be obvious : You can often find that
problem-solving techniques attempt to derive from well-known first principles.
The best design patterns usually provide solutions to problems indirectly - this
is considered a necessary approach for the most challenging problems related
to design.
The concept described must have been proven: Design patterns require
proof that they function as described and without this proof the design cannot
be seriously considered. If a pattern is highly speculative in nature, only the
brave may attempt to use it.
It must describe a relationship : In some cases it may appear that a pattern
describes a type of module. Although an implementation may appear this way,
the official description of the pattern must describe much deeper system
structures and mechanisms that explain it’s relationship to code.

You wouldn’t be blamed for thinking that a proto-pattern which doesn’t meet
the guidelines is worth learning from at all, but this is far from the truth. Many
proto-patterns are actually quite good. I’m not saying that all proto-patterns are
worth looking at, but there are quite a few useful ones in the wild that could
assist you with future projects. Use best judgment with the above list in mind

9 de 184 22/03/12 11:43


and you’ll be ﬁne in your selection process.

One of the additional requirements for a pattern to be valid is that they display
some recurring phenomenon. This is often something that can be qualified in
at least three key areas, referred to as the rule of three. To show recurrence
using this rule, one must demonstrate:

1. Fitness of purpose - how is the pattern considered successful?
2. Usefulness - why is the pattern considered successful?
3. Applicability - is the design worthy of being a pattern because it has wider
applicability? If so, this needs to be explained.When reviewing or defining a
pattern, it is important to keep the above in mind.

The Structure Of A Design Pattern

When studying design patterns, you may wonder what teams that create them
have to put in their design pattern descriptions. Every pattern has to initially
be formulated in a form of a rule that establishes a relationship between a
context, a system of forces that arises in that context and a configuration
that allows these forces to resolve themselves in context.

I find that a lot of the information available out there about the structure of a
good pattern can be condensed down to something more easily digestible.With
this in mind, lets now take a look at a summary of the component elements for
a design pattern.

A design pattern must have a:

Pattern Name and a description
Context Outline – the contexts in which the pattern is eﬀective in responding
to the users needs.

10 de 184 22/03/12 11:43


Problem Statement – a statement of the problem being addressed so we can
understand the intent of the pattern.
Solution – a description of how the user’s problem is being solved in an
understandable list of steps and perceptions.
Design – a description of the pattern’s design and in particular, the user’s
behavior in interacting with it
Implementation – a guide to how the pattern would be implemented
Illustrations – a visual representation of classes in the pattern (eg. a
diagram))
Examples – an implementation of the pattern in a minimal form
Co-requisites – what other patterns may be needed to support use of the
pattern being described?
Relations – what patterns does this pattern resemble? does it closely mimic
any others?
Known usage – is the pattern being used in the ‘wild’?. If so, where and how?
Discussions – the team or author’s thoughts on the exciting beneﬁts of the
pattern

Design patterns are quite a powerful approach to getting all of the developers
in an organization or team on the same page when creating or maintaining
solutions. If you or your company ever consider working on your own pattern,
remember that although they may have a heavy initial cost in the planning and
write-up phases, the value returned from that investment can be quite worth it.
Always research thoroughly before working on new patterns however, as you
may find it more beneficial to use or build on top of existing proven patterns
than starting afresh.

Writing Design Patterns

Although this book is aimed at those new to design patterns, a fundamental
understanding of how a design pattern is written can offer you a number of
useful benefits. For starters, you can gain a deeper appreciation for the
reasoning behind a pattern being needed but can also learn how to tell if a
pattern (or proto-pattern) is up to scratch when reviewing it for your own

11 de 184 22/03/12 11:43


needs.

Writing good patterns is a challenging task. Patterns not only need to provide a
substantial quantity of reference material for end-users (such as the items
found in the structure section above), but they also need to be able to almost
tell a ‘story’ that describes the experience they are trying to convey. If you’ve
already read the previous section on ‘what’ a pattern is, you may think that this
in itself should help you identify patterns when you see them in the wild. This
is actually quite the opposite - you can’t always tell if a piece of code you’re
inspecting follows a pattern.

When looking at a body of code that you think may be using a pattern, you
might write down some of the aspects of the code that you believe falls under a
particular existing pattern, but it may not be a one at all. In many cases of
pattern-analysis you’ll find that you’re just looking at code that follows good
principles and design practices that could happen to overlap with the rules for
a pattern by accident. Remember - solutions in which neither interactions nor
defined rules appear are not patterns.

If you’re interested in venturing down the path of writing your own design
patterns I recommend learning from others who have already been through
the process and done it well. Spend time absorbing the information from a
number of diﬀerent design pattern descriptions and books and take in what’s
meaningful to you - this will help you accomplish the goals you’ve got of
designing the pattern you want to achieve. You’ll probably also want to
examine the structure and semantics of existing patterns - this can be begun
by examining the interactions and context of the patterns you are interested in
so you can identify the principles that assist in organizing those patterns
together in useful conﬁgurations.

Once you’ve exposed yourself to a wealth of information on pattern literature,
you may wish to begin your pattern using an existing format and see if you can
brainstorm new ideas for improving it or integrating your ideas in there. An
example of someone that did this quite recently is JavaScript developer
Christian Heilmann, who took an existing pattern called the module pattern
and made some fundamentally useful changes to it to create the revealing
module pattern (this is one of the patterns covered later in this book).

If you would like to try your hand at writing a design pattern (even if just for

12 de 184 22/03/12 11:43


the learning experience of going through the process), the tips I have for doing
so would be as follows:

Bear in mind practicability: Ensure that your pattern describes proven
solutions to recurring problems rather than just speculative solutions which
haven’t been qualiﬁed.
Ensure that you draw upon best practices: The design decisions you make
should be based on principles you derive from an understanding of best
practices.
Your design patterns should be transparent to the user: Design patterns
should be entirely transparent to any type of user-experience. They are
primarily there to serve the developers using them and should not force
changes to behaviour in the user-experience that would not be incurred
without the use of a pattern.
Remember that originality is not key in pattern design: When writing a
pattern, you do not need to be the original discoverer of the solutions being
documented nor do you have to worry about your design overlapping with
minor pieces of other patterns.If your design is strong enough to have broad
useful applicability, it has a chance of being recognized as a proper pattern
Know the differences between patterns and design: A design pattern
generally draws from proven best practice and serves as a model for a designer
to create a solution. The role of the pattern is to give designers guidance to
make the best design choices so they can cater to the needs of their users.
Your pattern needs to have a strong set of examples: A good pattern
description needs to be followed by an equally strong set of examples
demonstrating the successful application of your pattern. To show broad
usage, examples that exhibit good design principles are ideal.

Pattern writing is a careful balance between creating a design that is general,
specific and above all, useful. Try to ensure that if writing a pattern you cover
the widest possible areas of application and you should be fine. I hope that this
brief introduction to writing patterns has given you some insights that will
assist your learning process for the next sections of this book.

13 de 184 22/03/12 11:43


Anti-Patterns

If we consider that a pattern represents a best practice, an anti-pattern
represents a lesson that has been learned. The term anti-patterns was coined
in 1995 by Andrew Koenig in the November C++ Report that year, inspired by
the GoF's book Design Patterns. In Koenig’s report, there are two notions of
anti-patterns that are presented. Anti-Patterns:

Describe a bad solution to a particular problem which resulted in a bad
situation occurring
Describe how to get out of said situation and how to go from there to a good
solution

On this topic, Alexander writes about the difficulties in achieving a good
balance between good design structure and good context:

“These notes are about the process of design; the process of inventing physical
things which display a new physical order, organization, form, in response to
function.…every design problem begins with an effort to achieve fitness
between two entities: the form in question and its context. The form is the
solution to the problem; the context defines the problem”.

While it’s quite important to be aware of design patterns, it can be equally
important to understand anti-patterns. Let us qualify the reason behind this.
When creating an application, a project’s life-cycle begins with construction
however once you’ve got the initial release done, it needs to be maintained.
The quality of a final solution will either be good or bad, depending on the level
of skill and time the team have invested in it. Here good and bad are
considered in context - a ‘perfect’ design may qualify as an anti-pattern if
applied in the wrong context.

The bigger challenges happen after an application has hit production and is
ready to go into maintenance mode. A developer working on such a system
who hasn’t worked on the application before may introduce a bad design into
the project by accident. If said bad practices are created as anti-patterns, they
allow developers a means to recognize these in advance so that they can avoid
common mistakes that can occur - this is parallel to the way in which design

14 de 184 22/03/12 11:43


patterns provide us with a way to recognize common techniques that are
useful.

To summarize, an anti-pattern is a bad design that is worthy of documenting.
Examples of anti-patterns in JavaScript are the following:

Polluting the namespace by defining a large number of variables in the global
context
Passing strings rather than functions to either setTimeout or setInterval as
this triggers the use of eval() internally.
Prototyping against the Object object (this is a particularly bad anti-pattern)
Using JavaScript in an inline form as this is inflexible
The use of document.write where native DOM alternatives such as
document.createElement are more appropriate. document.write has been
grossly misused over the years and has quite a few disadvantages including
that if it's executed after the page has been loaded it can actually overwrite the
page you're on, whilst document.createElement does not. You can see here for
a live example of this in action. It also doesn't work with XHTML which is
another reason opting for more DOM-friendly methods such as
document.createElement is favorable.

Knowledge of anti-patterns is critical for success. Once you are able to
recognize such anti-patterns, you will be able to refactor your code to negate
them so that the overall quality of your solutions improves instantly.

Categories Of Design Pattern

A glossary from the well-known design book, Domain-Driven Terms, rightly
states that:

“A design pattern names, abstracts, and identiﬁes the key
aspects of a common design structure that make it useful for
creating a reusable object-oriented design. The design
pattern identiﬁes the participating classes and their

15 de 184 22/03/12 11:43


instances, their roles and collaborations, and the distribution
of responsibilities.

Each design pattern focuses on a particular object-oriented
design problem or issue. It describes when it applies,
whether or not it can be applied in view of other design
constraints, and the consequences and trade-offs of its use.
Since we must eventually implement our designs, a design
pattern also provides sample ... code to illustrate an
implementation.

Although design patterns describe object-oriented designs,
they are based on practical solutions that have been
implemented in mainstream object-oriented programming
languages ....”

Design patterns can be broken down into a number of diﬀerent categories. In
this section we’ll review three of these categories and briefly mention a few
examples of the patterns that fall into these categories before exploring
specific ones in more detail.

Creational Design Patterns

Creational design patterns focus on handling object creation mechanisms
where objects are created in a manner suitable for the situation you are
working in. The basic approach to object creation might otherwise lead to
added complexity in a project whilst creational patterns aim to solve this
problem by controlling the creation of such objects.

Some of the patterns that fall under this category are: Factory, Abstract,
Prototype, Singleton and Builder.

Structural Design Patterns

16 de 184 22/03/12 11:43


Structural patterns focus on the composition of classes and objects. Structural
‘class’ creation patterns use inheritance to compose interfaces whilst ‘object’
patterns define methods to create objects to obtain new functionality.

Patterns that fall under this category include: Decorator, Facade, Composite,
Adapter and Bridge

Behavioral Design Patterns

The main focus behind this category of patterns is the communication between
a class’s objects. By specifically targeting this problem, these patterns are able
to increase the flexibility in carrying out this communication.

Some behavioral patterns include: Iterator, Mediator, Observer and Visitor.

Summary Table Of Design Pattern
Categorization

In my early experiences of learning about design patterns, I personally found
the following table a very useful reminder of what a number of patterns has to
offer - it covers the 23 Design Patterns mentioned by the GoF. The original
table was summarized by Elyse Nielsen back in 2004 and I've modified it where
necessary to suit our discussion in this section of the book.

I recommend using this table as reference, but do remember that there are a
number of additional patterns that are not mentioned here but will be
discussed later in the book.

A brief note on classes

Keep in mind that there will be patterns in this table that reference the concept
of 'classes'. JavaScript is a class-less language, however classes can be
simulated using functions.

17 de 184 22/03/12 11:43


The most common approach to achieving this is by defining a JavaScript
function where we then create an object using the new keyword. this can be
used to help define new properties and methods for the object as follows:

1 // A car 'class'
2 function Car ( model ){
3 this.model = model;
4 this.color = 'silver';
5 this.year = '2012';
6 this.getInfo = function(){
7 return this.model + ' ' + this.year;
8 }
9 }

We can then instantiate the object using the Car constructor we defined above
like this:

1 var myCar = new Car('ford');
2 myCar.year = '2010';
3 console.log(myCar.getInfo());

For more ways to define 'classes' using JavaScript, see Stoyan Stefanov's
useful post on them.

Let us now proceed to review the table.

Creational Based on the concept of creating an object.
Class
Factory This makes an instance of several derived classes based on
Method interfaced data or events.
Object
Abstract Creates an instance of several families of classes without
Factory detailing concrete classes.
Separates object construction from its representation, always
Builder
creates the same type of object.
Prototype A fully initialized instance used for copying or cloning.
Singleton A class with only a single instance with global access points.

Structural Based on the idea of building blocks of objects
Class
Match interfaces of different classes therefore classes can
Adapter
work together despite incompatible interfaces

18 de 184 22/03/12 11:43


Object
Match interfaces of different classes therefore classes can
Adapter
work together despite incompatible interfaces
Separates an object's interface from its implementation so the
Bridge
two can vary independently
A structure of simple and composite objects which makes the
Composite
total object more than just the sum of its parts.
Decorator Dynamically add alternate processing to objects.
A single class that hides the complexity of an entire
Facade
subsystem.
A fine-grained instance used for efficient sharing of
Flyweight
information that is contained elsewhere.
Proxy A place holder object representing the true object

Behavioral Based on the way objects play and work together.
Class
A way to include language elements in an application to match
Interpreter
the grammer of the intended language.
Template Creates the shell of an algorithm in a method, then defer the
Method exact steps to a subclass.
Object
Chain of A way of passing a request between a chain of objects to find
Responsibility the object that can handle the request.
Encapsulate a command request as an object to enable,
Command logging and/or queuing of requests, and provides error-
handling for unhandled requests.
Sequentially access the elements of a collection without
Iterator
knowing the inner workings of the collection.
Defines simplified communication between classes to prevent
Mediator
a group of classes from referring explicitly to each other.
Memento Capture an object's internal state to be able to restore it later.
A way of notifying change to a number of classes to ensure
Observer
consistency between the classes.
State Alter an object's behavior when its state changes
Encapsulates an algorithm inside a class separating the
Strategy
selection from the implementation

19 de 184 22/03/12 11:43


Visitor Adds a new operation to a class without changing the class

An Introduction To Design Patterns

We are now going to explore JavaScript implementations of a number of both
classical and modern design patterns. This section of the book will cover an
introduction to these patterns, whilst the next section will focus on looking at
some select patterns in greater detail.

A common question developers regularly ask is what the 'ideal' set of patterns
they should be using are. There isn't a singular answer to this question, but
with the aid of what you'll learn in this book, you will hopefully be able to use
your best judgement to select the right patterns to best suit your project's
needs.

The patterns we will be exploring in this section are the:

Creational Pattern
Constructor Pattern
Singleton Pattern
Module Pattern
Revealing Module Pattern
Observer Pattern
Mediator Pattern
Prototype Pattern
Command Pattern
DRY Pattern
Facade Pattern
Factory Pattern
Mixin Pattern
Decorator Pattern

20 de 184 22/03/12 11:43


The Creational Pattern
The Creational pattern is the basis for a number of the other design patterns
we'll be looking at in this section and is probably the easiest to understand. As
you may guess, the creational pattern deals with the idea of creating new
things, specifically new objects. In JavaScript, the common way of creating new
objects (collections of name/value) pairs is as follows:

Each of the following options will create a new empty object:

1 var newObject = {}; // or
2
3 var newObject = Object.create(null); // or
4
5 var newObject = new Object();

Where the 'Object' constructor creates an object wrapper for a specific value,
or where no value is passed, it will create an empty object and return it.

There are then a number of ways in which keys and values can then be
assigned to an object including:

1 newObject.someKey = 'Hello World';
2 newObject['someKey'] = 'Hello World';
3
4 // which can be accessed in a similar fashion
5 var key = newObject.someKey; //or
6 var key = newObject['someKey'];

We can also define new properties on objects as follows, should we require
more granular configuration capabilities:

01 // First, define a new Object 'man'
02 var man = Object.create(null);
03
04 // Next let's create a configuration object containing properties
05 // Properties can be writable, enumerable and configurable
06 var config = {
07 writable: true,
08 enumerable: true,
09 configurable: true
10 };
11
12 // Typically one would use Object.defineProperty() to add new
13 // properties. For convenience we will use a short-hand version:
14
15 var defineProp = function ( obj, key, value ){
16 config.value = value;
17 Object.defineProperty(obj, key, config);
18 }
19

21 de 184 22/03/12 11:43


20 defineProp( man, 'car', 'Delorean' );
21 defineProp( man, 'dob', '1981' );
22 defineProp( man, 'beard', false );

As we will see a little later in the book, this can even be used for inheritance,
as follows:

1 var driver = Object.create( man );
2 defineProp (driver, 'topSpeed', '100mph');
3 driver.topSpeed // 100mph

Thanks to Yehuda Katz for the less verbose version presented above.

The Constructor Pattern
The phrase ‘constructor’ is familiar to most developers, however if you’re a
beginner it can be useful to review what a constructor is before we get into
talking about a pattern dedicated to it.

Constructors are used to create specific types of objects - they both prepare the
object for use and can also accept parameters which the constructor uses to
set the values of member variables when the object is first created. The idea
that a constructor is a paradigm can be found in the majority of programming
languages, including JavaScript. You’re also able to define custom constructors
that define properties and methods for your own types of objects.

Basic Constructors

In JavaScript, constructor functions are generally considered a reasonable way
to implement instances. As we saw earlier, JavaScript doesn't support the
concept of classes but it does support special constructor functions. By simply
prefixing a call to a constructor function with the keyword 'new', you can tell
JavaScript you would like function to behave like a constructor and instantiate
a new object with the members defined by that function.Inside a constructor,
the keyword 'this' references the new object that's being created. Again, a very
basic constructor may be:

01 function Car( model, year, miles ){
03 this.year = year;
04 this.miles = miles;
05 this.toString = function(){
06 return this.model + " has done " + this.miles + " miles";
07 };

22 de 184 22/03/12 11:43


08 }
09
10 var civic = new Car( "Honda Civic" , 2009, 20000 );
11 var mondeo = new Car( "Ford Mondeo", 2010 , 5000 );
12
13 console.log(civic.toString());
14 console.log(mondeo.toString());

The above is a simple version of the constructor pattern but it does suffer from
some problems. One is that it makes inheritance difficult and the other is that
functions such as toString() are redefined for each of the new objects created
using the Car constructor. This isn't very optimal as the function should ideally
be shared between all of the instances of the Car type.

Constructors With Prototypes

Functions in JavaScript have a property called a prototype. When you call a
JavaScript constructor to create an object, all the properties of the
constructor's prototype are then made available to the new object. In this
fashion, multiple Car objects can be created which access the same prototype.
We can thus extend the original example as follows:

01 function Car( model, year, miles ){
05 }
06
07 /*
08 Note here that we are using Object.prototype.newMethod rather than
09 Object.prototype so as to avoid redefining the prototype object
10 */
11 Car.prototype.toString = function(){
12 return this.model + " has done " + this.miles + " miles";
13 };
14
15 var civic = new Car( "Honda Civic", 2009, 20000);
16 var mondeo = new Car( "Ford Mondeo", 2010, 5000);
17
18 console.log(civic.toString());

Here, a single instance of toString() will now be shared between all of the Car
objects.

Note: Douglas Crockford recommends capitalizing your constructor functions
so that it is easier to distinguish between them and normal functions.

23 de 184 22/03/12 11:43


The Singleton Pattern
In conventional software engineering, the singleton pattern can be
implemented by creating a class with a method that creates a new instance of
the class if one doesn't exist. In the event of an instance already existing, it
simply returns a reference to that object.

The singleton pattern is thus known because traditionally, it restricts
instantiation of a class to a single object. With JavaScript, singletons serve as a
namespace provider which isolate implementation code from the global
namespace so-as to provide a single point of access for functions.

The singleton doesn't provide a way for code that doesn't know about a
previous reference to the singleton to easily retrieve it - it is not the object or
'class' that's returned by a singleton, it's a structure. Think of how closured
variables aren't actually closures - the function scope that provides the closure
is the closure.

Singletons in JavaScript can take on a number of different forms and
researching this pattern online is likely to result in at least 10 different
variations. In its simplest form, a singleton in JS can be an object literal
grouped together with its related methods and properties as follows:

01 var mySingleton = {
02 property1: "something",
03
04 property2: "something else",
05
06 method1:function(){
07 console.log('hello world');
08 }
09
10 };

If you wished to extend this further, you could add your own private members
and methods to the singleton by encapsulating variable and function
declarations inside a closure. Exposing only those which you wish to make
public is quite straight-forward from that point as demonstrated below:

01 var mySingleton = function(){
02
03 // here are our private methods and variables
04 var privateVariable = 'something private';
05 function showPrivate(){
06 console.log( privateVariable );
07 }
08

24 de 184 22/03/12 11:43


09 // public variables and methods (which can access
10 // private variables and methods )
11 return {
12
13 publicMethod:function(){
14 showPrivate();
15 },
16
17 publicVar:'the public can see this!'
18
19 };
20 };
21
22 var single = mySingleton();
23 single.publicMethod(); // logs 'something private'
24 console.log( single.publicVar ); // logs 'the public can see this!'

The above example is great, but let's next consider a situation where you only
want to instantiate the singleton when it's needed. To save on resources, you
can place the instantiation code inside another constructor function as follows:

01 var Singleton = (function(){
02 var instantiated;
03
04 function init (){
05 // singleton here
06 return {
07 publicMethod: function(){
08 console.log( 'hello world' );
09 },
10 publicProperty: 'test'
11 };
12 }
13
14 return {
15 getInstance: function(){
16 if ( !instantiated ){
17 instantiated = init();
18 }
19 return instantiated;
20 }
21 };
22 })();
23
24 // calling public methods is then as easy as:
25 Singleton.getInstance().publicMethod();

So, where else is the singleton pattern useful in practice?. Well, it's quite
useful when exactly one object is needed to coordinate patterns across the
system. Here's one last example of the singleton pattern being used:

25 de 184 22/03/12 11:43


01 var SingletonTester = (function(){
02
03 // args: an object containing arguments for the singleton
04 function Singleton( args ) {
05
06 // set args variable to args passed or empty object if none provided.
07 var args = args || {};
08 //set the name parameter
09 this.name = 'SingletonTester';
10 //set the value of pointX
11 this.pointX = args.pointX || 6; //get parameter from arguments or
set default
12 //set the value of pointY
13 this.pointY = args.pointY || 10;
14
15 }
16
17 // this is our instance holder
18 var instance;
19
20 // this is an emulation of static variables and methods
21 var _static = {
22 name: 'SingletonTester',
23 // This is a method for getting an instance
24
25 // It returns a singleton instance of a singleton object
26 getInstance: function ( args ){
27 if (instance === undefined) {
28 instance = new Singleton( args );
29 }
30 return instance;
31 }
32 };
33 return _static;
34 })();
35
36 var singletonTest = SingletonTester.getInstance({pointX: 5});
37 console.log(singletonTest.pointX); // outputs 5

The Module Pattern
Let's now look at the popular module pattern. Note that we'll be covering this
pattern in greater detail in the next section of the book, but a basic
introduction to it will be given in this chapter.

The module pattern was originally defined as a way to provide both private and
public encapsulation for classes in conventional software engineering.

In JavaScript, the module pattern is used to further emulate the concept of
classes in such a way that we're able to include both public/private methods

26 de 184 22/03/12 11:43


and variables inside a single object, thus shielding particular parts from the
global scope. What this results in is a reduction in the likelihood of your
function names conflicting with other functions defined in additional scripts on
the page.

JavaScript as a language doesn't have access modifiers that would allow us to
implement true privacy, but for the purposes of most use cases, simulated
privacy should work fine.

Exploring the concept of public and private methods further, the module
pattern pattern allows us to have particular methods and variables which are
only accessible from within the module, meaning that you have a level of
shielding from external entities accessing this 'hidden' information.

Let's begin looking at an implementation of the module pattern by creating a
module which is self-contained. Here, other parts of the code are unable to
directly read the value of our incrementCounter() or resetCounter(). The counter
variable is actually fully shielded from our global scope so it acts just like a
private variable would - its existence is limited to within the module's closure
so that the only code able to access its scope are our two functions. Our
methods are effectively namespaced so in the test section of our code, we need
to prefix any calls with the name of the module (eg. 'testModule').

01 var testModule = (function(){
02 var counter = 0;
03 return {
04 incrementCounter: function() {
05 return counter++;
06 },
07 resetCounter: function() {
08 console.log('counter value prior to reset:' + counter);
09 counter = 0;
10 }
11 };
12 })();
13
14 // test
15 testModule.incrementCounter();
16 testModule.resetCounter();

When working with the module pattern, you may find it useful to define a
simple template that you use for getting started with it. Here's one that covers
namespacing, public and private variables:

01 var myNamespace = (function(){
02
03 var myPrivateVar = 0;

27 de 184 22/03/12 11:43


04 var myPrivateMethod = function( someText ){
05 console.log(someText);
06 };
07
08 return {
09
10 myPublicVar: "foo",
11
12 myPublicFunction: function(bar){
13 myPrivateVar++;
14 myPrivateMethod(bar);
15 }
16 };
17
18 })();

A piece of trivia is that the module pattern was originally defined by Douglas
Crockford (famous for his book 'JavaScript: The Good Parts, and more),
although it is likely that variations of this pattern were used long before this.
Another piece of trivia is that if you've ever played with Yahoo's YUI library,
some of its features may appear quite familiar and the reason for this is that
the module pattern was a strong influence for YUI when creating their
components.

Advantages: We've seen why the singleton pattern can be useful, but why is
the module pattern a good choice? For starters, it's a lot cleaner for developers
coming from an object-oriented background than the idea of true
encapsulation, at least from a JavaScript perspective. Secondly, it supports
private data - so, in the module pattern, public parts of your code are able to
touch the private parts, however the outside world is unable to touch the
class's private parts (no laughing! Oh, and thanks to David Engfer for the joke).

Disadvantages: The disadvantages of the module pattern are that as you
access both public and private members differently, when you wish to change
visibility, you actually have to make changes to each place the member was
used. You also can't access private members in methods that are added to the
object at a later point. That said, in many cases the module pattern is still quite
useful and when used correctly, certainly has the potential to improve the
structure of your application. Here's a final module pattern example:

01 var someModule = (function(){
02
03 // private attributes
04 var privateVar = 5;
05
06 // private methods
07 var privateMethod = function(){
08 return 'Private Test';

28 de 184 22/03/12 11:43


09 };
10
11 return {
12 // public attributes
13 publicVar: 10,
14 // public methods
16 return ' Followed By Public Test ';
17 },
18
19 // let's access the private members
20 getData: function(){
21 return privateMethod() + this.publicMethod() + privateVar;
22 }
23 }
24 })(); //the parens here cause the anonymous function to execute and
return
25
26 someModule.getData();

To continue reading more about the module pattern, I strongly recommend
Ben Cherry's JavaScript Module Pattern In-Depth article.

The Revealing Module Pattern
Now that we're a little more familiar with the Module pattern, let’s take a look
at a slightly improved version - Christian Heilmann’s Revealing Module
pattern.

The Revealing Module Pattern came about as Heilmann (now at Mozilla) was
frustrated with the fact that if you had to repeat the name of the main object
when you wanted to call one public method from another or access public
variables. He also disliked the Module pattern’s requirement for having to
switch to object literal notation for the things you wished to make public.

The result of his efforts were an updated pattern where you would simply
define all of your functions and variables in the private scope and return an
anonymous object at the end of the module along with pointers to both the
private variables and functions you wished to reveal as public.

Once again, you’re probably wondering what the beneﬁts of this approach are.
The Reveling Module Pattern allows the syntax of your script to be fairly
consistent - it also makes it very clear at the end which of your functions and
variables may be accessed publicly, something that is quite useful. In addition,

29 de 184 22/03/12 11:43


you are also able to reveal private functions with more specific names if you
wish.

An example of how to use the revealing module pattern can be found below:

01 var myRevealingModule = (function(){
02
03 var name = 'John Smith';
04 var age = 40;
05
06 function updatePerson(){
07 name = 'John Smith Updated';
08 }
09 function setPerson () {
10 name = 'John Smith Set';
11 }
12 function getPerson () {
13 return name;
14 }
15 return {
16 set: setPerson,
17 get: getPerson
18 };
19 }());
20
21 // Sample usage:
22 myRevealingModule.get();

The Observer Pattern
The Observer pattern (also known as the Publish/Subscribe model) is a design
pattern which allows an object (known as an observer) to watch another object
(the subject) where the pattern provides a means for the subject and observer
to form a publish-subscribe relationship. It is regularly used when we wish to
decouple the different parts of an application from one another.

Note that this is another pattern we'll be looking at in greater detail in the next
section of the book.

Observers are able to register (subscribe) to receive notifications from the
subject when something interesting happens. When the subject needs to notify
observers about interesting events, it broadcasts (publishes) a notification of
these events to each observer (which can include data related to the event). .

30 de 184 22/03/12 11:43


The motivation behind using the observer pattern is where you need to
maintain consistency between related objects without making classes tightly
coupled. For example, when an object needs to be able to notify other objects
without making assumptions regarding those objects. Another use case is
where abstractions have more than one aspect, where one depends on the
other. The encapsulation of these aspects in separate objects allows the
variation and re-use of the objects independently.

Advantages using the observer pattern include:

Support for simple broadcast communication. Notifications are broadcast
automatically to all objects that have subscribed.
Dynamic relationships may exist between subjects and observers which can be
easily established on page load. This provides a great deal of flexibility.
Abstract coupling between subjects and observers where each can be extended
and re-used individually.
Disadvantages
A draw-back of the pattern is that observers are ignorant to the existence of
each other and are blind to the cost of switching in subject. Due to the dynamic
relationship between subjects and observers the update dependency can be
difficult to track.

Let us now take a look at an example of the observer pattern implemented in
JavaScript. The following demo is a minimalist version of Pub/Sub I released on
GitHub under a project called pubsubz. Sample usage of this implementation
can be seen shortly.

Observer implementation
01 var pubsub = {};
02
03 (function(q) {
04
05 var topics = {},
06 subUid = -1;
07
08 // Publish or broadcast events of interest
09 // with a specific topic name and arguments
10 // such as the data to pass along
11 q.publish = function( topic, args ) {
12
13 if ( !topics[topic] ) {
14 return false;
15 }
16
17 setTimeout(function() {

31 de 184 22/03/12 11:43


18 var subscribers = topics[topic],
19 len = subscribers ? subscribers.length : 0;
20
21 while (len--) {
22 subscribers[len].func(topic, args);
23 }
24 }, 0);
25
26 return true;
27
28 };
29
30 // Subscribe to events of interest
31 // with a specific topic name and a
32 // callback function, to be executed
33 // when the topic/event is observed
34 q.subscribe = function( topic, func ) {
35
36 if (!topics[topic]) {
37 topics[topic] = [];
38 }
39
40 var token = (++subUid).toString();
41 topics[topic].push({
42 token: token,
43 func: func
44 });
45 return token;
46 };
47
48 // Unsubscribe from a specific
49 // topic, based on a tokenized reference
50 // to the subscription
51 q.unsubscribe = function( token ) {
52 for ( var m in topics ) {
53 if ( topics[m] ) {
54 for (var i = 0, j = topics[m].length; i < j; i++) {
55 if (topics[m][i].token === token) {
56 topics[m].splice(i, 1);
57 return token;
58 }
59 }
60 }
61 }
62 return false;
63 };
64 }( pubsub ));

Observing and broadcasting

We can now use the implementation to publish and subscribe to events of
interest as follows:

01 var testSubscriber = function( topics , data ){
02 console.log( topics + ": " + data );
03 };
04

32 de 184 22/03/12 11:43


05 // Publishers are in charge of "publishing" notifications about events
06
07 pubsub.publish( 'example1', 'hello world!' );
08 pubsub.publish( 'example1', ['test','a','b','c'] );
09 pubsub.publish( 'example1', [{'color':'blue'},{'text':'hello'}] );
10
11 // Subscribers basically "subscribe" (or listen)
12 // And once they've been "notified" their callback functions are invoked
13 var testSubscription = pubsub.subscribe( 'example1', testSubscriber );
14
15 // Unsubscribe if you no longer wish to be notified
16
17 setTimeout(function(){
18 pubsub.unsubscribe( testSubscription );
19 }, 0);
20
21 pubsub.publish( 'example1', 'hello again! (this will fail)' );

A jsFiddle version of this example can be found at http://jsfiddle.net/LxPrq/

Note:If you are interested in a pub/sub pattern implementation using jQuery, I
recommend Ben Alman's GitHub Gist for an example of how to achieve this.

The Mediator Pattern
The dictionary refers to a Mediator as 'a neutral party who assists in
negotiations and conflict resolution'.

In software engineering, a Mediator is a behavioural design pattern that allows
us to expose a unified interface through which the different parts of a system
may communicate. If it appears a system may have too many direct
relationships between modules (colleagues), it may be time to have a central
point of control that modules communicate through instead. The Mediator
promotes loose coupling by ensuring that instead of modules referring to each
other explicitly, their interaction is handled through this central point.

If you would prefer an analogy, consider a typical airport traffic control system.
A tower (Mediator) handles what planes (modules) can take off and land
because all communications are done from the planes to the control tower,
rather than from plane-to-plane. A centralized controller is key to the success
of this system and that's really the role a mediator plays in software design.

In real-world terms, a mediator encapsulates how disparate modules interact

33 de 184 22/03/12 11:43


with each other by acting as an intermediary. At it's most basic, a mediator
could be implemented as a central base for accessing functionality as follows:

01 // Our app namespace can act as a mediator
02 var app = app || {};
03
04 // Communicate through the mediator for Ajax requests
05 app.sendRequest = function ( options ) {
06 return $.ajax($.extend({}, options);
07 }
08
09 // When a request for a URL resolves, do something with the view
10 app.populateView = function( url, view ){
11 $.when(app.sendRequest({url: url, method: 'GET'})
12 .then(function(){
13 //populate the view
14 });
15 }
16
17 // Empty a view of any content it may contain
18 app.resetView = function( view ){
19 view.html('');
20 }

That said, in the JavaScript world it's become quite common for the Mediator to
act as a messaging bus on top of the Observer-pattern. Rather than modules
calling a Publish/Subscribe implementation, they'll use a Mediator with these
capabilities built in instead. A possible implementation of this (based on work
by Ryan Florence) could look as follows:

01 var mediator = (function(){
02 // Subscribe to an event, supply a callback to be executed
03 // when that event is broadcast
04 var subscribe = function(channel, fn){
05 if (!mediator.channels[channel]) mediator.channels[channel] =
[];
06 mediator.channels[channel].push({ context: this, callback: fn
});
07 return this;
08 },
09
10 // Publish/broadcast an event to the rest of the application
11 publish = function(channel){
12 if (!mediator.channels[channel]) return false;
13 var args = Array.prototype.slice.call(arguments, 1);
14 for (var i = 0, l = mediator.channels[channel].length; i < l;
i++) {
15 var subscription = mediator.channels[channel][i];
16 subscription.callback.apply(subscription.context, args);
17 }
18 return this;
19 };
20
21 return {
22 channels: {},

34 de 184 22/03/12 11:43


23 publish: publish,
24 subscribe: subscribe,
25 installTo: function(obj){
26 obj.subscribe = subscribe;
27 obj.publish = publish;
28 }
29 };
30
31 }());

Here are two sample uses of the implementation from above. It's effectively
centralized Publish/Subscribe where a mediated implementation of the
Observer pattern is used:

01 (function( m ){
02
03 function initialize(){
04
05 // Set a default value for 'person'
06 var person = "tim";
07
08 // Subscribe to an event called 'nameChange' with
09 // a callback function which will log the original
10 // person's name and (if everything works) the new
11 // name
12
13 m.subscribe('nameChange', function( arg ){
14 console.log( person ); // tim
15 person = arg;
16 console.log( person ); // david
17 });
18 }
19
20 function updateName(){
21 // Publish/Broadcast the 'nameChange' event with the new data
22 m.publish( 'nameChange', 'david' );
23 }
24
25 })( mediator );

Advantages & Disadvantages

The benefits of the Mediator pattern are that it simplifies object interaction
and can aid with decoupling those using it as a communication hub. In the
above example, rather than using the Observer pattern to explicitly set
many-to-many listeners and events, a Mediator allows you to broadcast events
globally between subscribers and publishers. Broadcasted events can be
handled by any number of modules at once and a mediator can used for a
number of other purposes such as permissions management, given that it can
control what messages can be subscribed to and which can be broadcast.

Perhaps the biggest downside of using the Mediator pattern is that it can

35 de 184 22/03/12 11:43


introduce a single point of failure. Placing a Mediator between modules can
also cause a performance hit as they are always communicating
indirectly.Because of the nature of loose coupling, it's difficult to establish how
a system might react by only looking at the broadcasts. That said, it's useful to
remind ourselves that decoupled systems have a number of other benefits - if
our modules communicated with each other directly, changes to modules (e.g
another module throwing an exception) could easily have a domino effect on
the rest of your application. This problem is less of a concern with decoupled
systems.

At the end of the day, tight coupling causes all kinds of headaches and this is
just another alternative solution, but one which can work very well if
implemented correctly.

Mediator Vs. Observer

Developers often wonder what the differences are between the Mediator
pattern and the Observer pattern. Admittedly, there is a bit of overlap, but let's
refer back to the GoF for an explanation:

"In the Observer pattern, there is no single object that encapsulates a
constraint. Instead, the Observer and the Subject must cooperate to maintain
the constraint. Communication patterns are determined by the way observers
and subjects are interconnected: a single subject usually has many observers,
and sometimes the observer of one subject is a subject of another observer."

The Mediator pattern centralizes rather than simply just distributing. It places
the responsibility for maintaining a constraint squarely in the mediator.

Mediator Vs. Facade

We will be covering the Facade pattern shortly, but for reference purposes
some developers may also wonder whether there are similarities between the
Mediator and Facade patterns. They do both abstract the functionality of
existing modules, but there are some subtle differences.

The Mediator centralizes communication between modules where it's explicitly
referenced by these modules. In a sense this is multidirectional. The Facade
however just defines a simpler interface to a module or system but doesn't add
any additional functionality. Other modules in the system aren't directly aware
of the concept of a facade and could be considered unidirectional.

36 de 184 22/03/12 11:43


The Prototype Pattern
The GoF refer to the prototype pattern as one which creates objects based on a
template of an existing object through cloning.

We can think of the prototype pattern as being based on prototypal inheritance
where we create objects which act as prototypes for other objects. The
prototype object itself is effectively used as a blueprint for each object the
constructor creates. If the prototype of the constructor function used contains
a property called 'name' for example (as per the code sample lower down), then
each object created by that same constructor will also have this same property.

Looking at the definitions for the prototype pattern in existing literature
non-specific to JavaScript, you *may* find references to concepts outside the
scope of the language such as classes. The reality is that prototypal inheritance
avoids using classes altogether. There isn't a 'definition' object nor a core
object in theory. We're simply creating copies of existing functional objects.

One of the benefits of using the prototype pattern is that we're working with
the strengths JavaScript has to offer natively rather than attempting to imitate
features of other languages. With other design patterns, this isn't always the
case. Not only is the pattern an easy way to implement inheritance, but it can
also come with a performance boost as well: when defining a function in an
object, they're all created by reference (so all child objects point to the same
function) instead of creating their own individual copies.

For those interested, real prototypal inheritance, as defined in the ECMAScript
5 standard, requires the use of Object.create which has only become broadly
native at the time of writing. Object.create creates an object which has a
specified prototype and which optionally contains specified properties (i.e
Object.create(prototype, optionalDescriptorObjects)). We can also see this being
demonstrated in the example below:

1 // No need for capitalization as it's not a constructor
2 var someCar = {
3 drive: function() {},
4 name: 'Mazda 3'

37 de 184 22/03/12 11:43


5 };
6
7 // Use Object.create to generate a new car
8 var anotherCar = Object.create( someCar );
9 anotherCar.name = 'Toyota Camry';

Object.create allows you to easily implement advanced concepts such as
differential inheritance where objects are able to directly inherit from other
objects. With Object.create you're also able to initialise object properties using
the second supplied argument. For example:

01 var vehicle = {
02 getModel : function(){
03 console.log( 'The model of this vehicle is..' + this.model );
04 }
05 };
06
07 var car = Object.create( vehicle, {
08 'id' : {
09 value: MY_GLOBAL.nextId(),
10 enumerable: true // writable:false, configurable:false by default
11 },
12 'model':{
13 value: 'Ford',
14 enumerable: true
15 }
16 });

Here the properties can be initialized on the second argument of Object.create
using an object literal using the syntax similar to that used by the
Object.defineProperties and Object.defineProperty methods. It allows you to set
the property attributes such as enumerable, writable or configurable.

If you wish to implement the prototype pattern without directly using
Object.create, you can simulate the pattern as per the above example as
follows:

01 var vehiclePrototype = {
02 init: function( carModel ) {
03 this.model = carModel;
04 },
05 getModel: function() {
06 console.log( 'The model of this vehicle is..' + this.model );
07 }
08 };

38 de 184 22/03/12 11:43


09
10
11 function vehicle( model ) {
12 function F() {};
13 F.prototype = vehiclePrototype;
14
15 var f = new F();
16
17 f.init( model );
18 return f;
19 }
20
21 var car = vehicle( 'Ford Escort' );
22 car.getModel();

The Command Pattern
The command pattern aims to encapsulate method invocation, requests or
operations into a single object and gives you the ability to both parameterize
and pass method calls around that can be executed at your discretion. In
addition, it enables you to decouple objects invoking the action from the objects
which implement them, giving you a greater degree of overall flexibility in
swapping out concrete 'classes'.

If you haven't come across concrete classes before, they are best explained in
terms of class-based programming languages and are related to the idea of
abstract classes. An abstract class defines an interface, but doesn't necessarily
provide implementations for all of its member functions. It acts as a base class
from which others are derived. A derived class which implements the missing
functionality is called a concrete class (you may find these concepts familiar if
you're read about the Decorator or Prototype patterns).

The main idea behind the command pattern is that it provides you a means to
separate the responsibilities of issuing commands from anything executing
commands, delegating this responsibility to different objects instead.

Implementation wise, simple command objects bind together both an action
and the object wishing to invoke the action. They consistently include an
execution operation (such as run() or execute()). All command objects with the
same interface can easily be swapped as needed and this is considered one of
the larger benefits of the pattern.

39 de 184 22/03/12 11:43


To demonstrate the command pattern we're going to create a simple car
purchasing service.

01 $(function(){
02
03 var CarManager = {
04
05 // request information
06 requestInfo: function( model, id ){
07 return 'The information for ' + model +
08 ' with ID ' + id + ' is foobar';
09 },
10
11 // purchase the car
12 buyVehicle: function( model, id ){
13 return 'You have successfully purchased Item '
14 + id + ', a ' + model;
15 },
16
17 // arrange a viewing
18 arrangeViewing: function( model, id ){
19 return 'You have successfully booked a viewing of '
20 + model + ' ( ' + id + ' ) ';
21 }
22
23 };
24
25 })();

Now taking a look at the above code, we could easily execute our manager
commands by directly invoking the methods, however in some situations we
don't expect to invoke the inner methods inside the object directly.

The reason for this is that we don't want to increase the dependencies
amongst objects i.e if the core login behind the CarManager changes, all our
methods that carry out the processing with the manager have to be modified in
the mean time. This would effectively go against the OOP methodology of
loosely coupling objects as much as possible which we want to avoid.

Let's now expand on our CarManager so that our application of the command
pattern results in the following: accept any process requests from the
CarManager object where the contents of the request include the model and
car ID.

Here is what we would like to be able to achieve:

1 CarManager.execute({commandType: "buyVehicle", operand1: 'Ford Escort',
operand2: '453543'});

As per this structure we should now add a definition for the

40 de 184 22/03/12 11:43


"CarManager.execute" method as follows:

1 CarManager.execute = function( command ){
2 return CarManager[command.request](command.model,command.carID);
3 };

Our final sample calls would thus look as follows:

1 CarManager.execute({request: "arrangeViewing", model: 'Ferrari', carID:
'145523'});
2 CarManager.execute({request: "requestInfo", model: 'Ford Mondeo', carID:
'543434'});
3 CarManager.execute({request: "requestInfo", model: 'Ford Escort', carID:
'543434'});
4 CarManager.execute({request: "buyVehicle", model: 'Ford Escort', carID:
'543434'});

The DRY Pattern
Disclaimer: DRY is essentially a way of thinking and many patterns aim to
achieve a level of DRY-ness with their design. In this section we'll be covering
what it means for code to be DRY but also covering the DRY design pattern
based on these same concepts.

A challenge that developers writing large applications frequently have is
writing similar code multiple times. Sometimes this occurs because your script
or application may have multiple similar ways of performing something.
Repetitive code writing generally reduces productivity and leaves you open to
having to re-write code you’ve already written similar times before, thus
leaving you with less time to add in new functionality.

DRY (don’t repeat yourself) was created to simplify this - it’s based on the idea
that each part of your code should ideally only have one representation of each
piece of knowledge in it that applies to your system. The key concept to take
away here is that if you have code that performs a specific task, you shouldn’t
write that code multiple times through your applications or scripts.

When DRY is applied successfully, the modification of any element in the
system doesn’t change other logically-unrelated elements. Elements in your
code that are logically related change uniformly and are thus kept in sync.

As other patterns covered display aspects of DRY-ness with JavaScript, let's

41 de 184 22/03/12 11:43


take a look at how to write DRY code using jQuery. Note that where jQuery is
used, you can easily substitute selections using vanilla JavaScript because
jQuery is just JavaScript at an abstracted level.

Non-DRY

01 // Let's store some defaults about a car for reference
02 var defaultSettings = {};
03 defaultSettings['carModel'] = 'Mercedes';
04 defaultSettings['carYear'] = 2010;
05 defaultSettings['carMiles'] = 5000;
06 defaultSettings['carTint'] = 'Metallic Blue';
07
08 // Let's do something with this data if a checkbox is clicked
09 $('.someCheckbox').click(function(){
10
11 if ( this.checked ){
12
13 $('#input_carModel').val(activeSettings.carModel);
14 $('#input_carYear').val(activeSettings.carYear);
15 $('#input_carMiles').val(activeSettings.carMiles);
16 $('#input_carTint').val(activeSettings.carTint);
17
18 } else {
19
20 $('#input_carModel').val('');
21 $('#input_carYear').val('');
22 $('#input_carMiles').val('');
23 $('#input_carTint').val('');
24 }
25 });

DRY

01 $('.someCheckbox').click(function(){
02 var checked = this.checked,
03 fields = ['carModel', 'carYear', 'carMiles', 'carTint'];
04 /*
05 What are we repeating?
06 1. input_ precedes each field name
07 2. accessing the same array for settings
08 3. repeating value resets
09
10 What can we do?
11 1. programmatically generate the field names
12 2. access array by key
13 3. merge this call using terse coding (ie. if checked,
14 set a value, otherwise don't)
15 */
16 $.each(fields, function(i,key){
17 $('#input_' + key).val(checked ? defaultSettings[key] : '');
18 });

42 de 184 22/03/12 11:43


19 });

The Facade Pattern
When we put up a facade, we present an outward appearance to the world
which may conceal a very different reality. This was the inspiration for the
name behind the next pattern we're going to review - the facade pattern. The
facade pattern provides a convenient higher-level interface to a larger body of
code, hiding its true underlying complexity. Think of it as simplifying the API
being presented to other developers, something which almost always improves
usability.

Facades are a structural pattern which can often be seen in JavaScript libraries
like jQuery where, although an implementation may support methods with a
wide range of behaviors, only a 'facade' or limited abstraction of these methods
is presented to the public for use.

This allows us to interact with the facade rather than the subsystem behind
the scenes. Whenever you're using jQuery's $(el).css() or $(el).animate()
methods, you're actually using a facade - the simpler public interface that
avoids you having to manually call the many internal methods in jQuery core
required to get some behaviour working.

The facade pattern both simplifies the interface of a class and it also decouples
the class from the code that utilizes it. This gives us the ability to indirectly
interact with subsystems in a way that can sometimes be less prone to error
than accessing the subsystem directly. A facade's advantages include ease of
use and often a small size-footprint in implementing the pattern.

Let’s take a look at the pattern in action. This is an unoptimized code example,
but here we're utilizing a facade to simplify an interface for listening to events
cross-browser. We do this by creating a common method that can be used in
one’s code which does the task of checking for the existence of features so that
it can provide a safe and cross-browser compatible solution.

1 var addMyEvent = function( el,ev,fn ){
2 if(el.addEventListener){
3 el.addEventListener( ev,fn, false );
4 }else if(el.attachEvent){
5 el.attachEvent( 'on'+ ev, fn );

43 de 184 22/03/12 11:43


6 } else{
7 el['on' + ev] = fn;
8 }
9 };

In a similar manner, we're all familiar with jQuery's $(document).ready(..).
Internally, this is actually being powered by a method called bindReady(), which
is doing this:

01 bindReady: function() {
02 ...
03 if ( document.addEventListener ) {
04 // Use the handy event callback
05 document.addEventListener( "DOMContentLoaded", DOMContentLoaded,
false );
06
07 // A fallback to window.onload, that will always work
08 window.addEventListener( "load", jQuery.ready, false );
09
10 // If IE event model is used
11 } else if ( document.attachEvent ) {
12
13 document.attachEvent( "onreadystatechange", DOMContentLoaded );
14
15 // A fallback to window.onload, that will always work
16 window.attachEvent( "onload", jQuery.ready );
17 ...

This is another example of a facade, where the rest of the world simply uses
the limited interface exposed by $(document).ready(..) and the more complex
implementation powering it is kept hidden from sight.

Facades don't just have to be used on their own, however. They can also be
integrated with other patterns such as the module pattern. As you can see
below, our instance of the module patterns contains a number of methods
which have been privately defined. A facade is then used to supply a much
simpler API to accessing these methods:

01 var module = (function() {
02 var _private = {
03 i:5,
04 get : function() {
05 console.log('current value:' + this.i);
06 },
07 set : function( val ) {
08 this.i = val;
09 },
10 run : function() {
11 console.log( 'running' );
12 },
13 jump: function(){
14 console.log( 'jumping' );
15 }

44 de 184 22/03/12 11:43


16 };
17 return {
18 facade : function( args ) {
19 _private.set(args.val);
20 _private.get();
21 if ( args.run ) {
22 _private.run();
23 }
24 }
25 }
26 }());
27
28
29 module.facade({run: true, val:10});
30 //outputs current value: 10, running

In this example, calling module.facade() will actually trigger a set of private
behaviour within the module, but again, the user isn't concerned with this.
We've made it much easier for them to consume a feature without needing to
worry about implementation-level details.

The Factory Pattern
Similar to other creational patterns, the Factory Pattern deals with the problem
of creating objects (which we can think of as ‘factory products’) without the
need to specify the exact class of object being created.

Specifically, the Factory Pattern suggests defining an interface for creating an
object where you allow the subclasses to decide which class to instantiate. This
pattern handles the problem by defining a completely separate method for the
creation of objects and which sub-classes are able to override so they can
specify the ‘type’ of factory product that will be created.

This can come in quite useful, in particular if the creation process involved is
quite complex. eg. if it strongly depends on the settings in configuration files.

You can often find factory methods in frameworks where the code for a library
may need to create objects of particular types which may be subclassed by
scripts using the frameworks.

In our example, let’s take the code used in the original Constructor pattern
example and see what this would look like were we to optimize it using the
Factory Pattern:

45 de 184 22/03/12 11:43


01 var Car = (function() {
02 var Car = function ( model, year, miles ){
06 };
07
08 return function ( model, year, miles ) {
09 return new Car( model, year, miles );
10 };
11
12 })();
13
14 var civic = Car( "Honda Civic", 2009, 20000 );
15 var mondeo = Car("Ford Mondeo", 2010, 5000 );
16
17 /*
18 These are also valid:
19 var civic = new Car( "Honda Civic", 2009, 20000 );
20 var mondeo = new Car( "Ford Mondeo", 2010, 5000 );
21 */

When To Use This Pattern

The Factory pattern can be especially useful when applied to the following
situations:

When your object's setup requires a high level of complexity
When you need to generate different instances depending on the environment
When you're working with many small objects that share the same properties

When Not To Use This Pattern

It's generally a good practice to not use the factory pattern in every situation as
it can easily add an unnecessarily additional aspect of complexity to your code.
It can also make some tests more difficult to run.

The Mixin Pattern
In traditional object-oriented programming languages, mixins are classes

46 de 184 22/03/12 11:43


which provide the functionality to be inherited by a subclass. Inheriting from
mixins are a means of collecting functionality and classes may inherit
functionality from multiple mixins through multiple inheritance.

In the following example, we have a Car defined without any methods. We also
have a constructor called 'Mixin'. What we're going to do is augment the Car
so it has access to the methods within the Mixin.This code demonstrates how
with JavaScript you can augment a constructor to have a particular method
without using the typical inheritance methods or duplicating code for each
constructor function you have.

01 // Car
02 var Car = function( settings ){
03 this.model = settings.model || 'no model provided';
04 this.colour = settings.colour || 'no colour provided';
05 };
06
07 // Mixin
08 var Mixin = function(){};
09 Mixin.prototype = {
10 driveForward: function(){
11 console.log('drive forward');
12 },
13 driveBackward: function(){
14 console.log('drive backward');
15 }
16 };
17
18
19 // Augment existing 'class' with a method from another
20 function augment( receivingClass, givingClass ) {
21 // only provide certain methods
22 if ( arguments[2] ) {
23 for (var i=2, len=arguments.length; i<len; i++) {
24 receivingClass.prototype[arguments[i]] =
givingClass.prototype[arguments[i]];
25 }
26 }
27 // provide all methods
28 else {
29 for ( var methodName in givingClass.prototype ) {
30 /* check to make sure the receiving class doesn't
31 have a method of the same name as the one currently
32 being processed */
33 if ( !receivingClass.prototype[methodName] ) {
34 receivingClass.prototype[methodName] =
givingClass.prototype[methodName];
35 }
36 }
37 }
38 }
39
40
41 // Augment the Car have the methods 'driveForward' and 'driveBackward'*/

47 de 184 22/03/12 11:43


42 augment( Car, Mixin,'driveForward','driveBackward' );
43
44 // Create a new Car
45 var vehicle = new Car({model:'Ford Escort', colour:'blue'});
46
47 // Test to make sure we now have access to the methods
48 vehicle.driveForward();
49 vehicle.driveBackward();

The Decorator Pattern
The Decorator pattern is an alternative to creating subclasses. This pattern can
be used to wrap objects within another object of the same interface and allows
you to both add behaviour to methods and also pass the method call to the
original object (i.e the constructor of the decorator).

The decorator pattern is often used when you need to keep adding new
functionality to overridden methods. This can be achieved by stacking multiple
decorators on top of one another.

What is the main benefit of using a decorator pattern? Well, if we examine our
ﬁrst definition, we mentioned that decorators are an alternative to subclassing.
When a script is being run, subclassing adds behaviour that affects all the
instances of the original class, whilst decorating does not. It instead can add
new behaviour for individual objects, which can be of benefit depending on the
application in question. Let’s take a look at some code that implements the
decorator pattern:

01 // This is the 'class' we're going to decorate
02 function Macbook(){
03 this.cost = function(){
04 return 1000;
05 };
06 }
07
08 function Memory( macbook ){
10 return macbook.cost() + 75;
11 };
12 }
13
14 function BlurayDrive( macbook ){
17 };
18 }

48 de 184 22/03/12 11:43


19
20
21 function Insurance( macbook ){
24 };
25 }
26
27
28 // Sample usage
29 var myMacbook = new Insurance(new BlurayDrive(new Memory(new Macbook())));
30 console.log( myMacbook.cost() );

Here's another decorator example where when we invoke performTask on the
decorator object, it both performs some behaviour and invokes performTask on
the underlying object.

01 function ConcreteClass(){
02 this.performTask = function(){
03 this.preTask();
04 console.log('doing something');
05 this.postTask();
06 };
07 }
08
09 function AbstractDecorator( decorated ){
10 this.performTask = function()
11 {
12 decorated.performTask();
13 };
14 }
15
16 function ConcreteDecoratorClass( decorated ){
17 this.base = AbstractDecorator;
18 this.base(decorated);
19
20 this.preTask = function(){
21 console.log('pre-calling..');
22 };
23
24 this.postTask = function(){
25 console.log('post-calling..');
26 };
27
28 }
29
30 var concrete = new ConcreteClass();
31 var decorator1 = new ConcreteDecoratorClass(concrete);
32 var decorator2 = new ConcreteDecoratorClass(decorator1);
33 decorator2.performTask();

49 de 184 22/03/12 11:43


Patterns In Greater Detail

As a beginner, you should hopefully now have a basic understanding of many
of the commonly used design patterns in JavaScript (as well as some which are
less frequently implemented). In this next section, we're going to explore a
selection of the patterns we've already reviewed in greater detail.

The Observer (Pub/Sub) pattern

As we saw earlier in the book, the general idea behind the Observer pattern is
the promotion of loose coupling. Rather than single objects calling on the
methods of other objects directly, they instead subscribes to a specific task or
activity of another object and are notified when it occurs. Observers are also
called Subscribers and we refer to the object being observed as the Publisher
(or the subject). Publishers notify subscribers when events occur.

When objects are no longer interested in being notified by the subject they are
registered with, they can unregister (or unsubscribe) themselves. The subject
will then in turn remove them from the observer collection.

It's often useful to refer back to published definitions of design patterns that
are language agnostic to get a broader sense of their usage and advantages
over time. The definition of the observer pattern provided in the GoF book,
Design Patterns: Elements of Reusable Object-Oriented Software, is:

'One or more observers are interested in the state of a subject and register
their interest with the subject by attaching themselves. When something
changes in our subject that the observer may be interested in, a notify
message is sent which calls the update method in each observer. When the
observer is no longer interested in the subject's state, they can simply detach
themselves.'

50 de 184 22/03/12 11:43


Basically, the pattern describes subjects and observers forming a publish-
subscribe relationship. Unlimited numbers of objects may observe events in
the subject by registering themselves. Once registered to particular events, the
subject will notify all observers when the event has been fired.

Advantages
Arguably, the largest benefit of using pub/sub is the ability to break down our
applications into smaller, more loosely coupled modules, which can also
improve general manageability.

Pub/sub is also a pattern that encourages us to think hard about the
relationships between different parts of your application, identifying what
layers need to observe or listen for behaviour and which need to push
notifications regarding behaviour occurring to other parts of our apps.

Whilst it may not always be the best solution to every problem, it remains one
of the best tools for designing decoupled systems and should be considered an
important tool in any JavaScript developer's utility belt.

Disadvantages
Consequently, some of the issues with the pub/sub pattern actually stem from
its main benefit. By decoupling publishers from subscribers, it can sometimes
become difficult to obtain guarantees that particular parts of our applications
are functioning as we may expect.

For example, publishers may make an assumption that one or more
subscribers are listening to them. Say that we're using such an assumption to
log or output errors regarding some application process. If the subscriber
performing the logging crashes (or for some reason fails to function), the
publisher won't have a way of seeing this due to the decoupled nature of the
system.

Implementations
One of the benefits of design patterns is that once we understand the basics
behind how a particular pattern works, being able to interpret an
implementation of it becomes significantly more straightforward. Luckily,
popular JavaScript libraries such as dojo and YUI already have utilities that can
assist in easily implementing your own pub/sub system.

51 de 184 22/03/12 11:43


For those wishing to use the pub/sub pattern with vanilla JavaScript (or
another library) AmplifyJS includes a clean, library-agnostic implementation of
pub/sub that can be used with any library or toolkit. ScriptJunkie also has a
tutorial on how to get started with Amplify's pub/sub that was recently
published. You can of course also write your own implementation from scratch
or also check out either PubSubJS or OpenAjaxHub, both of which are also
library-agnostic.

jQuery developers have quite a few options for pub/sub (in addition to Amplify)
and can opt to use one of the many well-developed implementations ranging
from Peter Higgins's jQuery plugin to Ben Alman's (optimized) gist on GitHub.
Links to just a few of these can be found below.

Ben Alman's Pub/Sub gist https://gist.github.com/661855 (recommended)
Rick Waldron's jQuery-core style take on the above https://gist.github.com
/705311
Peter Higgins' plugin http://github.com/phiggins42/bloody-jquery-plugins
/blob/master/pubsub.js.
AppendTo's Pub/Sub in AmplifyJS http://amplifyjs.com
Ben Truyman's gist https://gist.github.com/826794

Tutorial
So that we are able to get an appreciation for how many of the vanilla
JavaScript implementations of the Observer pattern might work, let's take a
walk through of a trimmed down version of Morgan Roderick's PubSubJS,
which I've put together below. This demonstrates the core concepts of
subscribe, publish as well as the concept of unsubscribing.

I've opted to base our examples on this code as it sticks closely to both the
method signatures and approach of implementation I would expect to see in a
JavaScript version of the original observer pattern.

Sample Pub/Sub implementation
01 var PubSub = {};
02
03 (function(p){
04
05 "use strict";
06 var topics = {},
07 lastUid = -1;

52 de 184 22/03/12 11:43


08
09
10 var publish = function( topic , data){
11
12 if ( !topics.hasOwnProperty( topic ) ){
13 return false;
14 }
15
16
17 var notify = function(){
18 var subscribers = topics[topic],
19 throwException = function(e){
20 return function(){
21 throw e;
22 };
23
24 };
25
26 for ( var i = 0, j = subscribers.length; i < j; i++ ){
27 try {
28 subscribers[i].func( topic, data );
29 } catch( e ){
30
31 setTimeout( throwException(e), 0);
32 }
33 }
34 };
35
36 setTimeout( notify , 0 );
37 return true;
38 };
39
40
41
42 /**
43 * Publishes the topic, passing the data to it's subscribers
44 * @topic (String): The topic to publish
45 * @data: The data to pass to subscribers
46 **/
47
48 p.publish = function( topic, data ){
49 return publish( topic, data, false );
50 };
51
52
53 /**
54 * Subscribes the passed function to the passed topic.
55 * Every returned token is unique and should be stored if you need
to unsubscribe
56 * @topic (String): The topic to subscribe to
57 * @func (Function): The function to call when a new topic is
published
58 **/
59
60 p.subscribe = function( topic, func ){
61
62 // topic is not registered yet
63 if ( !topics.hasOwnProperty( topic ) ){
64 topics[topic] = [];

53 de 184 22/03/12 11:43


65 }
66
67 var token = (++lastUid).toString();
68 topics[topic].push( { token : token, func : func } );
69
70 // return token for unsubscribing
71 return token;
72
73 };
74
75 /**
76 * Unsubscribes a specific subscriber from a specific topic using
the unique token
77 * @token (String): The token of the function to unsubscribe
78 **/
79
80 p.unsubscribe = function( token ){
81
82 for ( var m in topics ){
83 if ( topics.hasOwnProperty( m ) ){
84 for ( var i = 0, j = topics[m].length; i < j; i++ ){
85 if ( topics[m][i].token === token ){
86 topics[m].splice( i, 1 );
87 return token;
88 }
89 }
90 }
91 }
92 return false;
93 };
94 });

Example 1: Basic use of publishers and subscribers

This could then be easily used as follows:

01 // a sample subscriber (or observer)
02
03 var testSubscriber = function( topics , data ){
04 console.log( topics + ": " + data );
05
06 };
07
08
09
10 // add the function to the list of subscribers to a particular topic
11 // maintain the token (subscription instance) to enable unsubscription
later
12
13 var testSubscription = PubSub.subscribe( 'example1', testSubscriber );
14
15
16
17 // publish a topic or message asyncronously
18
19 PubSub.publish( 'example1', 'hello scriptjunkie!' );
20

54 de 184 22/03/12 11:43


21 PubSub.publish( 'example1', ['test','a','b','c'] );
22
23 PubSub.publish( 'example1', [{'color':'blue'},{'text':'hello'}] );
24
25
26
27 // unsubscribe from further topics
29 PubSub.unsubscribe( testSubscription );
30 }, 0);
31
32
33
34 // test that we've fully unsubscribed
35 PubSub.publish( 'example1', 'hello again!');

Real-time stock market application

Next, let's imagine we have a web application responsible for displaying
real-time stock information.

The application might have a grid for displaying the stock stats and a counter
for displaying the last point of update, as well as an underlying data model.
When the data model changes, the application will need to update the grid and
counter. In this scenario, our subject is the data model and the observers are
the grid and counter.

When the observers receive notification that the model itself has changed, they
can update themselves accordingly.

Example 2: UI notifications using pub/sub

In the following example, we limit our usage of pub/sub to that of a notification
system. Our subscriber is listening to the topic 'dataUpdated' to find out when
new stock information is available. It then triggers 'gridUpdate' which goes on
to call hypothetical methods that pull in the latest cached data object and
re-render our UI components.

Note: the Mediator pattern is occasionally used to provide a level of
communication between UI components without requiring that they
communicate with each other directly. For example, rather than tightly
coupling our applications, we can have widgets/components publish a topic
when something interesting happens. A mediator can then subscribe to that
topic and call the relevant methods on other components.

01 var grid = {
02

55 de 184 22/03/12 11:43


03 refreshData: function(){
04 console.log('retrieved latest data from data cache');
05 console.log('updated grid component');
06 },
07
08 updateCounter: function(){
09 console.log('data last updated at: ' + getCurrentTime());
10 }
11
12 };
13
14
15
16 //a very basic mediator
17
18 var gridUpdate = function(topics, data){
19 grid.refreshData();
20 grid.updateCounter();
21 }
22
23
24 var dataSubscription = PubSub.subscribe( 'dataUpdated', gridUpdate );
25 PubSub.publish( 'dataUpdated', 'new stock data available!' );
26 PubSub.publish( 'dataUpdated', 'new stock data available!' );
27
28
29 function getCurrentTime(){
30
31 var date = new Date(),
32 m = date.getMonth() + 1,
33 d = date.getDate(),
34 y = date.getFullYear(),
35 t = date.toLocaleTimeString().toLowerCase(),
36 return (m + '/' + d + '/' + y + ' ' + t);
37
38 }

Whilst there's nothing terribly wrong with this, there are more optimal ways
that we can utilize pub/sub to our advantage.

Example 3: Taking notifications further

Rather than just notifying our subscribers that new data is available, why not
actually push the new data through to gridUpdate when we publish a new
notification from a publisher. In this next example, our publisher will notify
subscribers with the actual data that's been updated as well as a timestamp
from the data-source of when the new data was added.

In addition to avoiding data having to be read from a cached store, this also
avoids client-side calculation of the current time whenever a new data entry
gets published.

01 var grid = {

56 de 184 22/03/12 11:43


02
03 addEntry: function(data){
04
05 if (data !== 'undefined') {
06
07 console.log('Entry:'
08
09 + data.title
10
11 + ' Changenet / %'
12
13 + data.changenet
14
15 + '/' + data.percentage + ' % added');
16
17 }
18
19 },
20
21 updateCounter: function(timestamp){
22 console.log('grid last updated at: ' + timestamp);
23 }
24 };
25
26
27
28 var gridUpdate = function(topics, data){
29 grid.addEntry(data);
30 grid.updateCounter(data.timestamp);
31 }
32
33
34
35 var gridSubscription = PubSub.subscribe( 'dataUpdated', gridUpdate );
36
37 PubSub.publish('dataUpdated', { title: "Microsoft shares", changenet:
4, percentage: 33, timestamp: '17:34:12' });
38
39 PubSub.publish('dataUpdated', { title: "Dell shares", changenet: 10,
percentage: 20, timestamp: '17:35:16' });

Example 4: Decoupling applications using Ben Alman's
pub/sub implementation

In the following movie ratings example, we'll be using Ben Alman's jQuery
implementation of pub/sub to demonstrate how we can decouple a user
interface. Notice how submitting a rating only has the effect of publishing the
fact that new user and rating data is available.

It's left up to the subscribers to those topics to then delegate what happens
with that data. In our case we're pushing that new data into existing arrays and
then rendering them using the jQuery.tmpl plugin.

57 de 184 22/03/12 11:43


HTML/Templates

01 <script id="userTemplate" type="text/x-jquery-tmpl">
02 <li>${user}
03 </script>
04
05
06 <script id="ratingsTemplate" type="text/x-jquery-tmpl">
07 <li><strong>${movie}</strong> was rated ${rating}/5
08 </script>
09
10
11 <div id="container">
12
13 <div class="sampleForm">
14 <p>
15 <label for="twitter_handle">Twitter handle:</label>
16 <input type="text" id="twitter_handle" />
17 </p>
18 <p>
19 <label for="movie_seen">Name a movie you've seen this
year:</label>
20 <input type="text" id="movie_seen" />
21 </p>
22 <p>
23
24 <label for="movie_rating">Rate the movie you saw:</label>
25 <select id="movie_rating">
26 <option value="1">1</option>
30 <option value="5"ected>5</option>
31
32 </select>
33 </p>
34 <p>
35
36 <button id="add">Submit rating</button>
37 </p>
38 </div>
39
40
41
42 <div class="summaryTable">
43 <div id="users"><h3>Recent users</h3></div>
44 <div id="ratings"><h3>Recent movies rated</h3></div>
45 </div>
46
47 </div>

JavaScript

01 (function($) {
02
03
04 var movieList = [],
05 userList = [];

58 de 184 22/03/12 11:43


06
07
08
09 /* subscribers */
10
11 $.subscribe( "/new/user", function( e, userName ){
12
13 if(userName.length){
14 userList.push({user: userName});
15 $( "#userTemplate" ).tmpl( userList[userList.length - 1]
).appendTo( "#users" );
16 }
17
18 });
19
20
21
22 $.subscribe( "/new/rating", function( e, movieTitle, userRating ){
23
24 if(movieTitle.length){
25 movieList.push({ movie: movieTitle, rating: userRating});
26 $( "#ratingsTemplate" ).tmpl( movieList[movieList.length - 1]
).appendTo( "#ratings" );
27 }
28
29 });
30
31
32
33 $('#add').bind('click', function(){
34
35 var strUser = $("#twitter_handle").val(),
36 strMovie = $("#movie_seen").val(),
37 strRating = $("#movie_rating").val();
38
39 $.publish('/new/user', strUser );
40 $.publish('/new/rating', [ strMovie, strRating] );
41
42 });
43
44 })(jQuery);

Example 5: Decoupling an Ajax-based jQuery application

In our final example, we're going to take a practical look at how decoupling our
code using pub/sub early on in the development process can save us some
potentially painful refactoring later on. This is something Rebecca Murphey
touched on in her pub/sub screencast and is another reason why pub/sub is
favoured by so many developers in the community.

Quite often in Ajax-heavy applications, once we've received a response to a
request we want to achieve more than just one unique action. One could
simply add all of their post-request logic into a success callback, but there are

59 de 184 22/03/12 11:43


drawbacks to this approach.

Highly coupled applications sometimes increase the effort required to reuse
functionality due to the increased inter-function/code dependency. What this
means is that although keeping our post-request logic hardcoded in a callback
might be fine if we're just trying to grab a result set once, it's not as
appropriate when we want to make further Ajax-calls to the same data source
(and different end-behaviour) without rewriting parts of the code multiple
times. Rather than having to go back through each layer that calls the same
data-source and generalizing them later on, we can use pub/sub from the start
and save time.

Using pub/sub, we can also easily separate application-wide notifications
regarding different events down to whatever level of granularity you're
comfortable with, something which can be less elegantly done using other
patterns.

Notice how in our sample below, one topic notification is made when a user
indicates they want to make a search query and another is made when the
request returns and actual data is available for consumption. It's left up to the
subscribers to then decide how to use knowledge of these events (or the data
returned). The benefits of this are that, if we wanted, we could have 10
different subscribers utilizing the data returned in different ways but as far as
the Ajax-layer is concerned, it doesn't care. Its sole duty is to request and
return data then pass it on to whoever wants to use it. This separation of
concerns can make the overall design of your code a little cleaner.

HTML/Templates:

01 <form id="flickrSearch">
02
03 <input type="text" name="tag" id="query"/>
04
05 <input type="submit" name="submit" value="submit"/>
06
07 </form>
08
09
10
11 <div id="lastQuery"></div>
12
13 <div id="searchResults"></div>
14
15
16
17 <script id="resultTemplate" type="text/x-jquery-tmpl">
18 {{each(i, items) items}}

60 de 184 22/03/12 11:43


19 <li><p><img src="${items.media.m}"/></p></li>
20 {{/each}}
21 </script>

JAVASCRIPT:

01 (function($) {
02
03 $('#flickrSearch').submit(function( e ){
04
05 e.preventDefault();
06 var tags = $(this).find('#query').val();
07
08 if(!tags){return;}
09 $.publish('/search/tags', [ $.trim(tags) ]);
10
11 });
12
13
14
15 $.subscribe('/search/tags', function(tags){
16
17 $.getJSON('http://api.flickr.com/services/feeds
/photos_public.gne?jsoncallback=?',
18 { tags: tags, tagmode: 'any', format: 'json'},
19
20 function(data){
21 if(!data.items.length){ return; }
22 $.publish('/search/resultSet', [ data ]);
23 });
24
25 });
26
27
28
29 $.subscribe('/search/tags', function(tags){
30 $('#searchResults').html('<p>Searched for:<strong>' + tags +
'</strong></p>');
31 });
32
33
34 $.subscribe('/search/resultSet', function(results){
35
36 var holder = $('#searchResults');
37 holder.html();
38 $('#resultTemplate').tmpl(results).appendTo(holder);
39
40 });
41
42
43 });

The Observer pattern is useful for decoupling a number of different scenarios
in application design and if you haven't been using it, I recommend picking up
one of the pre-written implementations mentioned today and just giving it a try
out. It's one of the easier design patterns to get started with but also one of the

61 de 184 22/03/12 11:43


most powerful.

MVC And MVP

In this section, we're going to review two very important architectural patterns
- MVC (Model-View-Controller) and MVP (Model-View-Presenter). In the past
both of these patterns have been heavily used for structuring desktop and
server-side applications, but it's only been in recent years that come to being
applied to JavaScript.

As the majority of JavaScript developers currently using these patterns opt to
utilize libraries such as Backbone.js for implementing an MVC/MV*-like
structure, we will compare how modern solutions such as it differ in their
interpretation of MVC compared to classical takes on these patterns.

Let us first now cover the basics.

MVC
MVC is an architectural design pattern that encourages improved application
organization through a separation of concerns. It enforces the isolation of
business data (Models) from user interfaces (Views), with a third component
(Controllers) (traditionally) managing logic, user-input and coordinating both
the models and views. The pattern was originally designed by Trygve
Reenskaug during his time working on Smalltalk-80 (1979) where it was
initially called Model-View-Controller-Editor. MVC went on to be described in
depth in “Design Patterns: Elements of Reusable Object-Oriented Software”
(The "GoF" book) in 1994, which played a role in popularizing its use.

Smalltalk-80 MVC

It's important to understand what the original MVC pattern was aiming to
solve as it's mutated quite heavily since the days of it's origin. Back in the 70's,
graphical user-interfaces were far and few between and a concept known as
Separated Presentation began to be used as a means to make a clear division
between domain objects which modelled concepts in the real world (e.g a
photo, a person) and the presentation objects which were rendered to the
user's screen.

62 de 184 22/03/12 11:43


The Smalltalk-80 implementaion of MVC took this concept further and had an
objective of separating out the application logic from the user interface. The
idea was that decoupling these parts of the application would also allow the
reuse of models for other interfaces in the application. There are some
interesting points worth noting about Smalltalk-80's MVC architecture:

A Domain element was known as a Model and were ignorant of the
user-interface (Views and Controllers)
Presentation was taken care of by the View and the Controller, but there
wasn't just a single view and controller. A View-Controller pair was required for
each element being displayed on the screen and so there was no true
separation between them
The Controller's role in this pair was handling user input (such as key-presses
and click events), doing something sensible with them.
The Observer pattern was relied upon for updating the View whenever the
Model changed
Developers are sometimes surprised when they learn that the Observer
pattern (nowadays commonly implemented as a Publish/Subscribe system) was
included as a part of MVC's architecture many decades ago. In Smalltalk-80's
MVC, the View and Controller both observe the Model. As mentioned in the
bullet point above, anytime the Model changes, the Views react. A simple
example of this is an application backed by stock market data - in order for the
application to be useful, any change to the data in our Models should result in
the View being refreshed instantly.

Martin Fowler has done an excellent job of writing about the origins of MVC
over the years and if you are interested in some further historical information
about Smalltalk-80's MVC, I recommend reading his work.

MVC For JavaScript Developers
We've reviewed the 70's, but let us now return to the here and now. In modern
times, the MVC pattern has been applied to a diverse range of programming
languages including of most relevance to us: JavaScript. JavaScript now has a
number of frameworks boasting support for MVC (or variations on it, which we
refer to as the MV* family), allowing developers to easily add structure to their
applications without great effort. You've likely come across at least one of
these such frameworks, but they include the likes of Backbone, Ember.js and
JavaScriptMVC. Given the importance of avoiding "spaghetti" code, a term
which describes code that is very difficult to read or maintain due to its lack of

63 de 184 22/03/12 11:43


structure, it's imperative that the modern JavaScript developer understand
what this pattern provides. This allows us to effectively appreciate what these
frameworks enable us to do differently.

We know that MVC is composed of three core components:

Models

Models manage the data for an application. They are concerned with neither
the user-interface nor presentation layers but instead represent unique forms
of data that an application may require. When a model changes (e.g when it is
updated), it will typically notify its observers (e.g views, a concept we will cover
shortly) that a change has occurred so that they may react accordingly.

To understand models further, let us imagine we have a JavaScript photo
gallery application. In a photo gallery, the concept of a photo would merit its
own model as it represents a unique kind of domain-specific data. Such a
model may contain related attributes such as a caption, image source and
additional meta-data. A specific photo would be stored in an instance of a
model and a model may also be reusable. Below we can see an example of a
very simplistic model implemented using Backbone.

01 var Photo = Backbone.Model.extend({
02
03 // Default attributes for the photo
04 defaults: {
05 src: "placeholder.jpg",
06 caption: "A default image",
07 viewed: false
08 },
09
10 // Ensure that each photo created has an `src`.
11 initialize: function() {
12 this.set({"src": this.defaults.src});
13 }
14
15 });

The built-in capabilities of models vary across frameworks, however it is quite
common for them to support validation of attributes, where attributes
represent the properties of the model, such as a model identifier. When using
models in real-world applications we generally also desire model persistence.
Persistence allows us to edit and update models with the knowledge that its
most recent state will be saved in either: memory, in a user's localStorage
data-store or synchronized with a database.

64 de 184 22/03/12 11:43


In addition, a model may also have multiple views observing it. If say, our photo
model contained meta-data such as its location (longitude and latitude), friends
that were present in the a photo (a list of identifiers) and a list of tags, a
developer may decide to provide a single view to display each of these three
facets.

It is not uncommon for modern MVC/MV* frameworks to provide a means to
group models together (e.g in Backbone, these groups are referred to as
"collections"). Managing models in groups allows us to write application logic
based on notifications from the group should any model it contains be
changed. This avoids the need to manually observe individual model instances.

A sample grouping of models into a simplified Backbone collection can be seen
below.

01 var PhotoGallery = Backbone.Collection.extend({
02
03 // Reference to this collection's model.
04 model: Photo,
05
06 // Filter down the list of all photos
07 // that have been viewed
08 viewed: function() {
09 return this.filter(function( photo ){
10 return photo.get('viewed');
11 });
12 },
13
14 // Filter down the list to only photos that
15 // have not yet been viewed
16 unviewed: function() {
17 return this.without.apply( this, this.viewed() );
18 }
19
20 });

Should you read any of the older texts on MVC, you may come across a
description of models as also managing application 'state'. In JavaScript
applications "state" has a different meaning, typically referring to the current
"state" i.e view or sub-view (with specific data) on a users screen at a fixed
point. State is a topic which is regularly discussed when looking at Single-page
applications, where the concept of state needs to be simulated.

So to summarize, models are primarily concerned with business data.

Views

Views are a visual representation of models that present a filtered view of their

65 de 184 22/03/12 11:43


current state. A view typically observes a model and is notified when the model
changes, allowing the view to update itself accordingly. Design pattern
literature commonly refers to views as 'dumb' given that their knowledge of
models and controllers in an application is limited.

Users are able to interact with views and this includes the ability to read and
edit (i.e get or set the attribute values in) models. As the view is the
presentation layer, we generally present the ability to edit and update in a
user-friendly fashion. For example, in the former photo gallery application we
discussed earlier, model editing could be facilitated through an "edit" view
where a user who has selected a specific photo could edit its meta-data.

The actual task of updating the model falls to controllers (which we'll be
covering shortly).

Let's explore views a little further using a vanilla JavaScript sample
implementation. Below we can see a function that creates a single Photo view,
consuming both a model instance and a controller instance.

We define a render() utility within our view which is responsible for rendering
the contents of the photoModel using a JavaScript templating engine (Underscore
templating) and updating the contents of our view, referenced by photoEl.

The photoModel then adds our render() callback as one of it's subscribers so that
through the Observer pattern we can trigger the view to update when the
model changes.

You may wonder where user-interaction comes into play here. When users
click on any elements within the view, it's not the view's responsibility to know
what to do next. It relies on a controller to make this decision for it. In our
sample implementation, this is achieved by adding an event listener to photoEl
which will delegate handling the click behaviour back to the controller, passing
the model information along with it in case it's needed.

The benefit of this architecture is that each component plays it's own separate
role in making the application function as needed.

01 var buildPhotoView = function( photoModel, photoController ){
02
03 var base = document.createElement('div'),
04 photoEl = document.createElement('div');
05
06 base.appendChild(photoEl);

66 de 184 22/03/12 11:43


07
08 var render= function(){
09 // We use a templating library such as Underscore
10 // templating which generates the HTML for our
11 // photo entry
12 photoEl.innerHTML = _.template('photoTemplate',
13 {src: photoModel.getSrc()});
14 }
15
16 photoModel.addSubscriber( render );
17
18 photoEl.addEventListener('click', function(){
19 photoController.handleEvent('click', photoModel );
20 });
21
22 var show = function(){
23 photoEl.style.display = '';
24 }
25
26 var hide = function(){
27 photoEl.style.display = 'none';
28 }
29
30
31 return{
32 showView: show,
33 hideView: hide
34 }
35
36 }

Templating

In the context of JavaScript frameworks that support MVC/MV*, it is worth
briefly discussing JavaScript templating and its relationship to views as we
briefly touched upon it in the last section.

It has long been considered (and proven) a performance bad practice to
manually create large blocks of HTML markup in-memory through string
concatenation. Developers doing so have fallen prey to inperformantly iterating
through their data, wrapping it in nested divs and using outdated techniques
such as document.write to inject the 'template' into the DOM. As this typically
means keeping scripted markup inline with your standard markup, it can
quickly become both difficult to read and more importantly, maintain such
disasters, especially when building non-trivially sized applications.

JavaScript templating solutions (such as Handlebars.js and Mustache) are
often used to define templates for views as markup (either stored externally or
within script tags with a custom type - e.g text/template) containing template
variables. Variables may be deliminated using a variable syntax (e.g {{name}})

67 de 184 22/03/12 11:43


and frameworks are typically smart enough to accept data in a JSON form (of
which model instances can be converted to) such that we only need be
concerned with maintaining clean models and clean templates. Most of the
grunt work to do with population is taken care of by the framework itself. This
has a large number of benefits, particularly when opting to store templates
externally as this can give way to templates being dynamically loaded on an
as-needed basis when it comes to building larger applications.

Below we can see two examples of HTML templates. One implemented using
the popular Handlebars.js framework and another using Underscore's
templates.

Handlebars.js:

1 <li class="photo">
2 <h2>{{caption}}</h2>
3 <img class="source" src="{{src}}"/>
4 <div class="meta-data">
5 {{metadata}}
6 </div>
7 </li>

Underscore.js Microtemplates:

1 <li class="photo">
2 <h2><%= caption %></h2>
3 <img class="source" src="<%= src %>"/>
4 <div class="meta-data">
5 <%= metadata %>
6 </div>
7 </li>

It is also worth noting that in classical web development, navigating between
independent views required the use of a page refresh. In Single-page
JavaScript applications however, once data is fetched from a server via Ajax, it
can simply be dynamically rendered in a new view within the same page
without any such refresh being necessary. The role of navigation thus falls to a
"router", which assists in managing application state (e.g allowing users to
bookmark a particular view they have navigated to). As routers are however
neither a part of MVC nor present in every MVC-like framework, I will not be
going into them in greater detail in this section.

To summarize, views are a visual representation of our application data.

Controllers

68 de 184 22/03/12 11:43


Controllers are an intermediary between models and views which are
classically responsible for two tasks: they both update the view when the model
changes and update the model when the user manipulates the view.

In our photo gallery application, a controller would be responsible for handling
changes the user made to the edit view for a particular photo, updating a
specific photo model when a user has finished editing.

In terms of where most JavaScript MVC frameworks detract from what is
conventionally considered "MVC" however, it is with controllers. The reasons
for this vary, but in my honest opinion it is that framework authors initially look
at the server-side interpretation of MVC, realize that it doesn't translate 1:1 on
the client-side and re-interpret the C in MVC to mean something they feel
makes more sense. The issue with this however is that it is subjective,
increases the complexity in both understanding the classical MVC pattern and
of course the role of controllers in modern frameworks.

As an example, let's briefly review the architecture of the popular architectural
framework Backbone.js. Backbone contains models and views (somewhat
similar to what we reviewed earlier), however it doesn't actually have true
controllers. Its views and routers act a little similar to a controller, but neither
are actually controllers on their own.

In this respect, contrary to what might be mentioned in the official
documentation or in blog posts, Backbone is neither a truly MVC/MVP nor
MVVM framework. It's in fact better to consider it a member of the MV* family
which approaches architecture in its own way. There is of course nothing
wrong with this, but it is important to distinguish between classical MVC and
MV* should you be relying on advice from classical literature on the former to
help with the latter.

Controllers in another library (Spine.js) vs Backbone.js

Spine.js

We now know that controllers are traditionally responsible for updating the
view when the model changes (and similarly the model when the user updates
the view). As the framework we'll be discussing in this book (Backbone)
doesn't have it's own explicit controllers, it can be useful for us to review the
controller from another MVC framework to appreciate the difference in
implementations. For this, let's take a look at a sample controller from

69 de 184 22/03/12 11:43


Spine.js:

In this example, we're going to have a controller called `PhotosController which
will be in charge of individual photos in the application. It will ensure that
when the view updates (e.g a user editd the photo meta-data) the corresonding
model does too.

Note: We won't be delving heavily into Spine.js at all, but will just take a
ten-foot view of what it's controllers can do:

01 // Controllers in Spine are created by inheriting from Spine.Controller
02
03 var PhotosController = Spine.Controller.sub({
04 init: function(){
05 this.item.bind("update", this.proxy(this.render));
06 this.item.bind("destroy", this.proxy(this.remove));
07 },
08
09 render: function(){
10 // Handle templating
11 this.replace($("#photoTemplate").tmpl(this.item));
12 return this;
13 },
14
15 remove: function(){
16 this.el.remove();
17 this.release();
18 }
19 });

In Spine, controllers are considered the glue for an application, adding and
responding to DOM events, rendering templates and ensuring that views and
models are kept in sync (which makes sense in the context of what we know to
be a controller).

What we're doing in the above example is setting up listeners in the update and
destroy events using render() and remove(). When a photo entry gets updated , we
re-render the view to reflect the changes to the meta-data. Similarly, if the
photo gets deleted from the gallery, we remove it from the view. In case you
were wondering about the tmpl() function in the code snippet: in the render()
function, we're using this to render a JavaScript template called
#photoTemplate which simply returns a HTML string used to replace the
controller's current element.

What this provides us with is a very lightweight, simple way to manage
changes between the model and the view.

70 de 184 22/03/12 11:43


Backbone.js

Later on in this section we're going to revisit the differences between
Backbone and traditional MVC, but for now let's focus on controllers.

In Backbone, one shares the responsibility of a controller with both the
Backbone.View and Backbone.Router. Some time ago Backbone did once come
with it's own Backbone.Controller, but as the naming for this component didn't
make sense for the context in which it was being used, it was later renamed to
Router.

Routers handle a little more of the controller responsibility as it's possible to
bind the events there for models and have your view respond to DOM events
and rendering. As Tim Branyen (another Bocoup-based Backbone contributor)
has also previously pointed out, it's possible to get away with not needing
Backbone.Router at all for this, so a way to think about it using the Router
paradigm is probably:

01 var PhotoRouter = Backbone.Router.extend({
02 routes: { "photos/:id": "route" },
03
04 route: function(id) {
05 var item = photoCollection.get(id);
06 var view = new PhotoView({ model: item });
07
08 something.html( view.render().el );
09 }
10 }):

To summarize, the takeaway from this section is that controllers manage the
logic and coordination between models and views in an application.

What does MVC give us?
This separation of concerns in MVC facilitates simpler modularization of an
application's functionality and enables:

Easier overall maintenance. When updates need to be made to the application
it is very clear whether the changes are data-centric, meaning changes to
models and possibly controllers, or merely visual, meaning changes to views.
Decoupling models and views means that it is significantly more straight-
forward to write unit tests for business logic
Duplication of low-level model and controller code (i.e what you may have been
using instead) is eliminated across the application
Depending on the size of the application and separation of roles, this

71 de 184 22/03/12 11:43


modularity allows developers responsible for core logic and developers working
on the user-interfaces to work simultaneously
Delving deeper

Right now, you likely have a basic understanding of what the MVC pattern
provides, but for the curious, we can explore it a little further.

The GoF (Gang of Four) do not refer to MVC as a design pattern, but rather
consider it a "set of classes to build a user interface". In their view, it's actually
a variation of three other classical design patterns: the Observer (Pub/Sub),
Strategy and Composite patterns. Depending on how MVC has been
implemented in a framework, it may also use the Factory and Decorator
patterns.

As we've discussed, models represent application data whilst views are what
the user is presented on screen. As such, MVC relies on Pub/Sub for some of
its core communication (something that surprisingly isn't cover in many
articles about the MVC pattern). When a model is changed it notifies the rest
of the application it has been updated. The controller then updates the view
accordingly. The observer nature of this relationship is what facilitates multiple
views being attached to the same model.

For developers interested in knowing more about the decoupled nature of MVC
(once again, depending on the implement), one of the goal's of the pattern is to
help define one-to-many relationships between a topic and its observers. When
a topic changes, its observers are updated. Views and controllers have a
slightly different relationship. Controllers facilitate views to respond to
different user input and are an example of the Strategy pattern.

Summary

Having reviewed the classical MVC pattern, we should now understand how it
allows us to cleanly separate concerns in an application. We should also now
appreciate how JavaScript MVC frameworks may differ in their interpretation
of the MVC pattern, which although quite open to variation, still shares some
of the fundamental concepts the original pattern has to offer.

When reviewing a new JavaScript MVC/MV* framework, remember - it can be
useful to step back and review how it's opted to approach architecture
(specifically, how it supports implementing models, views, controllers or other
alternatives) as this can better help you grok how the framework expects to be

72 de 184 22/03/12 11:43


used.

MVP
Model-view-presenter (MVP) is a derivative of the MVC design pattern which
focuses on improving presentation logic. It originated at a company named
Taligent in the early 1990s while they were working on a model for a C++
CommonPoint environment. Whilst both MVC and MVP target the separation
of concerns across multiple components, there are some fundamental
differences between them.

For the purposes of this summary we will focus on the version of MVP most
suitable for web-based architectures.

Models, Views & Presenters

The P in MVP stands for presenter. It's a component which contains the
user-interface business logic for the view. Unlike MVC, invocations from the
view are delegated to the presenter, which are decoupled from the view and
instead talk to it through an interface. This allows for all kinds of useful things
such as being able to mock views in unit tests.

The most common implementation of MVP is one which uses a Passive View (a
view which is for all intents and purposes "dumb"), containing little to no logic.
MVP models are almost identical to MVC models and handle application data.
The presenter acts as a mediator which talks to both the view and model,
however both of these are isolated from each other. They effectively bind
models to views, a responsibility which was previously held by controllers in
MVC. Presenters are at the heart of the MVP pattern and as you can guess,
incorporate the presentation logic behind views.

Solicited by a view, presenters perform any work to do with user requests and
pass data back to them. In this respect, they retrieve data, manipulate it and
determine how the data should be displayed in the view. In some
implementations, the presenter also interacts with a service layer to persist
data (models). Models may trigger events but it's the presenters role to
subscribe to them so that it can update the view. In this passive architecture,
we have no concept of direct data binding. Views expose setters which
presenters can use to set data.

The benefit of this change from MVC is that it increases the testability of your

73 de 184 22/03/12 11:43


application and provides a more clean separation between the view and the
model. This isn't however without its costs as the lack of data binding support
in the pattern can often mean having to take care of this task separately.

Although a common implementation of a Passive View is for the view to
implement an interface, there are variations on it, including the use of events
which can decouple the View from the Presenter a little more. As we don't
have the interface construct in JavaScript, we're using more a protocol than an
explicit interface here. It's technically still an API and it's probably fair for us to
refer to it as an interface from that perspective.

There is also a Supervising Controller variation of MVP, which is closer to the
MVC and MVVM patterns as it provides data-binding from the Model directly
from the View. Key-value observing (KVO) plugins (such as Derick Bailey's
Backbone.ModelBinding plugin) tend to bring Backbone out of the Passive
View and more into the Supervising Controller or MVVM variations.

MVP or MVC?
MVP is generally used most often in enterprise-level applications where it's
necessary to reuse as much presentation logic as possible. Applications with
very complex views and a great deal of user interaction may find that MVC
doesn't quite fit the bill here as solving this problem may mean heavily relying
on multiple controllers. In MVP, all of this complex logic can be encapsulated
in a presenter, which can simplify maintenance greatly.

As MVP views are defined through an interface and the interface is technically
the only point of contact between the system and the view (other than a
presenter), this pattern also allows developers to write presentation logic
without needing to wait for designers to produce layouts and graphics for the
application.

Depending on the implementation, MVP may be more easy to automatically
unit test than MVC. The reason often cited for this is that the presenter can be
used as a complete mock of the user-interface and so it can be unit tested
independent of other components. In my experience this really depends on the
languages you are implementing MVP in (there's quite a difference between
opting for MVP for a JavaScript project over one for say, ASP.net).

At the end of the day, the underlying concerns you may have with MVC will
likely hold true for MVP given that the differences between them are mainly

74 de 184 22/03/12 11:43


semantic. As long as you are cleanly separating concerns into models, views
and controllers (or presenters) you should be achieving most of the same
benefits regardless of the pattern you opt for.

MVC, MVP and Backbone.js
There are very few, if any architectural JavaScript frameworks that claim to
implement the MVC or MVC patterns in their classical form as many JavaScript
developers don't view MVC and MVP as being mutually exclusive (we are
actually more likely to see MVP strictly implemented when looking at web
frameworks such as ASP.net or GWT). This is because it's possible to have
additional presenter/view logic in your application and yet still consider it a
flavor of MVC.

Backbone contributor Irene Ros (of Boston-based Bocoup) subscribes to this
way of thinking as when she separates views out into their own distinct
components, she needs something to actually assemble them for her. This
could either be a controller route (such as a Backbone.Router, covered later in the
book) or a callback in response to data being fetched.

That said, some developers do however feel that Backbone.js better fits the
description of MVP than it does MVC . Their view is that:

The presenter in MVP better describes the Backbone.View (the layer between
View templates and the data bound to it) than a controller does
The model fits Backbone.Model (it isn't greatly different to the models in MVC at
all)
The views best represent templates (e.g Handlebars/Mustache markup
templates)
A response to this could be that the view can also just be a View (as per MVC)
because Backbone is flexible enough to let it be used for multiple purposes.
The V in MVC and the P in MVP can both be accomplished by Backbone.View
because they're able to achieve two purposes: both rendering atomic
components and assembling those components rendered by other views.

We've also seen that in Backbone the responsibility of a controller is shared
with both the Backbone.View and Backbone.Router and in the following
example we can actually see that aspects of that are certainly true.

Our Backbone PhotoView uses the Observer pattern to 'subscribe' to changes to a
View's model in the line this.model.bind('change',...). It also handles templating

75 de 184 22/03/12 11:43


in the render() method, but unlike some other implementations, user
interaction is also handled in the View (see events).

01 var PhotoView = Backbone.View.extend({
02
03 //... is a list tag.
04 tagName: "li",
05
06 // Pass the contents of the photo template through a templating
07 // function, cache it for a single photo
08 template: _.template($('#photo-template').html()),
09
10 // The DOM events specific to an item.
11 events: {
12 "click img" : "toggleViewed"
13 },
14
15 // The PhotoView listens for changes to
16 // its model, re-rendering. Since there's
17 // a one-to-one correspondence between a
18 // **Photo** and a **PhotoView** in this
19 // app, we set a direct reference on the model for convenience.
20
21 initialize: function() {
22 _.bindAll(this, 'render');
23 this.model.bind('change', this.render);
24 this.model.bind('destroy', this.remove);
25 },
26
27 // Re-render the photo entry
28 render: function() {
29 $(this.el).html(this.template(this.model.toJSON()));
30 return this;
31 },
32
33 // Toggle the `"viewed"` state of the model.
34 toggleViewed: function() {
35 this.model.viewed();
36 }
37
38 });

Another (quite different) opinion is that Backbone more closely resembles
Smalltalk-80 MVC, which we went through earlier.

As regular Backbone user Derick Bailey has previously put it, it's ultimately
best not to force Backbone to fit any specific design patterns. Design patterns
should be considered flexible guides to how applications may be structured and
in this respect, Backbone fits neither MVC nor MVP. Instead, it borrows some
of the best concepts from multiple architectural patterns and creates a flexible
framework that just works well.

It is however worth understanding where and why these concepts originated,

76 de 184 22/03/12 11:43


so I hope that my explanations of MVC and MVP have been of help. Call it the
Backbone way, MV* or whatever helps reference its flavor of application
architecture. Most structural JavaScript frameworks will adopt their own take
on classical patterns, either intentionally or by accident, but the important
thing is that they help us develop applications which are organized, clean and
can be easily maintained.

Decorator Pattern

In this section we're going to continue exploring the decorator - a structural
designpattern that promotes code reuse and is a flexible alternative to
subclassing. This pattern is also useful for modifying existing systems where
you may wish to add additional features to objects without the need to change
the underlying code that uses them.

Traditionally, the decorator is defined as a design pattern that allows behaviour
to be added to an existing object dynamically. The idea is that the decoration
itself isn't essential to the base functionality of an object otherwise it would be
baked into the 'superclass' object itself.

Subclassing
For developers unfamiliar with subclassing, here is a beginner's primer on
them before we dive further into decorators: subclassing is a term that refers
to inheriting properties for a new object from a base or 'superclass' object.

In traditional OOP, a class B is able to extend another class A. Here we
consider A a superclass and B a subclass of A. As such, all instances of B
inherit the methods from A. B is however still able to define it's own methods,
including those that override methods originally defined by A.

Should B need to invoke a method in A that has been overriden, we refer to
this as method chaining. Should B need to invoke the constructor A() (the
superclass), we call this constructor chaining.

In order to demonstrate subclassing, we first need a base object that can have
new instances of itself created. Let's model this around the concept of a
person.

77 de 184 22/03/12 11:43


1 var subclassExample = subclassExample || {};
2 subclassExample = {
3 Person: function( firstName , lastName ){
4 this.firstName = firstName;
5 this.lastName = lastName;
6 this.gender = 'male'
7 }
8 }

Next, we'll want to specify a new class (object) that's a subclass of the existing
Person object. Let's imagine we want to add distinct properties to distinguish a
Person from a Superhero whilst inheriting the properties of the Person
'superclass'. As superheroes share many common traits with normal people
(eg. name, gender), this should hopefully illustrate how subclassing works
adequately.

01 //a new instance of Person can then easily be created as follows:
02 var clark = new subclassExample.Person( "Clark" , "Kent" );
03
04 //Define a subclass constructor for for 'Superhero':
05 subclassExample.Superhero = function( firstName, lastName , powers ){
06 /*
07 Invoke the superclass constructor on the new object
08 then use .call() to invoke the constructor as a method of
09 the object to be initialized.
10 */
11 subclassExample.Person.call(this, firstName, lastName);
12 //Finally, store their powers, a new array of traits not found in a
normal 'Person'
13 this.powers = powers;
14 }
15 subclassExample.Superhero.prototype = new subclassExample.Person;
16 var superman = new subclassExample.Superhero( "Clark" ,"Kent" ,
['flight','heat-vision'] );
17 console.log(superman); /* includes superhero props as well as gender*/

The Superhero definition creates an object which descends from Person.
Objects of this type have properties of the objects that are above it in the chain
and if we had set default values in the Person object, Superhero is capable of
overriding any inherited values with values specific to it's object.

So where do decorators come in?

Decorators
As we've previously covered, Decorators are used when it's necessary to
delegate responsibilities to an object where it doesn't make sense to subclass
it. A common reason for this is that the number of features required demand
for a very large quantity of subclasses. Can you imagine having to define

78 de 184 22/03/12 11:43


hundreds or thousands of subclasses for a project? It would likely become
unmanagable fairly quickly.

To give you a visual example of where this is an issue, imagine needing to
define new kinds of Superhero: SuperheroThatCanFly,
SuperheroThatCanRunQuickly and SuperheroWithXRayVision.

Now, what if s superhero had more than one of these properties?. We'd need
to define a subclass called SuperheroThatCanFlyAndRunQuickly ,
SuperheroThatCanFlyRunQuicklyAndHasXRayVision etc - effectively, one for
each possible combination. As you can see, this isn't very manageable when
you factor in different abilities.

The decorator pattern isn't heavily tied to how objects are created but instead
focuses on the problem of extending their functionality. Rather than just using
inheritance, where we're used to extending objects linearly, we work with a
single base object and progressively add decorator objects which provide the
additional capabilities. The idea is that rather than subclassing, we add
(decorate) properties or methods to a base object so its a little more
streamlined.

The extension of objects is something already built into JavaScript and as we
know, objects can be extended rather easily with properties being included at
any point. With this in mind, a very very simplistic decorator may be
implemented as follows:

Example 1: Basic decoration of existing object constructors
with new functionality
01 function vehicle( vehicleType ){
02 /*properties and defaults*/
03 this.vehicleType = vehicleType || 'car',
04 this.model = 'default',
05 this.license = '00000-000'
06 }
07 /*Test instance for a basic vehicle*/
08 var testInstance = new vehicle('car');
09 console.log(testInstance);
10 /*vehicle: car, model:default, license: 00000-000*/
11 /*Lets create a new instance of vehicle, to be decorated*/
12 var truck = new vehicle('truck');
13 /*New functionality we're decorating vehicle with*/
14 truck.setModel = function( modelName ){
15 this.model = modelName;
16 }
17 truck.setColor = function( color ){
18 this.color = color;

79 de 184 22/03/12 11:43


19 }
20
21 /*Test the value setters and value assignment works correctly*/
22 truck.setModel('CAT');
23 truck.setColor('blue');
24 console.log(truck);
25 /*vehicle:truck, model:CAT, color: blue*/
26 /*Demonstrate 'vehicle' is still unaltered*/
27 var secondInstance = new vehicle('car');
28 console.log(secondInstance);
29 /*as before, vehicle: car, model:default, license: 00000-000*/

This type of simplistic implementation is something you're likely familiar with,
but it doesn't really demonstrate some of the other strengths of the pattern.
For this, we're first going to go through my variation of the Coffee example
from an excellent book called Head First Design Patterns by Freeman, Sierra
and Bates, which is modelled around a Macbook purchase.

We're then going to look at psuedo-classical decorators.

Example 2: Simply decorate objects with multiple decorators
01 //What we're going to decorate
02 function MacBook() {
03 this.cost = function () { return 997; };
04 this.screenSize = function () { return 13.3; };
05 }
06
07 /*Decorator 1*/
08 function Memory( macbook ) {
09 var v = macbook.cost();
10 macbook.cost = function() {
11 return v + 75;
12 }
13 }
14 /*Decorator 2*/
15 function Engraving( macbook ){
17 macbook.cost = function(){
18 return v + 200;
19 };
20 }
21
22 /*Decorator 3*/
23 function Insurance( macbook ){
25 macbook.cost = function(){
26 return v + 250;
27 };
28 }
29 var mb = new MacBook();
30 Memory(mb);
31 Engraving(mb);
32 Insurance(mb);
33 console.log(mb.cost()); //1522

80 de 184 22/03/12 11:43


34 console.log(mb.screenSize()); //13.3

Here, the decorators are overrriding the superclass .cost() method to return
the current price of the Macbook plus with the cost of the upgrade being
specified. It's considered a decoration as the original Macbook object's
constructor methods which are not overridden (eg. screenSize()) as well as any
other properties which we may define as a part of the Macbook remain
unchanged and in tact.

As you can probably tell, there isn't really a defined 'interface' in the above
example and duck typing is used to shift the responsibility of ensuring an
object meets an interface when moving from the creator to the receiver.

Pseudo-classical decorators
We're now going to examine the variation of the decorator presented in 'Pro
JavaScript Design Patterns' (PJDP) by Dustin Diaz and Ross Harmes.

Unlike some of the examples from earlier, Diaz and Harmes stick more closely
to how decorators are implemented in other programming languages (such as
Java or C++) using the concept of an 'interface', which we'll define in more
detail shortly.

Note: This particular variation of the decorator pattern is provided for
reference purposes. If you find it overly complex for your application's needs, I
recommend sticking to one the simplier implementations covered earlier, but I
would still read the section. If you haven't yet grasped how decorators are
different from subclassing, it may help!.

Interfaces

PJDP describes the decorator as a pattern that is used to transparently wrap
objects inside other objects of the same interface. An interface is a way of
defining the methods an object *should* have, however, it doesn't actually
directly specify how those methods should be implemented.

They can also indicate what parameters the methods take, but this is
considered optional.

So, why would you use an interface in JavaScript? The idea is that they're
self-documenting and promote reusability. In theory, interfaces also make code
more stable by ensuring changes to them must also be made to the classes

81 de 184 22/03/12 11:43


implementing them.

Below is an example of an implementation of Interfaces in JavaScript using
duck-typing - an approach that helps determine whether an object is an
instance of constructor/object based on the methods it implements.

01 var TodoList = new Interface('Composite', ['add', 'remove']);
02 var TodoItem = new Interface('TodoItem', ['save']);
03 // TodoList class
04 var myTodoList = function(id, method, action) {
05 // implements TodoList, TodoItem
06 ...
07 };
08 ...
09 function addTodo( todoInstance ) {
10 Interface.ensureImplements(todoInstance, TodoList, TodoItem);
11 // This function will throw an error if a required method is not
implemented,
12 // halting execution of the function.
13 //...
14 }

where Interface.ensureImplements provides strict checking. If you would like
to explore interfaces further, I recommend looking at Chapter 2 of Pro
JavaScript design patterns. For the Interface class used above, see here.

The biggest problem with interfaces is that, as there isn't built-in support for
them in JavaScript, there's a danger of us attempting to emulate the
functionality of another language, however, we're going to continue
demonstrating their use just to give you a complete view of how the decorator
is implemented by other developers.

This variation of decorators and abstract decorators

To demonstrate the structure of this version of the decorator pattern, we're
going to imagine we have a superclass that models a macbook once again and
a store that allows you to 'decorate' your macbook with a number of
enhancements for an additional fee.

Enhancements can include upgrades to 4GB or 8GB Ram, engraving, Parallels
or a case. Now if we were to model this using an individual subclass for each
combination of enhancement options, it might look something like this:

01 var Macbook = function(){
02 //...
03 }
04 var MacbookWith4GBRam = function(){},
05 MacbookWith8GBRam = function(){},

82 de 184 22/03/12 11:43


06 MacbookWith4GBRamAndEngraving = function(){},
07 MacbookWith8GBRamAndEngraving = function(){},
08 MacbookWith8GBRamAndParallels = function(){},
09 MacbookWith4GBRamAndParallels = function(){},
10 MacbookWith8GBRamAndParallelsAndCase = function(){},
11 MacbookWith4GBRamAndParallelsAndCase = function(){},
12 MacbookWith8GBRamAndParallelsAndCaseAndInsurance = function(){},
13 MacbookWith4GBRamAndParallelsAndCaseAndInsurance = function(){};

and so on.

This would be an impractical solution as a new subclass would be required for
every possible combination of enhancements that are available. As we'd prefer
to keep things simple without maintaining a large set of subclasses, let's look
at how decorators may be used to solve this problem better.

Rather than requiring all of the combinations we saw earlier, we should simply
have to create five new decorator classes. Methods that are called on these
enhancement classes would be passed on to our Macbook class.

In our next example, decorators transparently wrap around their components
and can interestingly be interchanged astray use the same interface.

Here's the interface we're going to define for the Macbook:

01 var Macbook = new Interface('Macbook', ['addEngraving', 'addParallels',
'add4GBRam', 'add8GBRam', 'addCase']);
02 A Macbook Pro might thus be represented as follows:
03 var MacbookPro = function(){
04 //implements Macbook
05 }
06 MacbookPro.prototype = {
07 addEngraving: function(){
08 },
09 addParallels: function(){
10 },
11 add4GBRam: function(){
12 },
13 add8GBRam:function(){
14 },
15 addCase: function(){
16 },
17 getPrice: function(){
18 return 900.00; //base price.
19 }
20 };

We're not going to worry about the actual implementation at this point as we'll
shortly be passing on all method calls that are made on them.

To make it easier for us to add as many more options as needed later on, an

83 de 184 22/03/12 11:43


abstract decorator class is defined with default methods required to implement
the Macbook interface, which the rest of the options will subclass.

Abstract decorators ensure that we can decorate a base class independently
with as many decorators as needed in different combinations (remember the
example earlier?) without needing to derive a class for every possible
combination.

01 //Macbook decorator abstract decorator class
02 var MacbookDecorator = function( macbook ){
03 Interface.ensureImplements(macbook, Macbook);
04 this.macbook = macbook;
05 }
06 MacbookDecorator.prototype = {
07 addEngraving: function(){
08 return this.macbook.addEngraving();
09 },
10 addParallels: function(){
11 return this.macbook.addParallels();
12 },
13 add4GBRam: function(){
14 return this.macbook.add4GBRam();
15 },
16 add8GBRam:function(){
17 return this.macbook.add8GBRam();
18 },
19 addCase: function(){
20 return this.macbook.addCase();
21 },
22 getPrice: function(){
23 return this.macbook.getPrice();
24 }
25 };

What's happening in the above sample is that the Macbook decorator is taking
an object to use as the component. It's using the Macbook interface we defined
earlier and for each method is just calling the same method on the component.
We can now create our option classes just by using the Macbook decorator -
simply call the superclass constructor and any methods can be overriden as per
necessary.

84 de 184 22/03/12 11:43


01 var CaseDecorator = function( macbook ){
02 /*call the superclass's constructor next*/
03 this.superclass.constructor(macbook);
04 }
05 /*Let's now extend the superclass*/
06 extend( CaseDecorator, MacbookDecorator );
07 CaseDecorator.prototype.addCase = function(){
08 return this.macbook.addCase() + " Adding case to macbook ";
09 };
10 CaseDecorator.prototype.getPrice = function(){
11 return this.macbook.getPrice() + 45.00;
12 };

As you can see, most of this is relatively easy to implement. What we're doing
is overriding the addCase() and getPrice() methods that need to be decorated
and we're achieving this by first executing the component's method and then
adding to it.

As there's been quite a lot of information presented in this section so far, let's
try to bring it all together in a single example that will hopefully highlight what
we've learned.

1 //Instantiation of the macbook
2 var myMacbookPro = new MacbookPro();
3 //This will return 900.00
4 console.log(myMacbookPro.getPrice());
5 //Decorate the macbook
6 myMacbookPro = new CaseDecorator( myMacbookPro ); /*note*/
7 //This will return 945.00
8 console.log(myMacbookPro.getPrice());

An important note from PJDP is that in the line denoted *note*, Harmes and
Diaz claim that it's important not to create a separate variable to store the
instance of your decorators, opting for the same variable instead. The
downside to this is that we're unable to access the original macbook object in
our example, however we technically shouldn't need to further.

As decorators are able to modify objects dynamically, they're a perfect pattern
for changing existing systems. Occasionally, it's just simpler to create
decorators around an object versus the trouble of maintaining individual
subclasses. This makes maintaining applications of this type significantly more
straight-forward.

Implementing decorators with jQuery
As with other patterns I''ve covered, there are also examples of the decorator
pattern that can be implemented with jQuery. jQuery.extend() allows you to

85 de 184 22/03/12 11:43


extend (or merge) two or more objects (and their properties) together into a
single object either at run-time or dynamically at a later point.

In this scenario, a target object can be decorated with new functionality
without necessarily breaking or overriding existing methods in the
source/superclass object (although this can be done).

In the following example, we define three objects: defaults, options and
settings. The aim of the task is to decorate the 'defaults' object with additional
functionality found in 'options', which we'll make available through 'settings'.
We must:

(a) Leave 'defaults' in an untouched state where we don't lose the ability to
access the properties or functions found in it a later point (b) Gain the ability to
use the decorated properties and functions found in 'options'

01 var decoratorApp = decoratorApp || {};
02 /* define the objects we're going to use*/
03 decoratorApp = {
04 defaults:{
05 validate: false,
06 limit: 5,
07 name: "foo",
08 welcome: function(){
09 //console.log('welcome!');
10 }
11 },
12 options:{
13 validate: true,
14 name: "bar",
15 helloWorld: function(){
16 //console.log('hello');
17 }
18 },
19 settings:{},
20 printObj: function(obj) {
21 var arr = [];
22 $.each(obj, function(key, val) {
23 var next = key + ": ";
24 next += $.isPlainObject(val) ? printObj(val) : val;
25 arr.push( next );
26 });
27 return "{ " + arr.join(", ") + " }";
28 }
29
30 }
31 /* merge defaults and options, without modifying defaults */
32 decoratorApp.settings = $.extend({},
decoratorApp.defaults,decoratorApp.options);
33 /* what we've done here is decorated defaults in a way that provides
access to the properties and functionality it has to offer (as well as
that of the decorator 'options'). defaults itself is left unchanged*/

86 de 184 22/03/12 11:43


34 $('#log').append("<div><b>settings -- </b>" +
decoratorApp.printObj(decoratorApp.settings) + "</div><div><b>options --
</b>" + decoratorApp. printObj(decoratorApp.options) + "</div>
<div><b>defaults -- </b>" +decoratorApp.printObj(decoratorApp.defaults)
+ "</div>" );
35 /*
36 settings -- { validate: true, limit: 5, name: bar, welcome: function (){
console.log('welcome!'); }, helloWorld: function (){
console.log('hello!'); } }
37 options -- { validate: true, name: bar, helloWorld: function (){
console.log('hello!'); } }
38 defaults -- { validate: false, limit: 5, name: foo, welcome: function
(){ console.log('welcome!'); } }
39 */

Pros and cons of the pattern
Developers enjoy using this pattern as it can be used transparently and is also
fairly flexible - as we've seen, objects can be wrapped or 'decorated' with new
behavior and then continue to be used without needing to worry about the
base object being modified. In a broader context, this pattern also avoids us
needing to rely on large numbers of subclasses to get the same benefits.

There are however drawbacks that you should be aware of when implementing
the pattern. If poorly managed, it can significantly complicate your application's
architecture as it introduces many small, but similar objects into your
namespace. The concern here is that in addition to becoming hard to manage,
other developers unfamiliar with the pattern may have a hard time grasping
why it's being used.

Sufficient commenting or pattern research should assist with the latter,
however as long as you keep a handle on how widespread you use the
decorator in your application you should be fine on both counts.

Namespacing Patterns

In this section, I'll be discussing both intermediate and advanced patterns for
namespacing in JavaScript. We're going to begin with the latter, however if
you're new to namespacing with the language and would like to learn more
about some of the fundamentals, please feel free to skip to the section titled
'namespacing fundamentals' to continue reading.

87 de 184 22/03/12 11:43


What is namespacing?
In many programming languages, namespacing is a technique employed to
avoid collisions with other objects or variables in the global namespace.
They're also extremely useful for helping organize blocks of functionality in
your application into easily manageable groups that can be uniquely identified.

In JavaScript, namespacing at an enterprise level is critical as it's important to
safeguard your code from breaking in the event of another script on the page
using the same variable or method names as you are. With the number of
third-party tags regularly injected into pages these days, this can be a
common problem we all need to tackle at some point in our careers. As a
well-behaved 'citizen' of the global namespace, it's also imperative that you do
your best to similarly not prevent other developer's scripts executing due to the
same issues.

Whilst JavaScript doesn't really have built-in support for namespaces like other
languages, it does have objects and closures which can be used to achieve a
similar effect.

Advanced namespacing patterns
In this section, I'll be exploring some advanced patterns and utility techniques
that have helped me when working on larger projects requiring a re-think of
how application namespacing is approached. I should state that I'm not
advocating any of these as *the* way to do things, but rather just ways that I've
found work in practice.

Automating nested namespacing

As you're probably aware, a nested namespace provides an organized
hierarchy of structures in an application and an example of such a namespace
could be the following: application.utilities.drawing.canvas.2d. In JavaScript the
equivalent of this definition using the object literal pattern would be:

01 var application = {
02 utilities:{
03 drawing:{
04 canvas:{
05 2d:{
06 /*...*/

88 de 184 22/03/12 11:43


07 }
08 }
09 }
10 }
11 };

Wow, that's ugly.

One of the obvious challenges with this pattern is that each additional depth
you wish to create requires yet another object to be defined as a child of some
parent in your top-level namespace. This can become particularly laborious
when multiple depths are required as your application increases in complexity.

How can this problem be better solved? In JavaScript Patterns, Stoyan Stefanov
presents a very-clever approach for automatically defining nested namespaces
under an existing global variable using a convenience method that takes a
single string argument for a nest, parses this and automatically populates your
base namespace with the objects required.

The method he suggests using is the following, which I've updated it to be a
generic function for easier re-use with multiple namespaces:

01 // top-level namespace being assigned an object literal
02 var myApp = myApp || {};
03
04 // a convenience function for parsing string namespaces and
05 // automatically generating nested namespaces
06 function extend( ns, ns_string ) {
07 var parts = ns_string.split('.'),
08 parent = ns,
09 pl, i;
10
11 if (parts[0] == "myApp") {
12 parts = parts.slice(1);
13 }
14
15 pl = parts.length;
16 for (i = 0; i < pl; i++) {
17 // create a property if it doesnt exist
18 if (typeof parent[parts[i]] == 'undefined') {
19 parent[parts[i]] = {};
20 }
21
22 parent = parent[parts[i]];
23 }
24
25 return parent;
26 }
27
28 // sample usage:
29 // extend myApp with a deeply nested namespace
30 var mod = extend(myApp, 'myApp.modules.module2');

89 de 184 22/03/12 11:43


31 // the correct object with nested depths is output
32 console.log(mod);
33 // minor test to check the instance of mod can also
34 // be used outside of the myApp namesapce as a clone
35 // that includes the extensions
36 console.log(mod == myApp.modules.module2); //true
37 // further demonstration of easier nested namespace
38 // assignment using extend
39 extend(myApp, 'moduleA.moduleB.moduleC.moduleD');
40 extend(myApp, 'longer.version.looks.like.this');
41 console.log(myApp);

Web inspector output:

Note how where one would previously have had to explicitly declare the various
nests for their namespace as objects, this can now be easily achieved using a
single, cleaner line of code. This works exceedingly well when defining purely
namespaces alone, but can seem a little less flexible when you want to define
both functions and properties at the same time as declaring your namespaces.
Regardless, it is still incredibly powerful and I regularly use a similar approach
in some of my projects.

Dependency declaration pattern

In this section we're going to take a look at a minor augmentation to the
nested namespacing pattern you may be used to seeing in some applications.
We all know that local references to objects can decrease overall lookup times,

90 de 184 22/03/12 11:43


but let's apply this to namespacing to see how it might look in practice:

01 // common approach to accessing nested namespaces
02 myApp.utilities.math.fibonacci(25);
03 myApp.utilities.math.sin(56);
04 myApp.utilities.drawing.plot(98,50,60);
05
06
07 // with local/cached references
08 Var utils = myApp.utilities,
09 maths = utils.math,
10 drawing = utils.drawing;
11
12 // easier to access the namespace
13 maths.fibonacci(25);
14 maths.sin(56);
15 drawing.plot(98, 50,60);
16
17 // note that the above is particularly performant when
18 // compared to hundreds or thousands of calls to nested
19 // namespaces vs. a local reference to the namespace

Working with a local variable here is almost always faster than working with a
top-level global (eg.myApp). It's also both more convenient and more
performant than accessing nested properties/sub-namespaces on every
subsequent line and can improve readability in more complex applications.

Stoyan recommends declaring localized namespaces required by a function or
module at the top of your function scope (using the single-variable pattern) and
calls this a dependancy declaration pattern. One if the benefits this offers is a
decrease in locating dependencies and resolving them, should you have an
extendable architecture that dynamically loads modules into your namespace
when required.

In my opinion this pattern works best when working at a modular level,
localizing a namespace to be used by a group of methods. Localizing
namespaces on a per-function level, especially where there is significant
overlap between namespace dependencies would be something I would
recommend avoiding where possible. Instead, define it further up and just have
them all access the same reference.

Deep object extension

An alternative approach to automatic namespacing is deep object extension.
Namespaces defined using object literal notation may be easily extended (or
merged) with other objects (or namespaces) such that the properties and
functions of both namespaces can be accessible under the same namespace

91 de 184 22/03/12 11:43


post-merge.

This is something that's been made fairly easy to accomplish with modern
JavaScript frameworks (eg. see jQuery's $.extend), however, if you're looking to
extend object (namespaces) using vanilla JS, the following routine may be of
assistance.

01 // extend.js
02 // written by andrew dupont, optimized by addy osmani
03 function extend(destination, source) {
04 var toString = Object.prototype.toString,
05 objTest = toString.call({});
06 for (var property in source) {
07 if (source[property] && objTest ==
toString.call(source[property])) {
08 destination[property] = destination[property] || {};
09 extend(destination[property], source[property]);
10 } else {
11 destination[property] = source[property];
12 }
13 }
14 return destination;
15 };
16
17
18 console.group("objExtend namespacing tests");
19
20 // define a top-level namespace for usage
21 var myNS = myNS || {};
22
23 // 1. extend namespace with a 'utils' object
24 extend(myNS, {
25 utils:{
26 }
27 });
28
29 console.log('test 1', myNS);
30 //myNS.utils now exists
31
32 // 2. extend with multiple depths (namespace.hello.world.wave)
33 extend(myNS, {
34 hello:{
35 world:{
36 wave:{
37 test: function(){
38 /*...*/
39 }
40 }
41 }
42 }
43 });
44
45 // test direct assignment works as expected
46 myNS.hello.test1 = 'this is a test';
47 myNS.hello.world.test2 = 'this is another test';

92 de 184 22/03/12 11:43


49
50 // 3. what if myNS already contains the namespace being added
51 // (eg. 'library')? we want to ensure no namespaces are being
52 // overwritten during extension
53
54 myNS.library = {
55 foo:function(){}
56 };
57
58 extend(myNS, {
59 library:{
60 bar:function(){
61 /*...*/
62 }
63 }
64 });
65
66 // confirmed that extend is operating safely (as expected)
67 // myNS now also contains library.foo, library.bar
69
70
71 // 4. what if we wanted easier access to a specific namespace without
having
72 // to type the whole namespace out each time?.
73
74 var shorterAccess1 = myNS.hello.world;
75 shorterAccess1.test3 = "hello again";
77 //success, myApp.hello.world.test3 is now 'hello again'
78
79 console.groupEnd();

If you do happen to be using jQuery in your application, you can achieve the
exact same object namespact extensibility using $.extend as seen below:

01 // top-level namespace
03
04 // directly assign a nested namespace
05 myApp.library = {
06 foo:function(){ /*..*/}
07 };
08
09 // deep extend/merge this namespace with another
10 // to make things interesting, let's say it's a namespace
11 // with the same name but with a different function
12 // signature: $.extend(deep, target, object1, object2)
13 $.extend(true, myApp, {
14 library:{
15 bar:function(){
16 /*..*/
17 }
18 }
19 });
20
21 console.log('test', myApp);
22 // myApp now contains both library.foo() and library.bar() methods

93 de 184 22/03/12 11:43


23 // nothing has been overwritten which is what we're hoping for.

For the sake of thoroughness, please see here for jQuery $.extend equivalents
to the rest of the namespacing experiments found in this section.

Namespacing Fundamentals
Namespaces can be found in almost any serious JavaScript application. Unless
you're working with a code-snippet, it's imperative that you do your best to
ensure that you're implementing namespacing correctly as it's not just simple
to pick-up, it'll also avoid third party code clobbering your own. The patterns
we'll be examining in this section are:

1. Single global variables
2. Object literal notation
3. Nested namespacing
4. Immediately-invoked Function Expressions
5. Namespace injection
1.Single global variables

One popular pattern for namespacing in JavaScript is opting for a single global
variable as your primary object of reference. A skeleton implementation of this
where we return an object with functions and properties can be found below:

1 var myApplication = (function(){
2 function(){
3 /*...*/
4 },
5 return{
6 /*...*/
7 }
8 })();

Although this works for certain situations, the biggest challenge with the
single global variable pattern is ensuring that no one else has used the same
global variable name as you have in the page.

One solution to this problem, as mentioned by Peter Michaux, is to use prefix
namespacing. It's a simple concept at heart, but the idea is you select a unique
prefix namespace you wish to use (in this example, "myApplication_") and then
define any methods, variables or other objects after the prefix as follows:

1 var myApplication_propertyA = {};
2 var myApplication_propertyB = {};
3 funcion myApplication_myMethod(){ /*..*/ }

94 de 184 22/03/12 11:43


This is effective from the perspective of trying to lower the chances of a
particular variable existing in the global scope, but remember that a uniquely
named object can have the same effect. This aside, the biggest issue with the
pattern is that it can result in a large number of global objects once your
application starts to grow. There is also quite a heavy reliance on your prefix
not being used by any other developers in the global namespace, so be careful
if opting to use this.

For more on Peter's views about the single global variable pattern, read his
excellent post on them here.

2. Object literal notation

Object literal notation can be thought of as an object containing a collection of
key:value pairs with a colon separating each pair of keys and values. It's syntax
requires a comma to be used after each key:value pair with the exception of
the last item in your object, similar to a normal array.

01 var myApplication = {
02 getInfo:function(){ /**/ },
03
04 // we can also populate our object literal to support
05 // further object literal namespaces containing anything
06 // really:
07 models : {},
08 views : {
09 pages : {}
10 },
11 collections : {}
12 };

One can also opt for adding properties directly to the namespace:

01 myApplication.foo = function(){
02 return "bar";
03 }
04 myApplication.utils = {
05 toString:function(){
06 /*..*/
07 },
08 export: function(){
09 /*..*/
10 }
11 }

Object literals have the advantage of not polluting the global namespace but
assist in organizing code and parameters logically. They're beneficial if you
wish to create easily-readable structures that can be expanded to support deep
nesting. Unlike simple global variables, object literals often also take into

95 de 184 22/03/12 11:43


account tests for the existence of a variable by the same name so the chances
of collision occurring are significantly reduced.

The code at the very top of the next sample demonstrates the different ways in
which you can check to see if a variable (object namespace) already exists
before defining it. You'll commonly see developers using Option 1, however
Options 3 and 5 may be considered more thorough and Option 4 is considered
a good best-practice.

01 // This doesn't check for existence of 'myApplication' in
02 // the global namespace. Bad practice as you can easily
03 // clobber an existing variable/namespace with the same name
04 var myApplication = {};
05
06 /*
07 The following options *do* check for variable/namespace existence.
08 If already defined, we use that instance, otherwise we assign a new
09 object literal to myApplication.
10
11 Option 1: var myApplication = myApplication || {};
12 Option 2 if(!MyApplication) MyApplication = {};
13 Option 3: var myApplication = myApplication = myApplication || {}
14 Option 4: myApplication || (myApplication = {});
15 Option 5: var myApplication = myApplication === undefined ? {} :
myApplication;
16
17 */

There is of course a huge amount of variance in how and where object literals
are used for organizing and structuring code. For smaller applications wishing
to expose a nested API for a particular self-enclosed module, you may just find
yourself using this next pattern when returning an interface for other
developers to use. It's a variation on the module pattern where the core
structure of the pattern is an IIFE, however the returned interface is an object
literal:

01 var namespace = (function () {
02
03 // defined within the local scope
04 var privateMethod1 = function () { /* ... */ }
05 var privateMethod2 = function () { /* ... */ }
06 var privateProperty1 = 'foobar';
07
08 return {
09 // the object literal returned here can have as many
10 // nested depths as you wish, however as mentioned,
11 // this way of doing things works best for smaller,
12 // limited-scope applications in my personal opinion
13 publicMethod1: privateMethod1,
14
15 //nested namespace with public properties
16 properties:{

96 de 184 22/03/12 11:43


17 publicProperty1: privateProperty1
18 },
19
20 //another tested namespace
21 utils:{
22 publicMethod2: privateMethod2
23 }
24 ...
25 }
26 })();

The benefit of object literals is that they offer us a very elegant key/value
syntax to work with; one where we're able to easily encapsulate any distinct
logic or functionality for our application in a way that clearly separates it from
others and provides a solid foundation for extending your code.

A possible downside however is that object literals have the potential to grow
into long syntactic constructs. Opting to take advantage of the nested
namespace pattern (which also uses the same pattern as it's base)

This pattern has a number of other useful applications too. In addition to
namespacing, it's often of benefit to decouple the default configuration for
your application into a single area that can be easily modified without the need
to search through your entire codebase just to alter them - object literals work
great for this purpose. Here's an example of a hypothetical object literal for
configuration:

01 var myConfig = {
02 language: 'english',
03 defaults: {
04 enableGeolocation: true,
05 enableSharing: false,
06 maxPhotos: 20
07 },
08 theme: {
09 skin: 'a',
10 toolbars: {
11 index: 'ui-navigation-toolbar',
12 pages: 'ui-custom-toolbar'
13 }
14 }
15 }

Note that there are really only minor syntactical differences between the object
literal pattern and a standard JSON data set. If for any reason you wish to use
JSON for storing your configurations instead (e.g. for simpler storage when
sending to the back-end), feel free to. For more on the object literal pattern, I
recommend reading Rebecca Murphey's excellent article on the topic.

97 de 184 22/03/12 11:43


3. Nested namespacing

An extension of the object literal pattern is nested namespacing. It's another
common pattern used that offers a lower risk of collision due to the fact that
even if a namespace already exists, it's unlikely the same nested children do.

Does this look familiar?

1 YAHOO.util.Dom.getElementsByClassName('test');

Yahoo's YUI framework uses the nested object namespacing pattern regularly
and at AOL we also use this pattern in many of our main applications. A
sample implementation of nested namespacing may look like this:

02
03 // perform a similar existence check when defining nested
04 // children
05 myApp.routers = myApp.routers || {};
06 myApp.model = myApp.model || {};
07 myApp.model.special = myApp.model.special || {};
08
09 // nested namespaces can be as complex as required:
10 // myApp.utilities.charting.html5.plotGraph(/*..*/);
11 // myApp.modules.financePlanner.getSummary();
12 // myApp.services.social.facebook.realtimeStream.getLatest();

You can also opt to declare new nested namespaces/properties as indexed
properties as follows:

1 myApp["routers"] = myApp["routers"] || {};
2 myApp["models"] = myApp["models"] || {};
3 myApp["controllers"] = myApp["controllers"] || {};

Both options are readable, organized and offer a relatively safe way of
namespacing your application in a similar fashion to what you may be used to
in other languages. The only real caveat however is that it requires your
browser's JavaScript engine first locating the myApp object and then digging
down until it gets to the function you actually wish to use.

This can mean an increased amount of work to perform lookups, however
developers such as Juriy Zaytsev have previously tested and found the
performance differences between single object namespacing vs the 'nested'
approach to be quite negligible.

98 de 184 22/03/12 11:43


4. Immediately-invoked Function Expressions (IIFE)s

An IIFE is effectively an unnamed function which is immediately invoked after
it's been defined. In JavaScript, because both variables and functions explicitly
defined within such a context may only be accessed inside of it, function
invocation provides an easy means to achieving privacy.

This is one of the many reasons why IIFEs are a popular approach to
encapsulating application logic to protect it from the global namespace. You've
probably come across this pattern before under the name of a self-executing
(or self-invoked) anonymous function, however I personally prefer Ben Alman's
naming convection for this particular pattern as I believe it to be both more
descriptive and more accurate.

The simplest version of an IIFE could be the following:

1 // an (anonymous) immediately-invoked function expression
2 (function(){ /*...*/})();
3 // a named immediately-invoked function expression
4 (function foobar(){ /*..*/}());
5 // this is technically a self-executing function which is quite
different
6 function foobar(){ foobar(); }

whilst a slightly more expanded version of the first example might look like:

01 var namespace = namespace || {};
02
03 // here a namespace object is passed as a function
04 // parameter, where we assign public methods and
05 // properties to it
06 (function( o ){
07 o.foo = "foo";
08 o.bar = function(){
09 return "bar";
10 };
11 })(namespace);
12
13 console.log(namespace);

Whilst readable, this example could be significantly expanded on to address
common development concerns such as defined levels of privacy (public/private
functions and variables) as well as convenient namespace extension. Let's go
through some more code:

01 // namespace (our namespace name) and undefined are passed here
02 // to ensure 1. namespace can be modified locally and isn't
03 // overwritten outside of our function context
04 // 2. the value of undefined is guaranteed as being truly
05 // undefined. This is to avoid issues with undefined being

99 de 184 22/03/12 11:43


06 // mutable pre-ES5.
07
08 ;(function ( namespace, undefined ) {
09 // private properties
10 var foo = "foo",
11 bar = "bar";
12
13 // public methods and properties
14 namespace.foobar = "foobar";
15 namespace.sayHello = function () {
16 speak("hello world");
17 };
18
19 // private method
20 function speak(msg) {
21 console.log("You said: " + msg);
22 };
23
24 // check to evaluate whether 'namespace' exists in the
25 // global namespace - if not, assign window.namespace an
26 // object literal
27 }(window.namespace = window.namespace || {});
28
29
30 // we can then test our properties and methods as follows
31
32 // public
33 console.log(namespace.foobar); // foobar
34 namescpace.sayHello(); // hello world
35
36 // assigning new properties
37 namespace.foobar2 = "foobar";
38 console.log(namespace.foobar2);

Extensibility is of course key to any scalable namespacing pattern and IIFEs
can be used to achieve this quite easily. In the below example, our 'namespace'
is once again passed as an argument to our anonymous function and is then
extended (or decorated) with further functionality:

1 // let's extend the namespace with new functionality
2 (function( namespace, undefined ){
3 // public method
4 namespace.sayGoodbye = function(){
5 console.log(namespace.foo);
6 console.log(namespace.bar);
7 speak('goodbye');
8 }
9 }( window.namespace = window.namespace || {});

namespace.sayGoodbye(); //goodbye

That's it for IIFEs for the time-being. If you would like to find out more about
this pattern, I recommend reading both Ben's IIFE post and Elijah Manor's
post on namespace patterns from C#.

100 de 184 22/03/12 11:43


5. Namespace injection

Namespace injection is another variation on the IIFE where we 'inject' the
methods and properties for a specific namespace from within a function
wrapper using this as a namespace proxy. The benefit this pattern offers is
easy application of functional behaviour to multiple objects or namespaces and
can come in useful when applying a set of base methods to be built on later
(eg. getters and setters).

The disadvantages of this pattern are that there may be easier or more optimal
approaches to achieving this goal (eg. deep object extension / merging) which I
cover earlier in the article..

Below we can see an example of this pattern in action, where we use it to
populate the behaviour for two namespaces: one initially defined (utils) and
another which we dynamically create as a part of the functionality assignment
for utils (a new namespace called tools).

02 myApp.utils = {};
03
04
05 (function() {
06 var val = 5;
07
08 this.getValue = function() {
09 return val;
10 };
11
12 this.setValue = function(newVal) {
13 val = newVal;
14 }
15
16 // also introduce a new sub-namespace
17 this.tools = {};
18
19 }).apply(myApp.utils);
20
21 // inject new behaviour into the tools namespace
22 // which we defined via the utilities module
23
24 (function(){
25 this.diagnose = function(){
26 return 'diagnosis';
27 }
28 }).apply(myApp.utils.tools);
29
30 // note, this same approach to extension could be applied
31 // to a regular IIFE, by just passing in the context as
32 // an argument and modifying the context rather than just
33 // 'this'

101 de 184 22/03/12 11:43


34
35 // testing
36 console.log(myApp); //the now populated namespace
37 console.log(myApp.utils.getValue()); // test get
38 myApp.utils.setValue(25); // test set
39 console.log(myApp.utils.getValue());
40 console.log(myApp.utils.tools.diagnose());

Angus Croll has also previously suggested the idea of using the call API to
provide a natural separation between contexts and arguments. This pattern
can feel a lot more like a module creator, but as modules still offer an
encapsulation solution, I'll briefly cover it for the sake of thoroghness:

01 // define a namespace we can use later
02 var ns = ns || {}, ns2 = ns2 || {};
03
04 // the module/namespace creator
05 var creator = function(val){
06 var val = val || 0;
07
08 this.next = function(){
09 return val++
10 };
11
12 this.reset = function(){
13 val = 0;
14 }
15 }
16
17 creator.call(ns);
18 // ns.next, ns.reset now exist
19 creator.call(ns2, 5000);
20 // ns2 contains the same methods
21 // but has an overridden value for val
22 // of 5000

As mentioned, this type of pattern is useful for assigning a similar base set of
functionality to multiple modules or namespaces, but I'd really only suggest
using it where explicitly declaring your functionality within an object/closure
for direct access doesn't make sense.

Reviewing the namespace patterns above, the option that I would personally
use for most larger applications is nested object namespacing with the object
literal pattern.

IIFEs and single global variables may work fine for applications in the small to
medium range, however, larger codebases requiring both namespaces and
deep sub-namespaces require a succinct solution that promotes readability and
scales. I feel this pattern achieves all of these objectives well.

I would also recommend trying out some of the suggested advanced utility

102 de 184 22/03/12 11:43


methods for namespace extension as they really can save you time in the
long-run.

Flyweight

The Flyweight pattern is considered a useful classical solution for code that's
repetitive, slow and inefficient - for example: situations where we might create
a large number of similar objects.

It's of particular use in JavaScript where code that's complex in nature may
easily use all of the available memory, causing a number of performance
issues. Interestingly, it's been quite underused in recent years. Given how
reliant we are on JavaScript for the applications of today, both performance and
scalability are often paramount and this pattern (when applied correctly) can
assist with improving both.

To give you some quick historical context, the pattern is named after the
boxing weight class that includes fighters weighing less than 112lb - Poncho
Villa being the most famous fighter in this division. It derives from this weight
classification as it refers to the small amount of weight (memory) used.

Flyweights are an approach to taking several similar objects and placing that
shared information into a single external object or structure. The general idea
is that (in theory) this reduces the resources required to run an overall
application. The flyweight is also a structural pattern, meaning that it aims to
assist with both the structure of your objects and the relationships between
them.

So, how do we apply it to JavaScript?

There are two ways in which the Flyweight pattern can be applied. The first is
on the data-layer, where we deal with the concept of large quantities of similar
objects stored in memory. The second is on the DOM-layer where the flyweight
can be used as a central event-manager to avoid attaching event handlers to
every child element in a parent container you wish to have some similar
behaviour.

103 de 184 22/03/12 11:43


As the data-layer is where the flyweight pattern is most used traditionally, we'll
take a look at this first.

Flyweight and the data layer
For this application, there are a few more concepts around the classical
flyweight pattern that we need to be aware of. In the Flyweight pattern there's
a concept of two states - intrinsic and extrinsic. Intrinsic information may be
required by internal methods in your objects which they absolutely can't
function without. Extrinsic information can however be removed and stored
externally.

Objects with the same intrinsic data can be replaced with a single shared
object, created by a factory method, meaning we're able to reduce the overall
quantity of objects down significantly. The benefit of this is that we're able to
keep an eye on objects that have already been instantiated so that new copies
are only ever created should the intrinsic state differ from the object we
already have.

We use a manager to handle the extrinsic states. How this is implemented can
vary, however as Dustin Diaz correctly points out in Pro JavaScript Design
patterns, one approach to this to have the manager object contain a central
database of the extrinsic states and the flyweight objects which they belong to.

Converting code to use the Flyweight pattern
Let's now demonstrate some of these concepts using the idea of a system to
manage all of the books in a library. The important meta-data for each book
could probably be broken down as follows:

ID
Title
Author
Genre
Page count
Publisher ID
ISBN

We'll also require the following properties to keep track of which member has
checked out a particular book, the date they've checked it out on as well as the

104 de 184 22/03/12 11:43


expected date of return.

checkoutDate
checkoutMember
dueReturnDate
availability

Each book would thus be represented as follows, prior to any optimization:

01 var Book = function( id, title, author, genre, pageCount,publisherID,
ISBN, checkoutDate, checkoutMember, dueReturnDate,availability ){
02 this.id = id;
03 this.title = title;
04 this.author = author;
05 this.genre = genre;
06 this.pageCount = pageCount;
07 this.publisherID = publisherID;
08 this.ISBN = ISBN;
09 this.checkoutDate = checkoutDate;
10 this.checkoutMember = checkoutMember;
11 this.dueReturnDate = dueReturnDate;
12 this.availability = availability;
13 };
14 Book.prototype = {
15 getTitle:function(){
16 return this.title;
17 },
18 getAuthor: function(){
19 return this.author;
20 },
21 getISBN: function(){
22 return this.ISBN;
23 },
24 /*other getters not shown for brevity*/
25 updateCheckoutStatus: function(bookID, newStatus,
checkoutDate,checkoutMember, newReturnDate){
26 this.id = bookID;
27 this.availability = newStatus;
28 this.checkoutDate = checkoutDate;
29 this.checkoutMember = checkoutMember;
30 this.dueReturnDate = newReturnDate;
31 },
32 extendCheckoutPeriod: function(bookID, newReturnDate){
33 this.id = bookID;
34 this.dueReturnDate = newReturnDate;
35 },
36 isPastDue: function(bookID){
37 var currentDate = new Date();
38 return currentDate.getTime() > Date.parse(this.dueReturnDate);
39 }
40 };

This probably works fine initially for small collections of books, however as the

105 de 184 22/03/12 11:43


library expands to include a larger inventory with multiple versions and copies
of each book available, you'll find the management system running slower and
slower over time. Using thousands of book objects may overwhelm the
available memory, but we can optimize our system using the flyweight pattern
to improve this.

We can now separate our data into intrinsic and extrinsic states as follows:
data relevant to the book object (title, author etc) is intrinsic whilst the
checkout data (checkoutMember, dueReturnDate etc) is considered extrinsic.
Effectively this means that only one Book object is required for each
combination of book properties. It's still a considerable quantity of objects, but
significantly fewer than we had previously.

The following single instance of our book meta-data combinations will be
shared among all of the copies of a book with a particular title.

1 /*flyweight optimized version*/
2 var Book = function(title, author, genre, pageCount, publisherID, ISBN){
3 this.title = title;
4 this.author = author;
5 this.genre = genre;
6 this.pageCount = pageCount;
7 this.publisherID = publisherID;
8 this.ISBN = ISBN;
9 };

As you can see, the extrinsic states have been removed. Everything to do with
library check-outs will be moved to a manager and as the object's data is now
segmented, a factory can be used for instantiation.

A Basic Factory
Let's now define a very basic factory. What we're going to have it do is perform
a check to see if a book with a particular title has been previously created
inside the system. If it has, we'll return it. If not, a new book will be created
and stored so that it can be accessed later. This makes sure that we only create
a single copy of each unique intrinsic piece of data:

01 /*Book Factory singleton */
02 var BookFactory = (function(){
03 var existingBooks = {};
04 return{
05 createBook: function(title, author,
genre,pageCount,publisherID,ISBN){
06 /*Find out if a particular book meta-data combination has been
created before*/
07 var existingBook = existingBooks[ISBN];

106 de 184 22/03/12 11:43


08 if(existingBook){
09 return existingBook;
10 }else{
11 /*if not, let's create a new instance of it and store
it*/
12 var book = new Book(title, author,
genre,pageCount,publisherID,ISBN);
13 existingBooks[ISBN] = book;
14 return book;
15 }
16 }
17 }
18 });

Managing the extrinsic states
Next, we need to store the states that were removed from the Book objects
somewhere - luckily a manager (which we'll be defining as a singleton) can be
used to encapsulate them. Combinations of a Book object and the library
member that's checked them out will be called Book records. Our manager will
be storing both and will also include checkout related logic we stripped out
during our flyweight optimization of the Book class.

01 /*BookRecordManager singleton*/
02 var BookRecordManager = (function(){
03 var bookRecordDatabase = {};
04 return{
05 /*add a new book into the library system*/
06 addBookRecord: function(id, title, author,
genre,pageCount,publisherID,ISBN, checkoutDate, checkoutMember,
dueReturnDate, availability){
07 var book = bookFactory.createBook(title, author,
genre,pageCount,publisherID,ISBN);
08 bookRecordDatabase[id] ={
09 checkoutMember: checkoutMember,
10 checkoutDate: checkoutDate,
11 dueReturnDate: dueReturnDate,
12 availability: availability,
13 book: book;
14
15 };
16 },
17 updateCheckoutStatus: function(bookID, newStatus, checkoutDate,
checkoutMember, newReturnDate){
18 var record = bookRecordDatabase[bookID];
19 record.availability = newStatus;
20 record.checkoutDate = checkoutDate;
21 record.checkoutMember = checkoutMember;
22 record.dueReturnDate = newReturnDate;
23 },
24 extendCheckoutPeriod: function(bookID, newReturnDate){
25 bookRecordDatabase[bookID].dueReturnDate = newReturnDate;
26 },
27 isPastDue: function(bookID){
28 var currentDate = new Date();

107 de 184 22/03/12 11:43


29 return currentDate.getTime() >
Date.parse(bookRecordDatabase[bookID].dueReturnDate);
30 }
31 };
32 });

The result of these changes is that all of the data that's been extracted from
the Book 'class' is now being stored in an attribute of the BookManager
singleton (BookDatabase) which is considerable more efficient than the large
number of objects we were previously using. Methods related to book
checkouts are also now based here as they deal with data that's extrinsic
rather than intrinsic.

This process does add a little complexity to our final solution, however it's a
small concern when compared to the performance issues that have been
tackled.

Data wise, if we have 30 copies of the same book, we are now only storing it
once. Also, every function takes up memory. With the flyweight pattern these
functions exist in one place (on the manager) and not on every object, thus
saving more memory.

The Flyweight pattern and the DOM
In JavaScript, functions are effectively object descriptors and all functions are
also JavaScript objects internally. The goal of the pattern here is thus to make
triggering objects have little to no responsibility for the actions they perform
and to instead abstract this responsibility up to a global manager. One of the
best metaphors for describing the pattern was written by Gary Chisholm and it
goes a little like this:

Try to think of the flyweight in terms of a pond. A fish opens its mouth (the
event), bubbles raise to the surface (the bubbling) a fly sitting on the top flies
away when the bubble reaches the surface (the action). In this example you
can easily transpose the fish opening its mouth to a button being clicked, the
bubbles as the bubbling effect and the fly flying away to some function being
run'.

As jQuery is accepted as one of the best options for DOM-manipulation and
selection, we'll be using it for our DOM-related examples.

Example 1: Centralized event handling

108 de 184 22/03/12 11:43


For our first pratical example, consider scenarios where you may have a
number of similar elements or structures on a page that share similar
behaviour when a user-action is performed against them.

In JavaScript, there's a known bubbling effect in the language so that if an
element such as a link or button is clicked, that event is bubbled up to the
parent, informing them that something lower down the tree has been clicked.
We can use this effect to our advantage.

Normally what you might do when constructing your own accordion
component, menu or other list-based widget is bind a click event to each link
element in the parent container. Instead of binding the click to multiple
elements, we can easily attach a flyweight to the top of our container which
can listen for events coming from below. These can then be handled using as
simple or as complex logic needed.

The benefit here is that we're converting many independent objects into a few
shared ones (potentially saving on memory), similar to what we were doing
with our first JavaScript example.

As the types of components mentioned often have the same repeating markup
for each section (e.g. each section of an accordion), there's a good chance the
behaviour of each element that may be clicked is going to be quite similar and
relative to similar classes nearby. We'll use this information to construct a very
basic accordion using the flyweight below.

A stateManager namespace is used here encapsulate our flyweight logic whilst
jQuery is used to bind the initial click to a container div. In order to ensure that
no other logic on the page is attaching similar handles to the container, an
unbind event is first applied.

Now to establish exactly what child element in the container is clicked, we
make use of a target check which provides a reference to the element that was
clicked, regardless of its parent. We then use this information to handle the
click event without actually needing to bind the event to specific children when
our page loads.

HTML

01 <div id="container">
02 <div class="toggle" href="#">More Info (Address)
03 <span class="info">
04 This is more information

109 de 184 22/03/12 11:43


05 </span></div>
06 <div class="toggle" href="#">Even More Info (Map)
07 <span class="info">
08 <iframe src="http://www.map-generator.net
/extmap.php?name=London&address=london%2C%20england&
amp;width=500...gt;"</iframe>
09 </span>
10 </div>
11 </div>

JAVASCRIPT

01 stateManager = {
02 fly: function(){
03 var self = this;
04 $('#container').unbind().bind("click", function(e){
05 var target = $(e.originalTarget || e.srcElement);
06 if(target.is("div.toggle")){
07 self.handleClick(target);
08 }
09 });
10 },
11
12 handleClick: function(elem){
13 elem.find('span').toggle('slow');
14 }
15 });

Example 2: Using the Flyweight for
Performance Gains
In our second example, we'll reference some useful performance gains you can
get from applying the flyweight pattern to jQuery.

James Padolsey previously wrote a post called '76 bytes for faster jQuery'
where he reminds us of an important point: every time jQuery fires off a
callback, regardless of type (filter, each, event handler), you're able to access
the function's context (the DOM element related to it) via the this keyword.

Unfortunately, many of us have become used to the idea of wrapping this in $()
or jQuery(), which means that a new instance of jQuery is constructed every
time.

Rather than doing this:

1 $('div').bind('click', function(){
2 console.log('You clicked: ' + $(this).attr('id'));
3 });
4 you should avoid using the DOM element to create a jQuery object (with
the overhead that comes with it) and just use the DOM element itself
like this:
5

110 de 184 22/03/12 11:43


7 console.log('You clicked: ' + this.id);
8 });

Now with respect to redundant wrapping, where possible with jQuery's utility
methods, it's better to use jQuery.N as opposed to jQuery.fn.N where N
represents a utility such as each. Because not all of jQuery's methods have
corresponding single-node functions, Padolsey devised the idea of
jQuery.single.

The idea here is that a single jQuery object is created and used for each call to
jQuery.single (effectively meaning only one jQuery object is ever created). The
implementation for this can be found below and is a flyweight as we're
consolidating multiple possible objects into a more central singular structure.

01 jQuery.single = (function(o){
02
03 var collection = jQuery([1]);
04 return function(element) {
05
06 // Give collection the element:
07 collection[0] = element;
08
09 // Return the collection:
10 return collection;
11
12 };
13 });

An example of this in action with chaining is:

2 var html = jQuery.single(this).next().html();
3 console.log(html);
4 });

Note that although we may believe that simply caching our jQuery code may
offer just as equivalent performance gains, Padolsey claims that $.single() is
still worth using and can perform better. That's not to say don't apply any
caching at all, just be mindful that this approach can assist. For further details
about $.single, I recommend reading Padolsey's full post.

Modules

In this section we're going to continue our exploration of the Module pattern

111 de 184 22/03/12 11:43


and the broader concept of a 'module'.

Modules are an integral piece of any robust application's architecture and
typically help in keeping the code for a project organized. In JavaScript, there
are several options for implementing modules including both the well-known
module pattern as well as object literal notation.

Object Literals
The module pattern is based in part on object literals and so it makes sense to
review them first. In object literal notation, an object is described as a set of
comma-separated name/value pairs enclosured in curly braces ({}). Names
inside the object may be either strings or identifiers that are followed by a
colon. There should be no comma used after the final name/value pair in the
object as this may result in errors.

Object literals don't require instantiation using the new operator but shouldn't
be used at the start of a statement as the opening { may be interpreted as the
beginning of a block. Below you can see an example of a module defined using
object literal syntax.

New members may be added to the object using assignment as follows
myModule.property = 'someValue';

01 var myModule = {
02 myProperty : 'someValue',
03 // object literals can contain properties and methods.
04 // here, another object is defined for configuration
05 // purposes:
06 myConfig:{
07 useCaching:true,
08 language: 'en'
09 },
10 // a very basic method
11 myMethod: function(){
12 console.log('I can haz functionality?');
13 },
14 // output a value based on current configuration
15 myMethod2: function(){
16 console.log('Caching is:' +
(this.myConfig.useCaching)?'enabled':'disabled');
17 },
18 // override the current configuration
19 myMethod3: function(newConfig){
20 if(typeof newConfig == 'object'){
21 this.myConfig = newConfig;
22 console.log(this.myConfig.language);
23 }
24 }

112 de 184 22/03/12 11:43


25 };
26
27 myModule.myMethod(); //I can haz functionality
28 myModule.myMethod2(); //outputs enabled
29 myModule.myMethod3({language:'fr',useCaching:false}); //fr

Using object literals can assist in encapsulating and organizing your code and
Rebecca Murphey has previously written about this topic in depth should you
wish to read into object literals further.

That said, if you're opting for this technique, you may be equally as interested
in the module pattern. It still uses object literals but only as the return value
from a scoping function.

The Module Pattern
As we reviewed earlier in the book, the module pattern encapsulates 'privacy',
state and organization using closures. It provides a way of wrapping a mix of
public and private methods and variables, protecting pieces from leaking into
the global scope and accidentally colliding with another developer's interface.
With this pattern, only a public API is returned, keeping everything else within
the closure private.

This gives us a clean solution for shielding logic doing the heavy lifting whilst
only exposing an interface you wish other parts of your application to use. The
pattern is quite similar to an immediately-invoked functional expression (IIFE)
except that an object is returned rather than a function.

From a historical perspective, the module pattern was originally developed by a
number of people including Richard Cornford in 2003. It was later popularized
by Douglas Crockford in his lectures and re-introduced by Eric Miraglia on the
YUI blog.

Below you can see an example of a shopping basket implemented using this
pattern. The module itself is completely self-contained in a global variable
called basketModule. The basket array in the module is kept private and so other
parts of your application are unable to directly read it. It only exists with the
module's closure and so the only methods able to access it are those with
access to its scope (ie. addItem(), getItem() etc).

01 var basketModule = (function() {
02 var basket = []; //private
03 function doSomethingPrivate(){
04 //...

113 de 184 22/03/12 11:43


05 }
06
07 function doSomethingElsePrivate(){
08 //...
09 }
10 return { //exposed to public
11 addItem: function(values) {
12 basket.push(values);
13 },
14 getItemCount: function() {
15 return basket.length;
16 },
17 doSomething: doSomethingPrivate(),
18 getTotal: function(){
19 var q = this.getItemCount(),p=0;
20 while(q--){
21 p+= basket[q].price;
22 }
23 return p;
24 }
25 }
26 }());

Inside the module, you'll notice we return an object. This gets automatically
assigned to basketModule so that you can interact with it as follows:

01 //basketModule is an object with properties which can also be methods
02 basketModule.addItem({item:'bread',price:0.5});
03 basketModule.addItem({item:'butter',price:0.3});
04
05 console.log(basketModule.getItemCount());
06 console.log(basketModule.getTotal());
07
08 //however, the following will not work:
09 console.log(basketModule.basket);// (undefined as not inside the
returned object)
10 console.log(basket); //(only exists within the scope of the closure)

The methods above are effectively namespaced inside basketModule.

Notice how the scoping function in the above basket module is wrapped
around all of our functions, which we then call and immediately store the
return value of. This has a number of advantages including:

The freedom to have private functions which can only be consumed by our
module. As they aren't exposed to the rest of the page (only our exported API
is), they're considered truly private.
Given that functions are declared normally and are named, it can be easier to
show call stacks in a debugger when we're attemping to discover what
function(s) threw an exception.
As T.J Crowder has pointed out in the past, it also enables us to return

114 de 184 22/03/12 11:43


different functions depending on the environment. In the past, I've seen
developers use this to perform UA testing in order to provide a code-path in
their module specific to IE, but we can easily opt for feature detection these
days to achieve a similar goal.

It should be noted that there isn't really an explicitly true sense of 'privacy'
inside JavaScript because unlike some traditional languages, it doesn't have
access modifiers. Variables can't technically be declared as being public nor
private and so we use function scope to simulate this concept. Within the
module pattern, variables or methods declared are only available inside the
module itself thanks to closure. Variables or methods defined within the
returning object however are available to everyone.

How about the module pattern implemented in specific toolkits or frameworks?

Dojo

Dojo provides a convenience method for working with objects called
dojo.setObject(). This takes as it's first argument a dot-separated string such as
myObj.parent.child which refers to a property called 'child' within an object
'parent' defined inside 'myObj'. Using setObject() allows us to set the value of
children, creating any of the intermediate objects in the rest of the path passed
if they don't already exist.

For example, if we wanted to declare basket.core as an object of the store
namespace, this could be achieved as follows using the traditional way:

1 var store = window.store || {};
2 if(!store["basket"]){ store.basket = {}; }
3 if(!store.basket["core"]){ store.basket.core={}; }
4
5 store.basket.core = {
6 // ...rest of our logic
7 }

Or as follows using Dojo 1.7 (AMD-compatible version) and above:

01 require(["dojo/_base/customStore"], function(store){
02
03 // using dojo.setObject()
04 customStore.setObject("basket.core", (function() {
05 var basket = [];
06 function privateMethod() {
07 console.log(basket);
08 }

115 de 184 22/03/12 11:43


09 return {
11 privateMethod();
12 }
13 };
14 }()), store);
15
16 });

For more information on dojo.setObject(), see the official documentation.

ExtJS

For those using Sencha's ExtJS, you're in for some luck as the official
documentation incorporates examples that do demonstrate how to correctly
use the module pattern with the framework.

Below we can see an example of how to define a namespace which can then be
populated with a module containing both a private and public API. With the
exception of some semantic differences, it's quite close to how the module
pattern is implemented in vanilla JavaScript:

01 // create namespace
02 Ext.namespace('myNameSpace');
03
04 // create application
05 myNameSpace.app = function() {
06 // do NOT access DOM from here; elements don't exist yet
07
08 // private variables
09 var btn1;
10 var privVar1 = 11;
11
12 // private functions
13 var btn1Handler = function(button, event) {
14 alert('privVar1=' + privVar1);
15 alert('this.btn1Text=' + this.btn1Text);
16 };
17
18 // public space
19 return {
20 // public properties, e.g. strings to translate
21 btn1Text: 'Button 1',
22
23 // public methods
24 init: function() {
25 if (Ext.Ext2) {
26 btn1 = new Ext.Button({
27 renderTo: 'btn1-ct',
28 text: this.btn1Text,
29 handler: btn1Handler
30 });
31 } else {
32 btn1 = new Ext.Button('btn1-ct', {

116 de 184 22/03/12 11:43


33 text: this.btn1Text,
34 handler: btn1Handler
35 });
36 }
37 }
38 };
39 }(); // end of app

YUI

Similarly, we can also implement the module pattern when building
applications using YUI. The following example is heavily based on the original
YUI module pattern implementation by Eric Miraglia, but again, isn't vastly
different from the vanilla JavaScript version:

01 YAHOO.store.basket = function () {
02
03 //"private" variables:
04 var myPrivateVar = "I can be accessed only within YAHOO.store.basket
.";
05
06 //"private" method:
07 var myPrivateMethod = function () {
08 YAHOO.log("I can be accessed only from within
YAHOO.store.basket");
09 }
10
11 return {
12 myPublicProperty: "I'm a public property.",
13 myPublicMethod: function () {
14 YAHOO.log("I'm a public method.");
15
16 //Within basket, I can access "private" vars and methods:
17 YAHOO.log(myPrivateVar);
18 YAHOO.log(myPrivateMethod());
19
20 //The native scope of myPublicMethod is store so we can
21 //access public members using "this":
22 YAHOO.log(this.myPublicProperty);
23 }
24 };
25
26 }();

jQuery

There are a number of ways in which jQuery code unspecific to plugins can be
wrapped inside the module pattern. Ben Cherry previously suggested an
implementation where a function wrapper is used around module definitions in
the event of there being a number of commonalities between modules.

117 de 184 22/03/12 11:43


In the following example, a library function is defined which declares a new
library and automatically binds up the init function to document.ready when new
libraries (ie. modules) are created.

01 function library(module) {
02 $(function() {
03 if (module.init) {
04 module.init();
05 }
06 });
07 return module;
08 }
09
10 var myLibrary = library(function() {
11 return {
13 /*implementation*/
14 }
15 };
16 }());

For further reading on the module pattern, see Ben Cherry's article on it here.

Examples Of Design Patterns in jQuery

Now that we've taken a look at vanilla-JavaScript implementations of popular
design patterns, let's switch gears and find out what of these design patterns
might look like when implemented using jQuery. jQuery (as you may know) is
currently the most popular JavaScript library and provides a layer of 'sugar' on
top of regular JavaScript with a syntax that can be easier to understand at a
glance.

Before we dive into this section, it's important to remember that many vanilla-
JavaScript design patterns can be intermixed with jQuery when used correctly
because jQuery is still essentially JavaScript itself.

jQuery is an interesting topic to discuss in the realm of patterns because the
library actually uses a number of design patterns itself. What impresses me is
just how cleanly all of the patterns it uses have been implemented so that they
exist in harmony.

118 de 184 22/03/12 11:43


Let's take a look at what some of these patterns are and how they are used.

Module Pattern

We have already explored the module pattern previously, but in case you've
skipped ahead: the Module Pattern allows us to encapsulate logic for a unit
of code such that we can have both private and public methods and variables.
This can be applied to writing jQuery plugins too, where a private API holds any
code we don't wish to expose and a public API contains anything a user will be
allowed to interact with. See below for an example:

01 !function(exports, $, undefined){
02
03 var Plugin = function(){
04
05 // Our private API
06 var priv = {},
07
08 // Our public API
09 Plugin = {},
10
11 // Plugin defaults
12 defaults = {};
13
14 // Private options and methods
15 priv.options = {};
16 priv.method1 = function(){};
17 priv.method2 = function(){};
18
19 // Public methods
20 Plugin.method1 = function(){...};
21 Plugin.method2 = function(){...};
22
23 // Public initialization
24 Plugin.init = function(options) {
25 $.extend(priv.options, defaults, options);
26 priv.method1();
27 return Plugin;
28 }
29
30 // Return the Public API (Plugin) we want
31 // to expose
32 return Plugin;
33 }
34
35
36 exports.Plugin = Plugin;
37
38 }(this, jQuery);

119 de 184 22/03/12 11:43


This can then be used as follows:

1 var myPlugin = new Plugin;
2 myPlugin.init(/* custom options */);
3 myPlugin.method1();

Lazy Initialization

Lazy Initialization is a design pattern wish allows us to delay expensive
processes (eg. the creation of objects) until the first instance they are needed.
An example of this is the .ready() function in jQuery that only executes a
function once the DOM is ready.

01 $(document).ready(function(){
02 // The ajax request won't attempt to execute until
03 // the DOM is ready
04
05 var jqxhr = $.ajax({
06 url: 'http://domain.com/api/',
07 data: 'display=latest&order=ascending'
08 })
09 .done(function( data )){
10 $('.status').html('content loaded');
11 console.log( 'Data output:' + data );
12 });
13 });

Whilst it isn't directly used in jQuery core, some developers will be familiar
with the concept of LazyLoading via plugins such as this. LazyLoading is
effectively the same as Lazy initialization and is a technique whereby
additional data on a page is loaded when needed (e.g when a user has scrolled
to the end of the page). In recent years this pattern has become quite
prominent and can be currently be found in both the Twitter and Facebook UIs.

The Composite Pattern

The Composite Pattern describes a group of objects that can be treated in
the same way a single instance of an object may be. Implementing this pattern
allows you to treat both individual objects and compositions in a uniform
manner. In jQuery, when we're accessing or performing actions on a single

120 de 184 22/03/12 11:43


DOM element or a collection of elements, we can treat both sets in a uniform
manner. This is demonstrated by the code sample below:

1 // Single elements
2 $('#singleItem').addClass('active');
3 $('#container').addClass('active');
4
5 // Collections of elements
6 $('div').addClass('active');
7 $('.item').addClass('active');
8 $('input').addClass('active');

The Wrapper Pattern

The Wrapper Pattern is a pattern which translates an interface for a class
into a an interface compatible with a specific system. Wrappers basically allow
classes to function together which normally couldn't due to their incompatible
interfaces. The wrapper translates calls to its interface into calls to the original
interface and the code required to achieve this is usually quite minimal.

One example of a wrapper you may have used is jQuery's $(el).css() method.
Not only does it help normalize the interfaces to how styles can be applied
between a number of browsers, there are plenty of good examples of this,
including opacity.

1 /*
2 Cross browser opacity:
3 opacity: 0.9; Chrome 4+, FF2+, Saf3.1+, Opera 9+, IE9, iOS 3.2+,
Android 2.1+
4 filter: alpha(opacity=90); IE6-IE8
5 */
6
7 $('.container').css({ opacity: .5 });

The Facade Pattern

As we saw in earlier sections, the Facade Pattern is where an object provides
a simpler interface to a larger (possibly more complex) body of code. Facades
can be frequently found across the jQuery library and make methods both

121 de 184 22/03/12 11:43


easier to use and understand, but also more readable. The following are
facades for jQuery's $.ajax():

1 $.get( url, data, callback, dataType );
2 $.post( url, data, callback, dataType );
3 $.getJSON( url, data, callback );
4 $.getScript( url, callback );

These are translated behind the scenes to:

01 // $.get()
02 $.ajax({
03 url: url,
04 data: data,
05 dataType: dataType
06 }).done( callback );
07
08 // $.post
09 $.ajax({
10 type: 'POST',
11 url: url,
12 data: data,
13 dataType: dataType
15
16 // $.getJSON()
17 $.ajax({
18 url: url,
19 dataType: 'json',
20 data: data,
22
23 // $.getScript()
24 $.ajax({
25 url: url,
26 dataType: "script",

What's even more interesting is that the above facades are actually facades in
their own right. You see, $.ajax offers a much simpler interface to a complex
body of code that handles cross-browser XHR (XMLHttpRequest) as well as
deferreds. While I could link you to the jQuery source, here's a cross-browser
XHR implementation just so you can get an idea of how much easier this
pattern makes our lives.

The Observer Pattern

122 de 184 22/03/12 11:43


Another pattern we've look at previously is the Observer (Publish/Subscribe)
pattern, where a subject (the publisher), keeps a list of its dependants
(subscribers), and notifies them automatically anytime something interesting
happens.

jQuery actually comes with built-in support for a publish/subscribe-like system,
which it calls custom events. In earlier versions of the library, access to these
custom events was possible using .bind() (subscribe), .trigger() (publish) and
.unbind() (unsubscribe), but in recent versions this can be done using .on(),
.trigger() and .off().

Below we can see an example of this being used in practice:

01 // Equivalent to subscribe(topicName, callback)
02 $(document).on('topicName', function(){
03 //..perform some behaviour
04 });
05
06 // Equivalent to publish(topicName)
07 $(document).trigger('topicName');
08
09 // Equivalent to unsubscribe(topicName)
10 $(document).off('topicName');

For those that prefer to use the conventional naming scheme for the Observer
pattern, Ben Alman created a simple wrapper around the above methods which
gives you access to $.publish(), $.subscribe and $.unsubscribe methods. I've
previously linked to them earlier in the book, but you can see the wrapper in
full below.

01 (function($) {
02
03 var o = $({});
04
05 $.subscribe = function() {
06 o.on.apply(o, arguments);
07 };
08
09 $.unsubscribe = function() {
10 o.off.apply(o, arguments);
11 };
12
13 $.publish = function() {
14 o.trigger.apply(o, arguments);
15 };
16
17 }(jQuery));

Finally, in recent versions of jQuery, a multi-purpose callbacks object
($.Callbacks) was made available to enable users to write new solutions based

123 de 184 22/03/12 11:43


on callback lists. One such solution it's possible to write using this feature is
another Publish/Subscribe system. An implementation of this is the following:

01 var topics = {};
02
03 jQuery.Topic = function( id ) {
04 var callbacks,
05 topic = id && topics[ id ];
06 if ( !topic ) {
07 callbacks = jQuery.Callbacks();
08 topic = {
09 publish: callbacks.fire,
10 subscribe: callbacks.add,
11 unsubscribe: callbacks.remove
12 };
13 if ( id ) {
14 topics[ id ] = topic;
15 }
16 }
17 return topic;
18 };

which can then be used as follows:

01 // Subscribers
02 $.Topic( 'mailArrived' ).subscribe( fn1 );
03 $.Topic( 'mailArrived' ).subscribe( fn2 );
04 $.Topic( 'mailSent' ).subscribe( fn1 );
05
06 // Publisher
07 $.Topic( 'mailArrived' ).publish( 'hello world!' );
08 $.Topic( 'mailSent' ).publish( 'woo! mail!' );
09
10 // Here, 'hello world!' gets pushed to fn1 and fn2
11 // when the 'mailArrived' notification is published
12 // with 'woo! mail!' also being pushed to fn1 when
13 // the 'mailSent' notification is published.
14 /*
15 output:
16 hello world!
17 fn2 says: hello world!
18 woo! mail!
19 */

The Iterator Pattern

The Iterator Pattern is a design pattern where iterators (objects that allow
us to traverse through all the elements of a collection) access the elements of
an aggregate object sequentially without needing to expose its underlying
form.

124 de 184 22/03/12 11:43


Iterators encapsulate the internal structure of how that particular iteration
occurs - in the case of jQuery's $(el).each() iterator, you are actually able to use
the underlying code behind $.each() to iterate through a collection, without
needing to see or understand the code working behind the scenes that's
providing this capability. This is a pattern similar to the facade, except it deals
explicitly with iteration.

1 $.each(['john','dave','rick','julian'], function(index, value) {
2 console.log(index + ': ' + value);
3 });
4
5 $('li').each(function(index) {
6 console.log(index + ': ' + $(this).text());
7 });
8

The Strategy Pattern

The Strategy Pattern is a pattern where a script may select a particular
algorithm at runtime. The purpose of this pattern is that it's able to provide a
way to clearly define families of algorithms, encapsulate each as an object and
make them easily interchangeable. You could say that the biggest benefit this
pattern offers is that it allows algorithms to vary independent of the clients that
utilize them.

An example of this is where jQuery's toggle() allows you to bind two or more
handlers to the matched elements, to be executed on alternate clicks.The
strategy pattern allows for alternative algorithms to be used independent of the
client internal to the function.

1 $('button').toggle(function(){
2 console.log('path 1');
3 },
4 function(){
5 console.log('path 2');
6 });

The Proxy Pattern

125 de 184 22/03/12 11:43


The Proxy Pattern - a proxy is basically a class that functions as an interface
to something else: a file, a resource, an object in memory, something else that
is difficult to duplicate etc. jQuery's .proxy() method takes as input a function
and returns a new one that will always have a particular context - it ensures
that the value of this in a function is the value you desire. This is parallel to the
idea of providing an interface as per the proxy pattern.

One example of where this is useful is when you're making use of a timer
inside a click handler. Say we have the following handler:

1 $('button').on('click', function(){
2 // Within this function, 'this' refers to the element that was clicked
3 $(this).addClass('active');
4 });

However, say we wished to add in a delay before the active class was added.
One thought that comes to mind is using setTimeout to achieve this, but there's a
slight problem here: whatever function is passed to setTimeout will have a
different value for this inside that function (it will refer to window instead).

3 // 'this' doesn't refer to our element!
5 });
6 });

To solve this problem, we can use $.proxy(). By calling it with the function and
value we would like assisnged to this it will actally return a function that
retains the value we desire. Here's how this would look:

2 setTimeout($.proxy(function() {
3 // 'this' now refers to our element as we wanted
5 }, this), 500);
6 // the last 'this' we're passing tells $.proxy() that our DOM
element
7 // is the value we want 'this' to refer to.
8 });

The Builder Pattern

126 de 184 22/03/12 11:43


The Builder Pattern's general idea is that it abstracts the steps involved in
creating objects so that different implementations of these steps have the
ability to construct different representations of objects. Below are examples of
how jQuery utilizes this pattern to allow you to dynamically create new
elements.

1 $('<div class= "foo">bar</div>');
2
3 $('<p id="test">foo <em>bar</em></p>').appendTo('body');
4
5 var newParagraph = $('<p />').text("Hello world");
6
7 $('<input />').attr({'type':'text', 'id':'sample'})
8 .appendTo('#container');

The Prototype Pattern

As we've seen, the Prototype Pattern is used when objects are created based
on a template of an existing object through cloning. Essentially this pattern is
used to avoid creating a new object in a more conventional manner where this
process may be expensive or overly complex.

In terms of the jQuery library, your first thought when cloning is mentioned
might be the .clone() method. Unfortunately this only clones DOM elements
but if we want to clone JavaScript objects, this can be done using the $.extend()
method as follows:

1 var myOldObject = {};
2
3 // Create a shallow copy
4 var myNewObject = jQuery.extend({}, myOldObject);
5
6 // Create a deep copy
7 var myOtherNewObject = jQuery.extend(true, {}, myOldObject);

This pattern has used many times in jQuery core (as well as in jQuery plugins)
quite successfully. For those wondering what deep cloning might look like in
JavaScript without the use of a library, Rick Waldron has an implementation
you can use below (and tests available here).

01 function clone( obj ) {
02 var val, length, i,
03 temp = [];

127 de 184 22/03/12 11:43


04
05 if ( Array.isArray(obj) ) {
06 for ( i = 0, length = obj.length; i < length; i++ ) {
07 // Store reference to this array item's value
08 val = obj[ i ];
09
10 // If array item is an object (including arrays), derive new value
by cloning
11 if ( typeof val === "object" ) {
12 val = clone( val );
13 }
14 temp[ i ] = val;
15 }
16 return temp;
17 }
18
19 // Create a new object whose prototype is a new, empty object,
20 // Using the second properties object argument to copy the source
properties
21 return Object.create({}, (function( src ) {
22 // Initialize a cache for non-inherited properties
23 var props = {};
24
25 Object.getOwnPropertyNames( src ).forEach(function( name ) {
26 // Store short reference to property descriptor
27 var descriptor = Object.getOwnPropertyDescriptor( src, name );
28
29 // Recurse on properties whose value is an object or array
30 if ( typeof src[ name ] === "object" ) {
31 descriptor.value = clone( src[ name ] );
32 }
33 props[ name ] = descriptor;
34 });
35 return props;
36 }( obj )));
37 }

Modern Modular JavaScript Design
Patterns

The Importance Of Decoupling Your
Application
In the world of modern JavaScript, when we say an application is modular, we
often mean it's composed of a set of highly decoupled, distinct pieces of
functionality stored in modules. As you probably know, loose coupling
facilitates easier maintainability of apps by removing dependencies where
possible. When this is implemented efficiently, its quite easy to see how

128 de 184 22/03/12 11:43


changes to one part of a system may affect another.

Unlike some more traditional programming languages however, the current
iteration of JavaScript (ECMA-262) doesn't provide developers with the means
to import such modules of code in a clean, organized manner. It's one of the
concerns with specifications that haven't required great thought until more
recent years where the need for more organized JavaScript applications
became apparent.

Instead, developers at present are left to fall back on variations of the module
or object literal patterns, which we covered earlier in the book. With many of
these, module scripts are strung together in the DOM with namespaces being
described by a single global object where it's still possible to incur naming
collisions in your architecture. There's also no clean way to handle dependency
management without some manual effort or third party tools.

Whilst native solutions to these problems will be arriving in ES Harmony (the
next version of JavaScript), the good news is that writing modular JavaScript
has never been easier and you can start doing it today.

In this section, we're going to look at three formats for writing modular
JavaScript: AMD, CommonJS and proposals for the next version of JavaScript,
Harmony.

A Note On Script Loaders

It's difficult to discuss AMD and CommonJS modules without talking about the
elephant in the room - script loaders. At the time of writing, script loading is a
means to a goal, that goal being modular JavaScript that can be used in
applications today - for this, use of a compatible script loader is unfortunately
necessary. In order to get the most out of this section, I recommend gaining a
basic understanding of how popular script loading tools work so the
explanations of module formats make sense in context.

There are a number of great loaders for handling module loading in the AMD
and CommonJS formats, but my personal preferences are RequireJS and
curl.js. Complete tutorials on these tools are outside the scope of this article,
but I can recommend reading John Hann's article about curl.js and James
Burke's RequireJS API documentation for more.

From a production perspective, the use of optimization tools (like the RequireJS

129 de 184 22/03/12 11:43


optimizer) to concatenate scripts is recommended for deployment when
working with such modules. Interestingly, with the Almond AMD shim,
RequireJS doesn't need to be rolled in the deployed site and what you might
consider a script loader can be easily shifted outside of development.

That said, James Burke would probably say that being able to dynamically load
scripts after page load still has its use cases and RequireJS can assist with this
too. With these notes in mind, let's get started.

AMD A Format For Writing Modular JavaScript In The
Browser

The overall goal for the AMD (Asynchronous Module Definition) format is to
provide a solution for modular JavaScript that developers can use today. It was
born out of Dojo's real world experience using XHR+eval and proponents of
this format wanted to avoid any future solutions suffering from the
weaknesses of those in the past.

The AMD module format itself is a proposal for defining modules where both
the module and dependencies can be asynchronously loaded. It has a number
of distinct advantages including being both asynchronous and highly flexible by
nature which removes the tight coupling one might commonly find between
code and module identity. Many developers enjoy using it and one could
consider it a reliable stepping stone towards the module system proposed for
ES Harmony.

AMD began as a draft specification for a module format on the CommonJS list
but as it wasn't able to reach full concensus, further development of the format
moved to the amdjs group.

Today it's embraced by projects including Dojo (1.7), MooTools (2.0), Firebug
(1.8) and even jQuery (1.7). Although the term CommonJS AMD format has
been seen in the wild on occasion, it's best to refer to it as just AMD or Async
Module support as not all participants on the CommonJS list wished to pursue
it.

Note: There was a time when the proposal was referred to as Modules
Transport/C, however as the spec wasn't geared for transporting existing
CommonJS modules, but rather, for defining modules it made more sense to opt
for the AMD naming convention.
Getting Started With Modules

130 de 184 22/03/12 11:43


The two key concepts you need to be aware of here are the idea of a define
method for facilitating module definition and a require method for handling
dependency loading. define is used to define named or unnamed modules
based on the proposal using the following signature:

1 define(
2 module_id /*optional*/,
3 [dependencies] /*optional*/,
4 definition function /*function for instantiating the module or
object*/
5 );

As you can tell by the inline comments, the module_id is an optional argument
which is typically only required when non-AMD concatenation tools are being
used (there may be some other edge cases where it's useful too). When this
argument is left out, we call the module anonymous.

When working with anonymous modules, the idea of a module's identity is
DRY, making it trivial to avoid duplication of filenames and code. Because the
code is more portable, it can be easily moved to other locations (or around the
file-system) without needing to alter the code itself or change its ID. The
module_id is equivalent to folder paths in simple packages and when not used in
packages. Developers can also run the same code on multiple environments
just by using an AMD optimizer that works with a CommonJS environment
such as r.js.

Back to the define signature, the dependencies argument represents an array
of dependencies which are required by the module you are defining and the
third argument ('definition function' or 'factory function') is a function that's
executed to instantiate your module. A barebone module could be defined as
follows:

Understanding AMD: define()

01 // A module_id (myModule) is used here for demonstration purposes only
02
03 define('myModule',
04 ['foo', 'bar'],
05 // module definition function
06 // dependencies (foo and bar) are mapped to function parameters
07 function ( foo, bar ) {
08 // return a value that defines the module export
09 // (i.e the functionality we want to expose for consumption)
10
11 // create your module here
12 var myModule = {
13 doStuff:function(){

131 de 184 22/03/12 11:43


14 console.log('Yay! Stuff');
15 }
16 }
17
18 return myModule;
19 });
20
21 // An alternative example could be..
22 define('myModule',
23 ['math', 'graph'],
24 function ( math, graph ) {
25
26 // Note that this is a slightly different pattern
27 // With AMD, it's possible to define modules in a few
28 // different ways due as it's relatively flexible with
29 // certain aspects of the syntax
30 return {
31 plot: function(x, y){
32 return graph.drawPie(math.randomGrid(x,y));
33 }
34 }
35 };
36 });

require on the other hand is typically used to load code in a top-level JavaScript
file or within a module should you wish to dynamically fetch dependencies. An
example of its usage is:

Understanding AMD: require()

1 // Consider 'foo' and 'bar' are two external modules
2 // In this example, the 'exports' from the two modules loaded are passed
as
3 // function arguments to the callback (foo and bar)
4 // so that they can similarly be accessed
5
6 require(['foo', 'bar'], function ( foo, bar ) {
7 // rest of your code here
8 foo.doSomething();
9 });

Dynamically-loaded Dependencies

01 define(function ( require ) {
02 var isReady = false, foobar;
03
04 // note the inline require within our module definition
05 require(['foo', 'bar'], function (foo, bar) {
06 isReady = true;
07 foobar = foo() + bar();
08 });
09
10 // we can still return a module
11 return {
12 isReady: isReady,

132 de 184 22/03/12 11:43


13 foobar: foobar
14 };
15 });

Understanding AMD: plugins

The following is an example of defining an AMD-compatible plugin:

01 // With AMD, it's possible to load in assets of almost any kind
02 // including text-files and HTML. This enables us to have template
03 // dependencies which can be used to skin components either on
04 // page-load or dynamically.
05
06 define(['./templates', 'text!./template.md','css!./template.css'],
07 function( templates, template ){
08 console.log(templates);
09 // do some fun template stuff here.
10 }
11 });

Note: Although css! is included for loading CSS dependencies in the above
example, it's important to remember that this approach has some caveats such as
it not being fully possible to establish when the CSS is fully loaded. Depending on
how you approach your build, it may also result in CSS being included as a
dependency in the optimized file, so use CSS as a loaded dependency in such
cases with caution.
Loading AMD Modules Using RequireJS

1 require(['app/myModule'],
2 function( myModule ){
3 // start the main module which in-turn
4 // loads other modules
5 var module = new myModule();
6 module.doStuff();
7 });

This example could simply be looked at as requirejs(['app/myModule'], function(){})
which indicates the loader's top level globals are being used. This is how to
kick off top-level loading of modules with different AMD loaders however with
a define() function, if it's passed a local require all require([]) examples apply to
both types of loader (curl.js and RequireJS).

Loading AMD Modules Using curl.js

1 curl(['app/myModule.js'],
2 function( myModule ){
3 // start the main module which in-turn
4 // loads other modules
5 var module = new myModule();
6 module.doStuff();

133 de 184 22/03/12 11:43


7 });

Modules With Deferred Dependencies

01 // This could be compatible with jQuery's Deferred implementation,
02 // futures.js (slightly different syntax) or any one of a number
03 // of other implementations
04 define(['lib/Deferred'], function( Deferred ){
05 var defer = new Deferred();
06 require(['lib/templates/?index.html','lib/data/?stats'],
07 function( template, data ){
08 defer.resolve({ template: template, data:data });
09 }
10 );
11 return defer.promise();
12 });

Why Is AMD A Better Choice For Writing Modular JavaScript?

Provides a clear proposal for how to approach defining flexible modules.
Significantly cleaner than the present global namespace and <script> tag
solutions many of us rely on. There's a clean way to declare stand-alone
modules and dependencies they may have.
Module definitions are encapsulated, helping us to avoid pollution of the global
namespace.
Works better than some alternative solutions (eg. CommonJS, which we'll be
looking at shortly). Doesn't have issues with cross-domain, local or debugging
and doesn't have a reliance on server-side tools to be used. Most AMD loaders
support loading modules in the browser without a build process.
Provides a 'transport' approach for including multiple modules in a single file.
Other approaches like CommonJS have yet to agree on a transport format.
It's possible to lazy load scripts if this is needed.

Related Reading

The RequireJS Guide To AMD

What's the fastest way to load AMD modules?

AMD vs. CommonJS, what's the better format?

AMD Is Better For The Web Than CommonJS Modules

The Future Is Modules Not Frameworks

134 de 184 22/03/12 11:43


AMD No Longer A CommonJS Specification

On Inventing JavaScript Module Formats And Script Loaders

The AMD Mailing List

AMD Modules With Dojo

Defining AMD-compatible modules using Dojo is fairly straight-forward. As per
above, define any module dependencies in an array as the first argument and
provide a callback (factory) which will execute the module once the
dependencies have been loaded. e.g:

1 define(["dijit/Tooltip"], function( Tooltip ){
2 //Our dijit tooltip is now available for local use
3 new Tooltip(...);
4 });

Note the anonymous nature of the module which can now be both consumed
by a Dojo asynchronous loader, RequireJS or the standard dojo.require()
module loader that you may be used to using.

For those wondering about module referencing, there are some interesting
gotchas that are useful to know here. Although the AMD-advocated way of
referencing modules declares them in the dependency list with a set of
matching arguments, this isn't supported by the Dojo 1.6 build system - it really
only works for AMD-compliant loaders. e.g:

1 define(["dojo/cookie", "dijit/Tooltip"], function( cookie, Tooltip ){
2 var cookieValue = cookie("cookieName");
3 new Tree(...);
4 });

This has many advances over nested namespacing as modules no longer need
to directly reference complete namespaces every time - all we require is the
'dojo/cookie' path in dependencies, which once aliased to an argument, can be
referenced by that variable. This removes the need to repeatedly type out
'dojo.' in your applications.

Note: Although Dojo 1.6 doesn't officially support user-based AMD modules (nor
asynchronous loading), it's possible to get this working with Dojo using a number
of different script loaders. At present, all Dojo core and Dijit modules have been
transformed to the AMD syntax and improved overall AMD support will likely land

135 de 184 22/03/12 11:43


between 1.7 and 2.0.
The final gotcha to be aware of is that if you wish to continue using the Dojo
build system or wish to migrate older modules to this newer AMD-style, the
following more verbose version enables easier migration. Notice that dojo and
dijit and referenced as dependencies too:

1 define(["dojo", "dijit", "dojo/cookie", "dijit/Tooltip"], function(dojo,
dijit){
2 var cookieValue = dojo.cookie("cookieName");
3 new dijit.Tooltip(...);
4 });

AMD Module Design Patterns (Dojo)

If you've followed any of my previous posts on the benefits of design patterns,
you'll know that they can be highly effective in improving how we approach
structuring solutions to common development problems. John Hann recently
gave an excellent presentation about AMD module design patterns covering
the Singleton, Decorator, Mediator and others. I highly recommend checking
out his slides if you get a chance.

Some samples of these patterns can be found below:

Decorator pattern:

01 // mylib/UpdatableObservable: a decorator for dojo/store/Observable
02 define(['dojo', 'dojo/store/Observable'], function ( dojo, Observable )
{
03 return function UpdatableObservable ( store ) {
04
05 var observable = dojo.isFunction(store.notify) ? store :
06 new Observable(store);
07
08 observable.updated = function( object ) {
09 dojo.when(object, function ( itemOrArray) {
10 dojo.forEach( [].concat(itemOrArray), this.notify, this
);
11 };
12 };
13
14 return observable; // makes `new` optional
15 };
16 });
17
18
19 // decorator consumer
20 // a consumer for mylib/UpdatableObservable
21
22 define(['mylib/UpdatableObservable'], function ( makeUpdatable ) {
23 var observable, updatable, someItem;
24 // ... here be code to get or create `observable`

136 de 184 22/03/12 11:43


25
26 // ... make the observable store updatable
27 updatable = makeUpdatable(observable); // `new` is optional!
28
29 // ... later, when a cometd message arrives with new data item
30 updatable.updated(updatedItem);
31 });

Adapter pattern

01 // 'mylib/Array' adapts `each` function to mimic jQuery's:
02 define(['dojo/_base/lang', 'dojo/_base/array'], function (lang, array) {
03 return lang.delegate(array, {
04 each: function (arr, lambda) {
05 array.forEach(arr, function (item, i) {
06 lambda.call(item, i, item); // like jQuery's each
07 })
08 }
09 });
10 });
11
12 // adapter consumer
13 // 'myapp/my-module':
14 define(['mylib/Array'], function ( array ) {
15 array.each(['uno', 'dos', 'tres'], function (i, esp) {
16 // here, `this` == item
17 });
18 });

AMD Modules With jQuery

The Basics

Unlike Dojo, jQuery really only comes with one file, however given the
plugin-based nature of the library, we can demonstrate how straight-forward it
is to define an AMD module that uses it below.

01 define(['js/jquery.js','js/jquery.color.js','js/underscore.js'],
02 function($, colorPlugin, _){
03 // Here we've passed in jQuery, the color plugin and Underscore
04 // None of these will be accessible in the global scope, but we
05 // can easily reference them below.
06
07 // Pseudo-randomize an array of colors, selecting the first
08 // item in the shuffled array
09 var shuffleColor = _.first(_.shuffle(['#666','#333','#111']));
10
11 // Animate the background-color of any elements with the class
12 // 'item' on the page using the shuffled color
13 $('.item').animate({'backgroundColor': shuffleColor });
14
15 return {};
16 // What we return can be used by other modules
17 });

137 de 184 22/03/12 11:43


There is however something missing from this example and it's the concept of
registration.

Registering jQuery As An Async-compatible Module

One of the key features that landed in jQuery 1.7 was support for registering
jQuery as an asynchronous module. There are a number of compatible script
loaders (including RequireJS and curl) which are capable of loading modules
using an asynchronous module format and this means fewer hacks are
required to get things working.

If a developer wants to use AMD and does not want their jQuery version
leaking into the global space, they should call noConflict in their top level
module that uses jQuery. In addition, since multiple versions of jQuery can be
on a page there are special considerations that an AMD loader must account
for, and so jQuery only registers with AMD loaders that have recognized these
concerns, which are indicated by the loader specifying define.amd.jQuery.
RequireJS and curl are two loaders that do so

The named AMD provides a safety blanket of being both robust and safe for
most use-cases.

01 // Account for the existence of more than one global
02 // instances of jQuery in the document, cater for testing
03 // .noConflict()
04
05 var jQuery = this.jQuery || "jQuery",
06 $ = this.$ || "$",
07 originaljQuery = jQuery,
08 original$ = $;
09
10 define(['jquery'] , function ($) {
11 $('.items').css('background','green');
12 return function () {};
13 });

Smarter jQuery Plugins

I've recently discussed some ideas and examples of how jQuery plugins could
be written using Universal Module Definition (UMD) patterns here. UMDs
define modules that can work on both the client and server, as well as with all
popular script loaders available at the moment. Whilst this is still a new area
with a lot of concepts still being finalized, feel free to look at the code samples
in the section title AMD && CommonJS below and let me know if you feel
there's anything we could do better.

138 de 184 22/03/12 11:43


What Script Loaders & Frameworks Support AMD?

In-browser:

RequireJS http://requirejs.org
curl.js http://github.com/unscriptable/curl
bdLoad http://bdframework.com/bdLoad
Yabble http://github.com/jbrantly/yabble
PINF http://github.com/pinf/loader-js
(and more)
Server-side:

RequireJS http://requirejs.org

AMD Conclusions

The above are very trivial examples of just how useful AMD modules can truly
be, but they hopefully provide a foundation for understanding how they work.

You may be interested to know that many visible large applications and
companies currently use AMD modules as a part of their architecture. These
include IBM and the BBC iPlayer, which highlight just how seriously this
format is being considered by developers at an enterprise-level.

For more reasons why many developers are opting to use AMD modules in
their applications, you may be interested in this post by James Burke.

CommonJS A Module Format Optimized For The Server

CommonJS are a volunteer working group which aim to design, prototype and
standardize JavaScript APIs. To date they've attempted to ratify standards for
both modules and packages. The CommonJS module proposal specifies a
simple API for declaring modules server-side and unlike AMD attempts to
cover a broader set of concerns such as io, filesystem, promises and more.

Getting Started

From a structure perspective, a CommonJS module is a reusable piece of
JavaScript which exports specific objects made available to any dependent code

139 de 184 22/03/12 11:43


- there are typically no function wrappers around such modules (so you won't
see define used here for example).

At a high-level they basically contain two primary parts: a free variable named
exports which contains the objects a module wishes to make available to other
modules and a require function that modules can use to import the exports of
other modules.

Understanding CommonJS: require() and exports

01 // package/lib is a dependency we require
02 var lib = require('package/lib');
03
04 // some behaviour for our module
05 function foo(){
06 lib.log('hello world!');
07 }
08
09 // export (expose) foo to other modules
10 exports.foo = foo;

Basic consumption of exports

01 // define more behaviour we would like to expose
02 function foobar(){
03 this.foo = function(){
04 console.log('Hello foo');
05 }
06
07 this.bar = function(){
08 console.log('Hello bar');
09 }
10 }
11
12 // expose foobar to other modules
13 exports.foobar = foobar;
14
15
16 // an application consuming 'foobar'
17
18 // access the module relative to the path
19 // where both usage and module files exist
20 // in the same directory
21
22 var foobar = require('./foobar').foobar,
23 test = new foobar();
24
25 test.bar(); // 'Hello bar'

AMD-equivalent Of The First CommonJS Example

01 define(function(require){
02 var lib = require('package/lib');

140 de 184 22/03/12 11:43


03
04 // some behaviour for our module
05 function foo(){
06 lib.log('hello world!');
07 }
08
09 // export (expose) foo for other modules
10 return {
11 foobar: foo
12 };
13 });

This can be done as AMD supports a simplified CommonJS wrapping feature.

Consuming Multiple Dependencies

app.js

01 var modA = require('./foo');
02 var modB = require('./bar');
03
04 exports.app = function(){
05 console.log('Im an application!');
06 }
07
08 exports.foo = function(){
09 return modA.helloWorld();
10 }

bar.js

1 exports.name = 'bar';

foo.js

1 require('./bar');
2 exports.helloWorld = function(){
3 return 'Hello World!!''
4 }

What Loaders & Frameworks Support CommonJS?

In-browser:

curl.js http://github.com/unscriptable/curl
SproutCore 1.1 http://sproutcore.com
(and more)
Server-side:

141 de 184 22/03/12 11:43


Nodehttp://nodejs.org
Narwhal https://github.com/tlrobinson/narwhal
Perseverehttp://www.persvr.org/
Wakandahttp://www.wakandasoft.com/

Is CommonJS Suitable For The Browser?

There are developers that feel CommonJS is better suited to server-side
development which is one reason there's currently a level of disagreement
over which format should and will be used as the de facto standard in the
pre-Harmony age moving forward. Some of the arguments against CommonJS
include a note that many CommonJS APIs address server-oriented features
which one would simply not be able to implement at a browser-level in
JavaScript - for example, io, system and js could be considered
unimplementable by the nature of their functionality.

That said, it's useful to know how to structure CommonJS modules regardless
so that we can better appreciate how they fit in when defining modules which
may be used everywhere. Modules which have applications on both the client
and server include validation, conversion and templating engines. The way
some developers are approaching choosing which format to use is opting for
CommonJS when a module can be used in a server-side environment and using
AMD if this is not the case.

As AMD modules are capable of using plugins and can define more granular
things like constructors and functions this makes sense. CommonJS modules
are only able to define objects which can be tedious to work with if you're
trying to obtain constructors out of them.

Although it's beyond the scope of this section, you may have also noticed that
there were different types of 'require' methods mentioned when discussing
AMD and CommonJS.

The concern with a similar naming convention is of course confusion and the
community are currently split on the merits of a global require function. John
Hann's suggestion here is that rather than calling it 'require', which would
probably fail to achieve the goal of informing users about the different between
a global and inner require, it may make more sense to rename the global
loader method something else (e.g. the name of the library). It's for this reason
that a loader like curl.js uses curl() as opposed to require.

142 de 184 22/03/12 11:43


Related Reading

Demystifying CommonJS Modules

JavaScript Growing Up

The RequireJS Notes On CommonJS

Taking Baby Steps With Node.js And CommonJS - Creating Custom Modules

Asynchronous CommonJS Modules for the Browser

The CommonJS Mailing List

AMD && CommonJS Competing, But Equally Valid
Standards

Whilst this section has placed more emphasis on using AMD over CommonJS,
the reality is that both formats are valid and have a use.

AMD adopts a browser-first approach to development, opting for asynchronous
behaviour and simplified backwards compatability but it doesn't have any
concept of File I/O. It supports objects, functions, constructors, strings, JSON
and many other types of modules, running natively in the browser. It's
incredibly flexible.

CommonJS on the other hand takes a server-first approach, assuming
synchronous behaviour, no global baggage as John Hann would refer to it as
and it attempts to cater for the future (on the server). What we mean by this is
that because CommonJS supports unwrapped modules, it can feel a little more
close to the ES.next/Harmony specifications, freeing you of the define()
wrapper that AMD enforces. CommonJS modules however only support objects
as modules.

Although the idea of yet another module format may be daunting, you may be
interested in some samples of work on hybrid AMD/CommonJS and Univeral
AMD/CommonJS modules.

Basic AMD Hybrid Format (John Hann)

1 define( function (require, exports, module){

143 de 184 22/03/12 11:43


2
3 var shuffler = require('lib/shuffle');
4
5 exports.randomize = function( input ){
6 return shuffler.shuffle(input);
7 }
8 });

Note: this is basically the 'simplified CommonJS wrapper' that is supported in
the AMD spec.

AMD/CommonJS Universal Module Definition (Variation 2, UMDjs)

01 /**
02 * exports object based version, if you need to make a
03 * circular dependency or need compatibility with
04 * commonjs-like environments that are not Node.
05 */
06 (function (define) {
07 //The 'id' is optional, but recommended if this is
08 //a popular web library that is used mostly in
09 //non-AMD/Node environments. However, if want
10 //to make an anonymous module, remove the 'id'
11 //below, and remove the id use in the define shim.
12 define('id', function (require, exports) {
13 //If have dependencies, get them here
14 var a = require('a');
15
16 //Attach properties to exports.
17 exports.name = value;
18 });
19 }(typeof define === 'function' && define.amd ? define : function (id,
factory) {
20 if (typeof exports !== 'undefined') {
21 //commonjs
22 factory(require, exports);
23 } else {
24 //Create a global function. Only works if
25 //the code does not have dependencies, or
26 //dependencies fit the call pattern below.
27 factory(function(value) {
28 return window[value];
29 }, (window[id] = {}));
30 }
31 }));

Extensible UMD Plugins With (Variation by myself and Thomas Davis).

core.js

01 // Module/Plugin core
02 // Note: the wrapper code you see around the module is what enables
03 // us to support multiple module formats and specifications by
04 // mapping the arguments defined to what a specific format expects
05 // to be present. Our actual module functionality is defined lower

144 de 184 22/03/12 11:43


06 // down, where a named module and exports are demonstrated.
07
08 ;(function ( name, definition ){
09 var theModule = definition(),
10 // this is considered "safe":
11 hasDefine = typeof define === 'function' && define.amd,
12 // hasDefine = typeof define === 'function',
13 hasExports = typeof module !== 'undefined' && module.exports;
14
15 if ( hasDefine ){ // AMD Module
16 define(theModule);
17 } else if ( hasExports ) { // Node.js Module
18 module.exports = theModule;
19 } else { // Assign to common namespaces or simply the global object
(window)
20 (this.jQuery || this.ender || this.$ || this)[name] = theModule;
21 }
22 })( 'core', function () {
23 var module = this;
24 module.plugins = [];
25 module.highlightColor = "yellow";
26 module.errorColor = "red";
27
28 // define the core module here and return the public API
29
30 // this is the highlight method used by the core highlightAll()
31 // method and all of the plugins highlighting elements different
32 // colors
33 module.highlight = function(el,strColor){
34 // this module uses jQuery, however plain old JavaScript
35 // or say, Dojo could be just as easily used.
36 if(this.jQuery){
37 jQuery(el).css('background', strColor);
38 }
39 }
40 return {
41 highlightAll:function(){
42 module.highlight('div', module.highlightColor);
43 }
44 };
45
46 });

myExtension.js

01 ;(function ( name, definition ) {
03 hasDefine = typeof define === 'function',
05
06 if ( hasDefine ) { // AMD Module
(window)
11
12

145 de 184 22/03/12 11:43


13 // account for for flat-file/global module extensions
14 var obj = null;
15 var namespaces = name.split(".");
16 var scope = (this.jQuery || this.ender || this.$ || this);
17 for (var i = 0; i < namespaces.length; i++) {
18 var packageName = namespaces[i];
19 if (obj && i == namespaces.length - 1) {
20 obj[packageName] = theModule;
21 } else if (typeof scope[packageName] === "undefined") {
22 scope[packageName] = {};
23 }
24 obj = scope[packageName];
25 }
26
27 }
28 })('core.plugin', function () {
29
30 // define your module here and return the public API
31 // this code could be easily adapted with the core to
32 // allow for methods that overwrite/extend core functionality
33 // to expand the highlight method to do more if you wished.
34 return {
35 setGreen: function ( el ) {
36 highlight(el, 'green');
37 },
38 setRed: function ( el ) {
39 highlight(el, errorColor);
40 }
41 };
42
43 });

app.js

01 $(function(){
02
03 // the plugin 'core' is exposed under a core namespace in
04 // this example which we first cache
05 var core = $.core;
06
07 // use then use some of the built-in core functionality to
08 // highlight all divs in the page yellow
09 core.highlightAll();
10
11 // access the plugins (extensions) loaded into the 'plugin'
12 // namespace of our core module:
13
14 // Set the first div in the page to have a green background.
15 core.plugin.setGreen("div:first");
16 // Here we're making use of the core's 'highlight' method
17 // under the hood from a plugin loaded in after it
18
19 // Set the last div to the 'errorColor' property defined in
20 // our core module/plugin. If you review the code further down
21 // you'll see how easy it is to consume properties and methods
22 // between the core and other plugins
23 core.plugin.setRed('div:last');
24 });

146 de 184 22/03/12 11:43


ES Harmony Modules Of The Future

TC39, the standards body charged with defining the syntax and semantics of
ECMAScript and its future iterations is composed of a number of very
intelligent developers. Some of these developers (such as Alex Russell) have
been keeping a close eye on the evolution of JavaScript usage for large-scale
development over the past few years and are acutely aware of the need for
better language features for writing more modular JS.

For this reason, there are currently proposals for a number of exciting
additions to the language including flexible modules that can work on both the
client and server, a module loader and more. In this section, I'll be showing you
some code samples of the syntax for modules in ES.next so you can get a taste
of what's to come.

Note: Although Harmony is still in the proposal phases, you can already try out
(partial) features of ES.next that address native support for writing modular
JavaScript thanks to Google's Traceur compiler. To get up and running with
Traceur in under a minute, read this getting started guide. There's also a JSConf
presentation about it that's worth looking at if you're interested in learning more
about the project.
Modules With Imports And Exports

If you've read through the sections on AMD and CommonJS modules you may
be familiar with the concept of module dependencies (imports) and module
exports (or, the public API/variables we allow other modules to consume). In
ES.next, these concepts have been proposed in a slightly more succinct
manner with dependencies being specified using an import keyword. export isn't
greatly different to what we might expect and I think many developers will look
at the code below and instantly 'get' it.

import declarations bind a module's exports as local variables and may be
renamed to avoid name collisions/conflicts.
export declarations declare that a local-binding of a module is externally visible
such that other modules may read the exports but can't modify them.
Interestingly, modules may export child modules however can't export modules
that have been defined elsewhere. You may also rename exports so their
external name differs from their local names.

147 de 184 22/03/12 11:43


01 module staff{
02 // specify (public) exports that can be consumed by
03 // other modules
04 export var baker = {
05 bake: function( item ){
06 console.log('Woo! I just baked ' + item);
07 }
08 }
09 }
10
11 module skills{
12 export var specialty = "baking";
13 export var experience = "5 years";
14 }
15
16 module cakeFactory{
17
18 // specify dependencies
19 import baker from staff;
20
21 // import everything with wildcards
22 import * from skills;
23
24 export var oven = {
25 makeCupcake: function( toppings ){
26 baker.bake('cupcake', toppings);
27 },
28 makeMuffin: function( mSize ){
29 baker.bake('muffin', size);
30 }
31 }
32 }

Modules Loaded From Remote Sources

The module proposals also cater for modules which are remotely based (e.g. a
third-party API wrapper) making it simplistic to load modules in from external
locations. Here's an example of us pulling in the module we defined above and
utilizing it:

1 module cakeFactory from 'http://addyosmani.com/factory/cakes.js';
2 cakeFactory.oven.makeCupcake('sprinkles');
3 cakeFactory.oven.makeMuffin('large');

Module Loader API

The module loader proposed describes a dynamic API for loading modules in
highly controlled contexts. Signatures supported on the loader include load(
url, moduleInstance, error) for loading modules, createModule( object,
globalModuleReferences) and others. Here's another example of us dynamically
loading in the module we initially defined. Note that unlike the last example

148 de 184 22/03/12 11:43


where we pulled in a module from a remote source, the module loader API is
better suited to dynamic contexts.

1 Loader.load('http://addyosmani.com/factory/cakes.js',
2 function(cakeFactory){
3 cakeFactory.oven.makeCupcake('chocolate');
4 });

CommonJS-like Modules For The Server

For developers who are server-oriented, the module system proposed for
ES.next isn't just constrained to looking at modules in the browser. Below for
examples, you can see a CommonJS-like module proposed for use on the
server:

1 // io/File.js
2 export function open(path) { ... };
3 export function close(hnd) { ... };

01 // compiler/LexicalHandler.js
02 module file from 'io/File';
03
04 import { open, close } from file;
05 export function scan(in) {
06 try {
07 var h = open(in) ...
08 }
09 finally { close(h) }
10 }

1 module lexer from 'compiler/LexicalHandler';
2 module stdlib from '@std';
3
4 //... scan(cmdline[0]) ...

Classes With Constructors, Getters & Setters

The notion of a class has always been a contentious issue with purists and
we've so far got along with either falling back on JavaScript's prototypal nature
or through using frameworks or abstractions that offer the ability to use class
definitions in a form that desugars to the same prototypal behavior.

In Harmony, classes come as part of the language along with constructors and
(finally) some sense of true privacy. In the following examples, I've included
some inline comments to help you understand how classes are structured, but
you may also notice the lack of the word 'function' in here. This isn't a typo
error: TC39 have been making a conscious effort to decrease our abuse of the
function keyword for everything and the hope is that this will help simplify how

149 de 184 22/03/12 11:43


we write code.

01 class Cake{
02
03 // We can define the body of a class' constructor
04 // function by using the keyword 'constructor' followed
05 // by an argument list of public and private declarations.
06 constructor( name, toppings, price, cakeSize ){
07 public name = name;
08 public cakeSize = cakeSize;
09 public toppings = toppings;
10 private price = price;
11
12 }
13
14 // As a part of ES.next's efforts to decrease the unnecessary
15 // use of 'function' for everything, you'll notice that it's
16 // dropped for cases such as the following. Here an identifier
17 // followed by an argument list and a body defines a new method
18
19 addTopping( topping ){
20 public(this).toppings.push(topping);
21 }
22
23 // Getters can be defined by declaring get before
24 // an identifier/method name and a curly body.
25 get allToppings(){
26 return public(this).toppings;
27 }
28
29 get qualifiesForDiscount(){
30 return private(this).price > 5;
31 }
32
33 // Similar to getters, setters can be defined by using
34 // the 'set' keyword before an identifier
35 set cakeSize( cSize ){
36 if( cSize < 0 ){
37 throw new Error('Cake must be a valid size -
38 either small, medium or large');
39 }
40 public(this).cakeSize = cSize;
41 }
42
43
44 }

ES Harmony Conclusions

As you can see, ES.next is coming with some exciting new additions. Although
Traceur can be used to an extent to try our such features in the present,
remember that it may not be the best idea to plan out your system to use
Harmony (just yet). There are risks here such as specifications changing and a
potential failure at the cross-browser level (IE9 for example will take a while to

150 de 184 22/03/12 11:43


die) so your best bets until we have both spec finalization and coverage are
AMD (for in-browser modules) and CommonJS (for those on the server).

Related Reading

A First Look At The Upcoming JavaScript Modules

David Herman On JavaScript/ES.Next (Video)

ES Harmony Module Proposals

ES Harmony Module Semantics/Structure Rationale

ES Harmony Class Proposals

Conclusions And Further Reading A Review

In this section we reviewed several of the options available for writing modular
JavaScript using modern module formats. These formats have a number of
advantages over using the (classical) module pattern alone including: avoiding
a need for developers to create global variables for each module they create,
better support for static and dynamic dependency management, improved
compatibility with script loaders, better (optional) compatibility for modules on
the server and more.

In short, I recommend trying out what's been suggested today as these formats
offer a lot of power and flexibility that can help when building applications
based on many reusable blocks of functionality.

Bonus: jQuery Plugin Design Patterns

While well-known JavaScript design patterns can be extremely useful, another
side of development could benefit from its own set of design patterns are
jQuery plugins. The official jQuery plugin authoring guide offers a great
starting point for getting into writing plugins and widgets, but let’s take it
further.

Plugin development has evolved over the past few years. We no longer have
just one way to write plugins, but many. In reality, certain patterns might work

151 de 184 22/03/12 11:43


better for a particular problem or component than others.

Some developers may wish to use the jQuery UI widget factory; it’s great for
complex, flexible UI components. Some may not. Some might like to structure
their plugins more like modules (similar to the module pattern) or use a more
formal module format such as AMD (asynchronous module definition). Some
might want their plugins to harness the power of prototypal inheritance. Some
might want to use custom events or pub/sub to communicate from plugins to
the rest of their app. And so on.

I began to think about plugin patterns after noticing a number of efforts to
create a one-size-fits-all jQuery plugin boilerplate. While such a boilerplate is a
great idea in theory, the reality is that we rarely write plugins in one fixed way,
using a single pattern all the time.

Let’s assume that you’ve tried your hand at writing your own jQuery plugins at
some point and you’re comfortable putting together something that works. It’s
functional. It does what it needs to do, but perhaps you feel it could be
structured better. Maybe it could be more flexible or could solve more issues. If
this sounds familiar and you aren’t sure of the differences between many of
the different jQuery plugin patterns, then you might find what I have to say
helpful.

My advice won’t provide solutions to every possible pattern, but it will cover
popular patterns that developers use in the wild.

Note: This section is targeted at intermediate to advanced developers. If you
don’t feel you’re ready for this just yet, I’m happy to recommend the official
jQuery Plugins/Authoring guide, Ben Alman’s plugin style guide and Remy
Sharp’s “Signs of a Poorly Written jQuery Plugin.”

Patterns

jQuery plugins have very few defined rules, which one of the reasons for the
incredible diversity in how they’re implemented. At the most basic level, you
can write a plugin simply by adding a new function property to jQuery’s $.fn
object, as follows:

1 $.fn.myPluginName = function() {
2 // your plugin logic
3 };

This is great for compactness, but the following would be a better foundation to

152 de 184 22/03/12 11:43


build on:

1 (function( $ ){
2 $.fn.myPluginName = function() {
4 };
5 })( jQuery );

Here, we’ve wrapped our plugin logic in an anonymous function. To ensure
that our use of the $ sign as a shorthand creates no conflicts between jQuery
and other JavaScript libraries, we simply pass it to this closure, which maps it
to the dollar sign, thus ensuring that it can’t be affected by anything outside of
its scope of execution.

An alternative way to write this pattern would be to use $.extend, which enables
you to define multiple functions at once and which sometimes make more
sense semantically:

1 (function( $ ){
2 $.extend($.fn, {
3 myplugin: function(){
5 }
6 });
7 })( jQuery );

We could do a lot more to improve on all of this; and the first complete pattern
we’ll be looking at today, the lightweight pattern, covers some best practices
that we can use for basic everyday plugin development and that takes into
account common gotchas to look out for.

Note

While most of the patterns below will be explained, I recommend reading
through the comments in the code, because they will offer more insight into
why certain practices are best.

I should also mention that none of this would be possible without the previous
work, input and advice of other members of the jQuery community. I’ve listed
them inline with each pattern so that you can read up on their individual work
if interested.

153 de 184 22/03/12 11:43


A Lightweight Start

Let’s begin our look at patterns with something basic that follows best
practices (including those in the jQuery plugin-authoring guide). This pattern is
ideal for developers who are either new to plugin development or who just
want to achieve something simple (such as a utility plugin). This lightweight
start uses the following:

Common best practices, such as a semi-colon before the function’s invocation;
window, document, undefined passed in as arguments; and adherence to the jQuery
core style guidelines.
A basic defaults object.
A simple plugin constructor for logic related to the initial creation and the
assignment of the element to work with.
Extending the options with defaults.
A lightweight wrapper around the constructor, which helps to avoid issues
such as multiple instantiations.

01 /*!
02 * jQuery lightweight plugin boilerplate
03 * Original author: @ajpiano
04 * Further changes, comments: @addyosmani
05 * Licensed under the MIT license
06 */
07
08
09 // the semi-colon before the function invocation is a safety
10 // net against concatenated scripts and/or other plugins
11 // that are not closed properly.
12 ;(function ( $, window, document, undefined ) {
13
14 // undefined is used here as the undefined global
15 // variable in ECMAScript 3 and is mutable (i.e. it can
16 // be changed by someone else). undefined isn't really
17 // being passed in so we can ensure that its value is
18 // truly undefined. In ES5, undefined can no longer be
19 // modified.
20
21 // window and document are passed through as local
22 // variables rather than as globals, because this (slightly)
23 // quickens the resolution process and can be more
24 // efficiently minified (especially when both are
25 // regularly referenced in your plugin).
26
27 // Create the defaults once
28 var pluginName = 'defaultPluginName',
29 defaults = {
30 propertyName: "value"
31 };
32
33 // The actual plugin constructor

154 de 184 22/03/12 11:43


34 function Plugin( element, options ) {
35 this.element = element;
36
37 // jQuery has an extend method that merges the
38 // contents of two or more objects, storing the
39 // result in the first object. The first object
40 // is generally empty because we don't want to alter
41 // the default options for future instances of the plugin
42 this.options = $.extend( {}, defaults, options) ;
43
44 this._defaults = defaults;
45 this._name = pluginName;
46
47 this.init();
48 }
49
50 Plugin.prototype.init = function () {
51 // Place initialization logic here
52 // You already have access to the DOM element and
53 // the options via the instance, e.g. this.element
54 // and this.options
55 };
56
57 // A really lightweight plugin wrapper around the constructor,
58 // preventing against multiple instantiations
59 $.fn[pluginName] = function ( options ) {
60 return this.each(function () {
61 if (!$.data(this, 'plugin_' + pluginName)) {
62 $.data(this, 'plugin_' + pluginName,
63 new Plugin( this, options ));
64 }
65 });
66 }
67
68 })( jQuery, window, document );

Usage:

1 $('#elem').defaultPluginName({
2 propertyName: 'a custom value'
3 });

Further Reading

Plugins/Authoring, jQuery
“Signs of a Poorly Written jQuery Plugin,” Remy Sharp
“How to Create Your Own jQuery Plugin,” Elijah Manor
“Style in jQuery Plugins and Why It Matters,” Ben Almon
“Create Your First jQuery Plugin, Part 2,” Andrew Wirick

155 de 184 22/03/12 11:43


“Complete” Widget Factory

While the authoring guide is a great introduction to plugin development, it
doesn’t oﬀer a great number of conveniences for obscuring away from
common plumbing tasks that we have to deal with on a regular basis.

The jQuery UI Widget Factory is a solution to this problem that helps you build
complex, stateful plugins based on object-oriented principles. It also eases
communication with your plugin’s instance, obfuscating a number of the
repetitive tasks that you would have to code when working with basic plugins.

In case you haven’t come across these before, stateful plugins keep track of
their current state, also allowing you to change properties of the plugin after it
has been initialized.

One of the great things about the Widget Factory is that the majority of the
jQuery UI library actually uses it as a base for its components. This means that
if you’re looking for further guidance on structure beyond this template, you
won’t have to look beyond the jQuery UI repository.

Back to patterns. This jQuery UI boilerplate does the following:

Covers almost all supported default methods, including triggering events.
Includes comments for all of the methods used, so that you’re never unsure of
where logic should fit in your plugin.

01 /*!
02 * jQuery UI Widget-factory plugin boilerplate (for 1.8/9+)
03 * Author: @addyosmani
04 * Further changes: @peolanha
06 */
07
08
10
11 // define your widget under a namespace of your choice
12 // with additional parameters e.g.
13 // $.widget( "namespace.widgetname", (optional) - an
14 // existing widget prototype to inherit from, an object
15 // literal to become the widget's prototype );
16
17 $.widget( "namespace.widgetname" , {
18
19 //Options to be used as defaults
20 options: {
21 someValue: null
22 },
23

156 de 184 22/03/12 11:43


24 //Setup widget (eg. element creation, apply theming
25 // , bind events etc.)
26 _create: function () {
27
28 // _create will automatically run the first time
29 // this widget is called. Put the initial widget
30 // setup code here, then you can access the element
31 // on which the widget was called via this.element.
32 // The options defined above can be accessed
33 // via this.options this.element.addStuff();
34 },
35
36 // Destroy an instantiated plugin and clean up
37 // modifications the widget has made to the DOM
38 destroy: function () {
39
40 // this.element.removeStuff();
41 // For UI 1.8, destroy must be invoked from the
42 // base widget
43 $.Widget.prototype.destroy.call(this);
44 // For UI 1.9, define _destroy instead and don't
45 // worry about
46 // calling the base widget
47 },
48
49 methodB: function ( event ) {
50 //_trigger dispatches callbacks the plugin user
51 // can subscribe to
52 // signature: _trigger( "callbackName" , [eventObject],
53 // [uiObject] )
54 // eg. this._trigger( "hover", e /*where e.type ==
55 // "mouseenter"*/, { hovered: $(e.target)});
56 this._trigger('methodA', event, {
57 key: value
58 });
59 },
60
61 methodA: function ( event ) {
62 this._trigger('dataChanged', event, {
63 key: value
64 });
65 },
66
67 // Respond to any changes the user makes to the
68 // option method
69 _setOption: function ( key, value ) {
70 switch (key) {
71 case "someValue":
72 //this.options.someValue = doSomethingWith( value );
73 break;
74 default:
75 //this.options[ key ] = value;
76 break;
77 }
78
79 // For UI 1.8, _setOption must be manually invoked
80 // from the base widget
81 $.Widget.prototype._setOption.apply( this, arguments );
82 // For UI 1.9 the _super method can be used instead

157 de 184 22/03/12 11:43


83 // this._super( "_setOption", key, value );
84 }
85 });
86

Usage:

1 var instance = $('#elem').widgetName({
2 foo: false
3 });
4
5 instance.widgetName('methodB');

Further Reading

The jQuery UI Widget Factory
“Introduction to Stateful Plugins and the Widget Factory,” Doug Neiner
“Widget Factory” (explained), Scott Gonzalez
“Understanding jQuery UI Widgets: A Tutorial,” Hacking at 0300

Namespacing And Nested Namespacing

Namespacing your code is a way to avoid collisions with other objects and
variables in the global namespace. They’re important because you want to
safeguard your plugin from breaking in the event that another script on the
page uses the same variable or plugin names as yours. As a good citizen of the
global namespace, you must also do your best not to prevent other developers’
scripts from executing because of the same issues.

JavaScript doesn’t really have built-in support for namespaces as other
languages do, but it does have objects that can be used to achieve a similar
effect. Employing a top-level object as the name of your namespace, you can
easily check for the existence of another object on the page with the same
name. If such an object does not exist, then we define it; if it does exist, then
we simply extend it with our plugin.

Objects (or, rather, object literals) can be used to create nested namespaces,
such as namespace.subnamespace.pluginName and so on. But to keep things simple, the
namespacing boilerplate below should give you everything you need to get
started with these concepts.

158 de 184 22/03/12 11:43


01 /*!
02 * jQuery namespaced 'Starter' plugin boilerplate
03 * Author: @dougneiner
04 * Further changes: @addyosmani
06 */
07
08 ;(function ( $ ) {
09 if (!$.myNamespace) {
10 $.myNamespace = {};
11 };
12
13 $.myNamespace.myPluginName = function ( el, myFunctionParam, options
) {
14 // To avoid scope issues, use 'base' instead of 'this'
15 // to reference this class from internal events and functions.
16 var base = this;
17
18 // Access to jQuery and DOM versions of element
19 base.$el = $(el);
20 base.el = el;
21
22 // Add a reverse reference to the DOM object
23 base.$el.data( "myNamespace.myPluginName" , base );
24
25 base.init = function () {
26 base.myFunctionParam = myFunctionParam;
27
28 base.options = $.extend({},
29 $.myNamespace.myPluginName.defaultOptions, options);
30
31 // Put your initialization code here
32 };
33
34 // Sample Function, Uncomment to use
35 // base.functionName = function( paramaters ){
36 //
37 // };
38 // Run initializer
39 base.init();
40 };
41
42 $.myNamespace.myPluginName.defaultOptions = {
43 myDefaultValue: ""
44 };
45
46 $.fn.mynamespace_myPluginName = function
47 ( myFunctionParam, options ) {
49 (new $.myNamespace.myPluginName(this,
50 myFunctionParam, options));
51 });
52 };
53
54 })( jQuery );

Usage:

159 de 184 22/03/12 11:43


1 $('#elem').mynamespace_myPluginName({
2 myDefaultValue: "foobar"
3 });

Further Reading

“Namespacing in JavaScript,” Angus Croll
“Use Your $.fn jQuery Namespace,” Ryan Florence
“JavaScript Namespacing,” Peter Michaux
“Modules and namespaces in JavaScript,” Axel Rauschmayer

Custom Events For Pub/Sub (With The Widget factory)

You may have used the Observer (Pub/Sub) pattern in the past to develop
asynchronous JavaScript web applications. The basic idea here is that elements
will publish event notifications when something interesting occurs in your
application. Other elements then subscribe to or listen for these events and
respond accordingly. This results in the logic for your application being
significantly more decoupled (which is always good).

In jQuery, we have this idea that custom events provide a built-in means to
implement a publish and subscribe system that’s quite similar to the Observer
pattern. So, bind('eventType') is functionally equivalent to performing
subscribe('eventType'), and trigger('eventType') is roughly equivalent to
publish('eventType').

Some developers might consider the jQuery event system as having too much
overhead to be used as a publish and subscribe system, but it’s been
architected to be both reliable and robust for most use cases. In the following
jQuery UI widget factory template, we’ll implement a basic custom event-based
pub/sub pattern that allows our plugin to subscribe to event notifications from
the rest of our application, which publishes them.

01 /*!
02 * jQuery custom-events plugin boilerplate
03 * Author: DevPatch
06 */
07
08 // In this pattern, we use jQuery's custom events to add

160 de 184 22/03/12 11:43


09 // pub/sub (publish/subscribe) capabilities to widgets.
10 // Each widget would publish certain events and subscribe
11 // to others. This approach effectively helps to decouple
12 // the widgets and enables them to function independently.
13
15 $.widget("ao.eventStatus", {
16 options: {
17
18 },
19
20 _create : function() {
21 var self = this;
22
23 //self.element.addClass( "my-widget" );
24
25 //subscribe to 'myEventStart'
26 self.element.bind( "myEventStart", function( e ) {
27 console.log("event start");
28 });
29
30 //subscribe to 'myEventEnd'
31 self.element.bind( "myEventEnd", function( e ) {
32 console.log("event end");
33 });
34
35 //unsubscribe to 'myEventStart'
36 //self.element.unbind( "myEventStart", function(e){
37 ///console.log("unsubscribed to this event");
38 //});
39 },
40
41 destroy: function(){
42 $.Widget.prototype.destroy.apply( this, arguments );
43 },
44 });
45 })( jQuery, window , document );
46
47 // Publishing event notifications
48 // $(".my-widget").trigger("myEventStart");
49 // $(".my-widget").trigger("myEventEnd");

Usage:

1 var el = $('#elem');
2 el.eventStatus();
3 el.eventStatus().trigger('myEventStart');

Further Reading

“Communication Between jQuery UI Widgets,” Benjamin Sternthal

161 de 184 22/03/12 11:43


Prototypal Inheritance With The DOM-To-Object Bridge
Pattern

In JavaScript, we don’t have the traditional notion of classes that you would
find in other classical programming languages, but we do have prototypal
inheritance. With prototypal inheritance, an object inherits from another
object. And we can apply this concept to jQuery plugin development.

Alex Sexton and Scott Gonzalez have looked at this topic in detail. In sum, they
found that for organized modular development, clearly separating the object
that defines the logic for a plugin from the plugin-generation process itself can
be beneficial. The benefit is that testing your plugin’s code becomes easier,
and you can also adjust the way things work behind the scenes without
altering the way that any object APIs you’ve implemented are used.

In Sexton’s previous post on this topic, he implements a bridge that enables
you to attach your general logic to a particular plugin, which we’ve
implemented in the template below. Another advantage of this pattern is that
you don’t have to constantly repeat the same plugin initialization code, thus
ensuring that the concepts behind DRY development are maintained. Some
developers might also find this pattern easier to read than others.

01 /*!
02 * jQuery prototypal inheritance plugin boilerplate
03 * Author: Alex Sexton, Scott Gonzalez
06 */
07
08
09 // myObject - an object representing a concept that you want
10 // to model (e.g. a car)
11 var myObject = {
12 init: function( options, elem ) {
13 // Mix in the passed-in options with the default options
14 this.options = $.extend( {}, this.options, options );
15
16 // Save the element reference, both as a jQuery
17 // reference and a normal reference
18 this.elem = elem;
19 this.$elem = $(elem);
20
21 // Build the DOM's initial structure
22 this._build();
23
24 // return this so that we can chain and use the bridge with less
code.
25 return this;
26 },

162 de 184 22/03/12 11:43


27 options: {
28 name: "No name"
29 },
30 _build: function(){
31 //this.$elem.html('<h1>'+this.options.name+'</h1>');
32 },
33 myMethod: function( msg ){
34 // You have direct access to the associated and cached
35 // jQuery element
36 // this.$elem.append('<p>'+msg+'</p>');
37 }
38 };
39
40
41 // Object.create support test, and fallback for browsers without it
42 if ( typeof Object.create !== 'function' ) {
43 Object.create = function (o) {
44 function F() {}
45 F.prototype = o;
46 return new F();
47 };
48 }
49
50
51 // Create a plugin based on a defined object
52 $.plugin = function( name, object ) {
53 $.fn[name] = function( options ) {
54 return this.each(function() {
55 if ( ! $.data( this, name ) ) {
56 $.data( this, name, Object.create(object).init(
57 options, this ) );
58 }
59 });
60 };
61 };

Usage:

1 $.plugin('myobj', myObject);
2
3 $('#elem').myobj({name: "John"});
4
5 var instance = $('#elem').data('myobj');
6 instance.myMethod('I am a method');

Further Reading

“Using Inheritance Patterns To Organize Large jQuery Applications,” Alex
Sexton
“How to Manage Large Applications With jQuery or Whatever” (further
discussion), Alex Sexton
“Practical Example of the Need for Prototypal Inheritance,” Neeraj Singh
“Prototypal Inheritance in JavaScript,” Douglas Crockford

163 de 184 22/03/12 11:43


jQuery UI Widget Factory Bridge

If you liked the idea of generating plugins based on objects in the last design
pattern, then you might be interested in a method found in the jQuery UI
Widget Factory called $.widget.bridge. This bridge basically serves as a middle
layer between a JavaScript object that is created using $.widget and jQuery’s
API, providing a more built-in solution to achieving object-based plugin
deﬁnition. Eﬀectively, we’re able to create stateful plugins using a custom
constructor.

Moreover, $.widget.bridge provides access to a number of other capabilities,
including the following:

Both public and private methods are handled as one would expect in classical
OOP (i.e. public methods are exposed, while calls to private methods are not
possible);
Automatic protection against multiple initializations;
Automatic generation of instances of a passed object, and storage of them
within the selection’s internal $.data cache;
Options can be altered post-initialization.
For further information on how to use this pattern, look at the comments in
the boilerplate below:

01 /*!
02 * jQuery UI Widget factory "bridge" plugin boilerplate
03 * Author: @erichynds
04 * Further changes, additional comments: @addyosmani
06 */
07
08
09 // a "widgetName" object constructor
10 // required: this must accept two arguments,
11 // options: an object of configuration options
12 // element: the DOM element the instance was created on
13 var widgetName = function( options, element ){
14 this.name = "myWidgetName";
15 this.options = options;
16 this.element = element;
17 this._init();
18 }
19
20
21 // the "widgetName" prototype
22 widgetName.prototype = {
23

164 de 184 22/03/12 11:43


24 // _create will automatically run the first time this
25 // widget is called
26 _create: function(){
27 // creation code
28 },
29
30 // required: initialization logic for the plugin goes into _init
31 // This fires when your instance is first created and when
32 // attempting to initialize the widget again (by the bridge)
33 // after it has already been initialized.
34 _init: function(){
35 // init code
36 },
37
38 // required: objects to be used with the bridge must contain an
39 // 'option'. Post-initialization, the logic for changing options
40 // goes here.
41 option: function( key, value ){
42
43 // optional: get/change options post initialization
44 // ignore if you don't require them.
45
46 // signature: $('#foo').bar({ cool:false });
47 if( $.isPlainObject( key ) ){
48 this.options = $.extend( true, this.options, key );
49
50 // signature: $('#foo').option('cool'); - getter
51 } else if ( key && typeof value === "undefined" ){
52 return this.options[ key ];
53
54 // signature: $('#foo').bar('option', 'baz', false);
55 } else {
56 this.options[ key ] = value;
57 }
58
59 // required: option must return the current instance.
60 // When re-initializing an instance on elements, option
61 // is called first and is then chained to the _init method.
62 return this;
63 },
64
65 // notice no underscore is used for public methods
66 publicFunction: function(){
67 console.log('public function');
68 },
69
70 // underscores are used for private methods
71 _privateFunction: function(){
72 console.log('private function');
73 }
74 };

Usage:

01 // connect the widget obj to jQuery's API under the "foo" namespace
02 $.widget.bridge("foo", widgetName);
03
04 // create an instance of the widget for use

165 de 184 22/03/12 11:43


05 var instance = $('#foo').foo({
06 baz: true
07 });
08
09 // your widget instance exists in the elem's data
10 console.log(instance.data("foo").element); // => #elem element
11
12 // bridge allows you to call public methods...
13 instance.foo("publicFunction"); // => "public method"
14
15 // bridge prevents calls to internal methods
16 instance.foo("_privateFunction"); // => #elem element

Further Reading

“Using $.widget.bridge Outside of the Widget Factory,” Eric Hynds

jQuery Mobile Widgets With The Widget factory

jQuery mobile is a framework that encourages the design of ubiquitous Web
applications that work both on popular mobile devices and platforms and on
the desktop. Rather than writing unique applications for each device or OS, you
simply write the code once and it should ideally run on many of the A-, B- and
C-grade browsers out there at the moment.

The fundamentals behind jQuery mobile can also be applied to plugin and
widget development, as seen in some of the core jQuery mobile widgets used in
the official library suite. What’s interesting here is that even though there are
very small, subtle differences in writing a “mobile”-optimized widget, if you’re
familiar with using the jQuery UI Widget Factory, you should be able to start
writing these right away.

The mobile-optimized widget below has a number of interesting differences
than the standard UI widget pattern we saw earlier:

$.mobile.widgetis referenced as an existing widget prototype from which to
inherit. For standard widgets, passing through any such prototype is
unnecessary for basic development, but using this jQuery-mobile specific
widget prototype provides internal access to further “options” formatting.
You’ll notice in _create() a guide on how the official jQuery mobile widgets
handle element selection, opting for a role-based approach that better fits the
jQM mark-up. This isn’t at all to say that standard selection isn’t

166 de 184 22/03/12 11:43


recommended, only that this approach might make more sense given the
structure of jQM pages.
Guidelines are also provided in comment form for applying your plugin
methods on pagecreate as well as for selecting the plugin application via data
roles and data attributes.

01 /*!
02 * (jQuery mobile) jQuery UI Widget-factory plugin boilerplate (for
1.8/9+)
03 * Author: @scottjehl
06 */
07
09
10 //define a widget under a namespace of your choice
11 //here 'mobile' has been used in the first parameter
12 $.widget( "mobile.widgetName", $.mobile.widget, {
13
14 //Options to be used as defaults
15 options: {
16 foo: true,
17 bar: false
18 },
19
20 _create: function() {
21 // _create will automatically run the first time this
22 // widget is called. Put the initial widget set-up code
23 // here, then you can access the element on which
24 // the widget was called via this.element
25 // The options defined above can be accessed via
26 // this.options
27
28 //var m = this.element,
29 //p = m.parents(":jqmData(role='page')"),
30 //c = p.find(":jqmData(role='content')")
31 },
32
33 // Private methods/props start with underscores
34 _dosomething: function(){ ... },
35
36 // Public methods like these below can can be called
37 // externally:
38 // $("#myelem").foo( "enable", arguments );
39
40 enable: function() { ... },
41
42 // Destroy an instantiated plugin and clean up modifications
43 // the widget has made to the DOM
45 //this.element.removeStuff();
46 // For UI 1.8, destroy must be invoked from the
47 // base widget
48 $.Widget.prototype.destroy.call(this);
49 // For UI 1.9, define _destroy instead and don't

167 de 184 22/03/12 11:43


50 // worry about calling the base widget
51 },
52
54 //_trigger dispatches callbacks the plugin user can
55 // subscribe to
56 //signature: _trigger( "callbackName" , [eventObject],
57 // [uiObject] )
58 // eg. this._trigger( "hover", e /*where e.type ==
59 // "mouseenter"*/, { hovered: $(e.target)});
61 key: value
62 });
63 },
64
67 key: value
68 });
69 },
70
71 //Respond to any changes the user makes to the option method
73 switch (key) {
76 break;
77 default:
79 break;
80 }
81
82 // For UI 1.8, _setOption must be manually invoked from
83 // the base widget
84 $.Widget.prototype._setOption.apply(this, arguments);
86 // this._super( "_setOption", key, value );
87 }
88 });
89

Usage:

1 var instance = $('#foo').widgetName({
2 foo: false
3 });
4
5 instance.widgetName('methodB');

We can also self-initialize this widget whenever a new page in jQuery Mobile is
created. jQuery Mobile's "page" plugin dispatches a "create" event when a
jQuery Mobile page (found via data-role=page attr) is first initialized.We can
listen for that event (called "pagecreate" ) and run our plugin automatically
whenever a new page is created.

168 de 184 22/03/12 11:43


01 $(document).bind("pagecreate", function (e) {
02 // In here, e.target refers to the page that was created
03 // (it's the target of the pagecreate event)
04 // So, we can simply find elements on this page that match a
05 // selector of our choosing, and call our plugin on them.
06 // Here's how we'd call our "foo" plugin on any element with a
07 // data-role attribute of "foo":
08 $(e.target).find("[data-role='foo']").foo(options);
09
10 // Or, better yet, let's write the selector accounting for the
configurable
11 // data-attribute namespace
12 $(e.target).find(":jqmData(role='foo')").foo(options);
13 });

That's it. Now you can simply reference the script containing your widget and
pagecreate binding in a page running jQuery Mobile site, and it will
automatically run like any other jQuery Mobile plugin.

RequireJS And The jQuery UI Widget Factory

RequireJS is a script loader that provides a clean solution for encapsulating
application logic inside manageable modules. It’s able to load modules in the
correct order (through its order plugin); it simplifies the process of combining
scripts via its excellent optimizer; and it provides the means for defining
module dependencies on a per-module basis.

James Burke has written a comprehensive set of tutorials on getting started
with RequireJS. But what if you’re already familiar with it and would like to
wrap your jQuery UI widgets or plugins in a RequireJS-compatible module
wrapper?.

In the boilerplate pattern below, we demonstrate how a compatible widget can
be defined that does the following:

Allows the definition of widget module dependencies, building on top of the
previous jQuery UI boilerplate presented earlier;
Demonstrates one approach to passing in HTML template assets for creating
templated widgets with jQuery (in conjunction with the jQuery tmpl plugin)
(View the comments in _create().)
Includes a quick tip on adjustments that you can make to your widget module if

169 de 184 22/03/12 11:43


you wish to later pass it through the RequireJS optimizer

01 /*!
02 * jQuery UI Widget + RequireJS module boilerplate (for 1.8/9+)
03 * Authors: @jrburke, @addyosmani
05 */
06
07
08 // Note from James:
09 //
10 // This assumes you are using the RequireJS+jQuery file, and
11 // that the following files are all in the same directory:
12 //
13 // - require-jquery.js
14 // - jquery-ui.custom.min.js (custom jQuery UI build with widget
factory)
15 // - templates/
16 // - asset.html
17 // - ao.myWidget.js
18
19 // Then you can construct the widget like so:
20
21
22
23 //ao.myWidget.js file:
24 define("ao.myWidget", ["jquery", "text!templates/asset.html", "jquery-
ui.custom.min","jquery.tmpl"], function ($, assetHtml) {
25
26 // define your widget under a namespace of your choice
27 // 'ao' is used here as a demonstration
28 $.widget( "ao.myWidget", {
29
30 // Options to be used as defaults
31 options: {},
32
33 // Set up widget (e.g. create element, apply theming,
34 // bind events, etc.)
35 _create: function () {
36
37 // _create will automatically run the first time
38 // this widget is called. Put the initial widget
39 // set-up code here, then you can access the element
40 // on which the widget was called via this.element.
41 // The options defined above can be accessed via
42 // this.options
43
44 //this.element.addStuff();
45 //this.element.addStuff();
46 //this.element.tmpl(assetHtml).appendTo(this.content);
47 },
48
49 // Destroy an instantiated plugin and clean up modifications
50 // that the widget has made to the DOM
52 //t his.element.removeStuff();
53 // For UI 1.8, destroy must be invoked from the base
54 // widget

170 de 184 22/03/12 11:43


55 $.Widget.prototype.destroy.call( this );
56 // For UI 1.9, define _destroy instead and don't worry
57 // about calling the base widget
58 },
59
61 // _trigger dispatches callbacks the plugin user can
62 // subscribe to
63 //signature: _trigger( "callbackName" , [eventObject],
64 // [uiObject] )
66 key: value
67 });
68 },
69
72 key: value
73 });
74 },
75
76 //Respond to any changes the user makes to the option method
78 switch (key) {
81 break;
82 default:
84 break;
85 }
86
87 // For UI 1.8, _setOption must be manually invoked from
88 // the base widget
89 $.Widget.prototype._setOption.apply( this, arguments );
91 //this._super( "_setOption", key, value );
92 }
93
94 //somewhere assetHtml would be used for templating, depending
95 // on your choice.
96 });
97 });

Usage:

index.html:

1 <script data-main="scripts/main" src="http://requirejs.org/docs/release
/1.0.1/minified/require.js"></script>

main.js

01 require({
02
03 paths: {
04 'jquery': 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.1

171 de 184 22/03/12 11:43


/jquery.min',
05 'jqueryui': 'https://ajax.googleapis.com/ajax/libs/jqueryui
/1.8.18/jquery-ui.min',
06 'boilerplate': '../patterns/jquery.widget-
factory.requirejs.boilerplate'
07 }
08 }, ['require', 'jquery', 'jqueryui', 'boilerplate'],
09 function (req, $) {
10
11 $(function () {
12
13 var instance = $('#elem').myWidget();
14 instance.myWidget('methodB');
15
16 });
17 });

Further Reading

Using RequireJS with jQuery, Rebecca Murphey
“Fast Modular Code With jQuery and RequireJS,” James Burke
“jQuery’s Best Friends ,” Alex Sexton
“Managing Dependencies With RequireJS,” Ruslan Matveev

Globally And Per-Call Overridable Options (Best Options
Pattern)

For our next pattern, we’ll look at an optimal approach to configuring options
and defaults for your plugin. The way you’re probably familiar with defining
plugin options is to pass through an object literal of defaults to $.extend, as
demonstrated in our basic plugin boilerplate.

If, however, you’re working with a plugin with many customizable options that
you would like users to be able to override either globally or on a per-call level,
then you can structure things a little differently.

Instead, by referring to an options object defined within the plugin namespace
explicitly (for example, $fn.pluginName.options) and merging this with any options
passed through to the plugin when it is initially invoked, users have the option
of either passing options through during plugin initialization or overriding
options outside of the plugin (as demonstrated here).

01 /*!
02 * jQuery 'best options' plugin boilerplate

172 de 184 22/03/12 11:43


03 * Author: @cowboy
06 */
07
08
10
11 $.fn.pluginName = function ( options ) {
12
13 // Here's a best practice for overriding 'defaults'
14 // with specified options. Note how, rather than a
15 // regular defaults object being passed as the second
16 // parameter, we instead refer to $.fn.pluginName.options
17 // explicitly, merging it with the options passed directly
18 // to the plugin. This allows us to override options both
19 // globally and on a per-call level.
20
21 options = $.extend( {}, $.fn.pluginName.options, options );
22
24
25 var elem = $(this);
26
27 });
28 };
29
30 // Globally overriding options
31 // Here are our publicly accessible default plugin options
32 // that are available in case the user doesn't pass in all
33 // of the values expected. The user is given a default
34 // experience but can also override the values as necessary.
35 // eg. $fn.pluginName.key ='otherval';
36
37 $.fn.pluginName.options = {
38
39 key: "value",
40 myMethod: function ( elem, param ) {
41
42 }
43 };
44

Usage:

1 $('#elem').pluginName({
2 key: "foobar"
3 });

Further Reading

jQuery Pluginization and the accompanying gist, Ben Alman

173 de 184 22/03/12 11:43


A Highly Configurable And Mutable Plugin

Like Alex Sexton’s pattern, the following logic for our plugin isn’t nested in a
jQuery plugin itself. We instead define our plugin’s logic using a constructor
and an object literal deﬁned on its prototype, using jQuery for the actual
instantiation of the plugin object.

Customization is taken to the next level by employing two little tricks, one of
which you’ve seen in previous patterns:

Options can be overridden both globally and per collection of elements;
Options can be customized on a per-element level through HTML5 data
attributes (as shown below). This facilitates plugin behavior that can be applied
to a collection of elements but then customized inline without the need to
instantiate each element with a different default value.
You don’t see the latter option in the wild too often, but it can be a significantly
cleaner solution (as long as you don’t mind the inline approach). If you’re
wondering where this could be useful, imagine writing a draggable plugin for a
large set of elements. You could go about customizing their options like this:

1 javascript
2 $('.item-a').draggable({'defaultPosition':'top-left'});
3 $('.item-b').draggable({'defaultPosition':'bottom-right'});
4 $('.item-c').draggable({'defaultPosition':'bottom-left'});
5 //etc

But using our patterns inline approach, the following would be possible:

1 javascript
2 $('.items').draggable();

1 html
2 <li class="item" data-plugin-options='{"defaultPosition":"top-left"}'>
</div>
3 <li class="item" data-plugin-options='{"defaultPosition":"bottom-
left"}'></div>

And so on. You may well have a preference for one of these approaches, but it
is another potentially useful pattern to be aware of.

01 /*
02 * 'Highly configurable' mutable plugin boilerplate
03 * Author: @markdalgleish
04 * Further changes, comments: @addyosmani
06 */
07
08
09 // Note that with this pattern, as per Alex Sexton's, the plugin logic

174 de 184 22/03/12 11:43


10 // hasn't been nested in a jQuery plugin. Instead, we just use
11 // jQuery for its instantiation.
12
13 ;(function( $, window, document, undefined ){
14
15 // our plugin constructor
16 var Plugin = function( elem, options ){
17 this.elem = elem;
18 this.$elem = $(elem);
19 this.options = options;
20
21 // This next line takes advantage of HTML5 data attributes
22 // to support customization of the plugin on a per-element
23 // basis. For example,
24 // <div class=item' data-plugin-options='{"message":"Goodbye
World!"}'></div>
25 this.metadata = this.$elem.data( 'plugin-options' );
26 };
27
28 // the plugin prototype
29 Plugin.prototype = {
30 defaults: {
31 message: 'Hello world!'
32 },
33
35 // Introduce defaults that can be extended either
36 // globally or using an object literal.
37 this.config = $.extend({}, this.defaults, this.options,
38 this.metadata);
39
40 // Sample usage:
41 // Set the message per instance:
42 // $('#elem').plugin({ message: 'Goodbye World!'});
43 // or
44 // var p = new Plugin(document.getElementById('elem'),
45 // { message: 'Goodbye World!'}).init()
46 // or, set the global default message:
47 // Plugin.defaults.message = 'Goodbye World!'
48
49 this.sampleMethod();
50 return this;
51 },
52
53 sampleMethod: function() {
54 // eg. show the currently configured message
55 // console.log(this.config.message);
56 }
57 }
58
59 Plugin.defaults = Plugin.prototype.defaults;
60
61 $.fn.plugin = function(options) {
62 return this.each(function() {
63 new Plugin(this, options).init();
64 });
65 };
66
67 //optional: window.Plugin = Plugin;

175 de 184 22/03/12 11:43


68
69 })( jQuery, window , document );

Usage:

1 $('#elem').plugin({
2 message: "foobar"
3 });

Further Reading

“Creating Highly Conﬁgurable jQuery Plugins,” Mark Dalgleish
“Writing Highly Conﬁgurable jQuery Plugins, Part 2,” Mark Dalgleish

UMD: AMD And CommonJS-Compatible Modules For Plugins

Whilst many of the plugin and widget patterns presented above are acceptable
for general use, they aren’t without their caveats. Some require jQuery or the
jQuery UI Widget Factory to be present in order to function, while only a few
could be easily adapted to work well as globally compatible modules in both the
browser and other environments.

We've alredy explored both AMD and CommonJS in the last chapter, but
imagine how useful it would be if we could define and load plugin modules
compatible with AMD, CommonJS and other standards that are also compatible
with different environments (client-side, server-side and beyond).

To provide a solution for this problem, a number of developers including James
Burke, myself, Thomas Davis and Ryan Florence have been working on an
effort known as UMD (or Universal Module Definition). The goal of our efforts
has been to provide a set of agreed upon patterns for plugins that can work in
all environments. At present, a number of such boilerplates have been
completed and are available on the UMD group repo https://github.com
/umdjs/umd.

One such pattern we’ve worked on for jQuery plugins appears below and has
the following features:

A core/base plugin is loaded into a $.core namespace, which can then be easily
extended using plugin extensions via the namespacing pattern. Plugins loaded
via script tags automatically populate a plugin namespace under core (i.e.

176 de 184 22/03/12 11:43


$.core.plugin.methodName()).
The pattern can be quite nice to work with because plugin extensions can
access properties and methods defined in the base or, with a little tweaking,
override default behavior so that it can be extended to do more.
A loader isn’t required at all to make this pattern fully function.
usage.html

01 <script type="text/javascript" src="http://code.jquery.com/jquery-
1.7.1.min.js"></script>
02 <script type="text/javascript" src="pluginCore.js"></script>
03 <script type="text/javascript" src="pluginExtension.js"></script>
04
05 <script type="text/javascript">
06
07 $(function(){
08
09 // Our plugin 'core' is exposed under a core namespace in
10 // this example, which we first cache
11 var core = $.core;
12
13 // Then use use some of the built-in core functionality to
14 // highlight all divs in the page yellow
15 core.highlightAll();
16
17 // Access the plugins (extensions) loaded into the 'plugin'
18 // namespace of our core module:
19
20 // Set the first div in the page to have a green background.
21 core.plugin.setGreen("div:first");
22 // Here we're making use of the core's 'highlight' method
23 // under the hood from a plugin loaded in after it
24
25 // Set the last div to the 'errorColor' property defined in
26 // our core module/plugin. If you review the code further down,
27 // you'll see how easy it is to consume properties and methods
28 // between the core and other plugins
29 core.plugin.setRed('div:last');
30 });
31
32 </script>

pluginCore.js

01 // Module/Plugin core
02 // Note: the wrapper code you see around the module is what enables
03 // us to support multiple module formats and specifications by
04 // mapping the arguments defined to what a specific format expects
05 // to be present. Our actual module functionality is defined lower
06 // down, where a named module and exports are demonstrated.
07 //
08 // Note that dependencies can just as easily be declared if required
09 // and should work as demonstrated earlier with the AMD module examples.
10
11 (function ( name, definition ){

177 de 184 22/03/12 11:43


13 // this is considered "safe":
14 hasDefine = typeof define === 'function' && define.amd,
15 // hasDefine = typeof define === 'function',
17
18 if ( hasDefine ){ // AMD Module
(window)
23 (this.jQuery || this.ender || this.$ || this)[name] = theModule;
24 }
25 })( 'core', function () {
26 var module = this;
27 module.plugins = [];
28 module.highlightColor = "yellow";
29 module.errorColor = "red";
30
31 // define the core module here and return the public API
32
33 // This is the highlight method used by the core highlightAll()
34 // method and all of the plugins highlighting elements different
35 // colors
36 module.highlight = function(el,strColor){
37 if(this.jQuery){
38 jQuery(el).css('background', strColor);
39 }
40 }
41 return {
42 highlightAll:function(){
43 module.highlight('div', module.highlightColor);
44 }
45 };
46
47 });

pluginExtension.js

01 // Extension to module core
02
03 (function ( name, definition ) {
05 hasDefine = typeof define === 'function',
07
08 if ( hasDefine ) { // AMD Module
(window)
13
14
15 // account for for flat-file/global module extensions
16 var obj = null;
17 var namespaces = name.split(".");
18 var scope = (this.jQuery || this.ender || this.$ || this);

178 de 184 22/03/12 11:43


19 for (var i = 0; i < namespaces.length; i++) {
20 var packageName = namespaces[i];
21 if (obj && i == namespaces.length - 1) {
22 obj[packageName] = theModule;
23 } else if (typeof scope[packageName] === "undefined") {
24 scope[packageName] = {};
25 }
26 obj = scope[packageName];
27 }
28
29 }
30 })('core.plugin', function () {
31
32 // Define your module here and return the public API.
33 // This code could be easily adapted with the core to
34 // allow for methods that overwrite and extend core functionality
35 // in order to expand the highlight method to do more if you wish.
36 return {
37 setGreen: function ( el ) {
38 highlight(el, 'green');
39 },
40 setRed: function ( el ) {
41 highlight(el, errorColor);
42 }
43 };
44
45 });

Whilst work on improving these patterns is ongoing, please do feel free to
check out the patterns suggested to date as you may find them helpful.

Further Reading

“Using AMD Loaders to Write and Manage Modular JavaScript,” John Hann
“Demystifying CommonJS Modules,” Alex Young
“AMD Module Patterns: Singleton,” John Hann
“Run-Anywhere JavaScript Modules Boilerplate Code,” Kris Zyp
“Standards And Proposals for JavaScript Modules And jQuery,” James Burke

What Makes A Good Plugin Beyond Patterns?

At the end of the day, patterns are just one aspect of plugin development. And
before we wrap up, here are my criteria for selecting third-party plugins, which
will hopefully help developers write them.

Quality
Do your best to adhere to best practices with both the JavaScript and jQuery

179 de 184 22/03/12 11:43


that you write. Are your solutions optimal? Do they follow the jQuery Core
Style Guidelines? If not, is your code at least relatively clean and readable?

Compatibility
Which versions of jQuery is your plugin compatible with? Have you tested it
with the latest builds? If the plugin was written before jQuery 1.6, then it might
have issues with attributes, because the way we approach them changed with
that release. New versions of jQuery offer improvements and opportunities for
the jQuery project to improve on what the core library offers. With this comes
occasional breakages (mainly in major releases) as we move towards a better
way of doing things. I’d like to see plugin authors update their code when
necessary or, at a minimum, test their plugins with new versions to make sure
everything works as expected.

Reliability
Your plugin should come with its own set of unit tests. Not only do these prove
your plugin actually works, but they can also improve the design without
breaking it for end users. I consider unit tests essential for any serious jQuery
plugin that is meant for a production environment, and they’re not that hard to
write. For an excellent guide to automated JavaScript testing with QUnit, you
may be interested in “Automating JavaScript Testing With QUnit,” by Jorn
Zaefferer.

Performance
If the plugin needs to perform tasks that require a lot of computing power or
that heavily manipulates the DOM, then you should follow best practices that
minimize this. Use jsPerf.com to test segments of your code so that you’re
aware of how well it performs in different browsers before releasing the plugin.

Documentation
If you intend for other developers to use your plugin, ensure that it’s well
documented. Document your API. What methods and options does the plugin
support? Does it have any gotchas that users need to be aware of? If users
cannot figure out how to use your plugin, they’ll likely look for an alternative.
Also, do your best to comment the code. This is by far the best gift you could
give to other developers. If someone feels they can navigate your code base
well enough to fork it or improve it, then you’ve done a good job.

Likelihood of maintenance
When releasing a plugin, estimate how much time you’ll have to devote to
maintenance and support. We all love to share our plugins with the community,

180 de 184 22/03/12 11:43


but you need to set expectations for your ability to answer questions, address
issues and make improvements. This can be done simply by stating your
intentions for maintenance in the README file, and let users decide whether
to make fixes themselves.

In this section, we’ve explored several time-saving design patterns and best
practices that can be employed to improve your plugin development process.
Some are better suited to certain use cases than others, but I hope that the
code comments that discuss the ins and outs of these variations on popular
plugins and widgets were useful.

Remember, when selecting a pattern, be practical. Don’t use a plugin pattern
just for the sake of it; rather, spend some time understanding the underlying
structure, and establish how well it solves your problem or fits the component
you’re trying to build. Choose the pattern that best suits your needs.

Conclusions

That’s it for this introduction to the world of design patterns in JavaScript - I
hope you’ve found it useful. The contents of this book should hopefully have
given you sufficient information to get started using the patterns covered in
your day-to-day projects.

Design patterns make it easier to reuse successful designs and architectures.
It’s important for every developer to be aware of design patterns but it’s also
essential to know how and when to use them. Implementing the right patterns
intelligently can be worth the effort but the opposite is also true. A badly
implemented pattern can yield little benefit to a project.

Also keep in mind that it is not the number of patterns you implement that's
important but how you choose to implement them. For example, don’t choose a
pattern just for the sake of using ‘one’ but rather try understanding the pros
and cons of what particular patterns have to offer and make a judgement
based on it’s fitness for your application.

If I’ve encouraged your interest in this area further and you would like to learn

181 de 184 22/03/12 11:43


more about design patterns, there are a number of excellent titles on this area
available for generic software development but also those that cover speciﬁc
languages.

I'm happy to recommend:

1. 'Patterns Of Enterprise Application Architecture' by Martin Fowler
2. 'JavaScript Patterns' by Stoyan Stefanov
3. ‘Pro JavaScript Design Patterns’ by Ross Harmes and Dustin Diaz.

If you’ve managed to absorb most of the information in my book, I think you’ll
ﬁnd reading these the next logical step in your learning process (beyond trying
out some pattern examples for yourself of course).

Thanks for reading Essential JavaScript Design Patterns. For more educational
material on learning JavaScript, please feel free to read more from me on my
blog http://addyosmani.com or on Twitter @addyosmani.

References

1. Design Principles and Design Patterns - Robert C
Martinhttp://www.objectmentor.com/resources/articles
/Principles_and_Patterns.pdf
2. Ralph Johnson - Special Issue of ACM On Patterns and Pattern Languages -
http://www.cs.wustl.edu/~schmidt/CACM-editorial.html
3. Hillside Engineering Design Patterns Library - http://hillside.net/patterns/
4. Pro JavaScript Design Patterns - Ross Harmes and Dustin Diaz
http://jsdesignpatterns.com/
5. Design Pattern Definitions - http://en.wikipedia.org/wiki/Design_Patterns
6. Patterns and Software Terminology http://www.cmcrossroads.com/bradapp
/docs/patterns-intro.html
7. Reap the benefits of Design Patterns - Jeff Juday
http://articles.techrepublic.com.com/5100-10878_11-5173591.html
8. JavaScript Design Patterns - Subramanyan Guhan http://www.slideshare.net
/rmsguhan/javascript-design-patterns

182 de 184 22/03/12 11:43


9. What Are Design Patterns and Do I Need Them? - James Moaoriello
http://www.developer.com/design/article.php/1474561
10. Software Design Patterns - Alex Barnett http://alexbarnett.net/blog/archive
/2007/07/20/software-design-patterns.aspx
11. Evaluating Software Design Patterns - Gunni Rode http://www.rode.dk/thesis/
12. SourceMaking Design Patterns http://sourcemaking.com/design_patterns
13. The Singleton - Prototyp.ical http://prototyp.ical.ly/index.php/2007/03
/01/javascript-design-patterns-1-the-singleton/
14. JavaScript Patterns - Stoyan Stevanov - http://www.slideshare.net/stoyan
/javascript-patterns
15. Stack Overflow - Design Pattern Implementations in JavaScript (discussion)
http://stackoverflow.com/questions/24642/what-are-some-examples-of-design-
pattern-implementations-using-javascript
16. The Elements of a Design Pattern - Jared Spool http://www.uie.com/articles
/elements_of_a_design_pattern/
17. Stack Overflow - Examples of Practical JS Design Patterns (discussion)
http://stackoverflow.com/questions/3722820/examples-of-practical-javascript-
object-oriented-design-patterns
18. Design Patterns in JavaScript Part 1 - Nicholas Zakkas
http://www.webreference.com/programming/javascript/ncz/column5/
19. Stack Overflow - Design Patterns in jQuery http://stackoverflow.com/questions
/3631039/design-patterns-used-in-the-jquery-library
20. Classifying Design Patterns By AntiClue - Elyse Neilson
http://www.anticlue.net/archives/000198.htm
21. Design Patterns, Pattern Languages and Frameworks - Douglas Schmidt
http://www.cs.wustl.edu/~schmidt/patterns.html
22. Show Love To The Module Pattern - Christian Heilmann http://www.wait-
till-i.com/2007/07/24/show-love-to-the-module-pattern/
23. JavaScript Design Patterns - Mike G. http://www.lovemikeg.com/2010/09
/29/javascript-design-patterns/
24. Software Designs Made Simple - Anoop Mashudanan http://www.scribd.com
/doc/16352479/Software-Design-Patterns-Made-Simple
25. JavaScript Design Patterns - Klaus Komenda http://www.klauskomenda.com
/code/javascript-programming-patterns/
26. Introduction to the JavaScript Module Pattern https://www.unleashed-
technologies.com/blog/2010/12/09/introduction-javascript-module-design-
pattern
27. Design Patterns Explained - http://c2.com/cgi/wiki?DesignPatterns
28. Mixins explained http://en.wikipedia.org/wiki/Mixin

183 de 184 22/03/12 11:43


29. Working with GoF's Design Patterns In JavaScript http://aspalliance.com
/1782_Working_with_GoFs_Design_Patterns_in_JavaScript_Programming.all
30. Using Object.createhttp://stackoverflow.com/questions/2709612/using-object-
create-instead-of-new
31. t3knomanster's JavaScript Design Patterns -
http://t3knomanser.livejournal.com/922171.html
32. Working with GoF Design Patterns In JavaScript Programming -
http://aspalliance.com
/1782_Working_with_GoFs_Design_Patterns_in_JavaScript_Programming.7
33. JavaScript Advantages - Object Literals http://stackoverflow.com/questions
/1600130/javascript-advantages-of-object-literal
34. JavaScript Class Patterns - Liam McLennan http://geekswithblogs.net
/liammclennan/archive/2011/02/06/143842.aspx
35. Understanding proxies in jQuery - http://stackoverflow.com/questions/4986329
/understanding-proxy-in-jquery
36. Speaking on the Observer pattern - http://www.javaworld.com/javaworld/javaqa
/2001-05/04-qa-0525-observer.html
37. Singleton examples in JavaScript - Hardcode.nl - http://www.hardcode.nl
/subcategory_1/article_526-singleton-examples-in-javascript.htm
38. Design Patterns by Gamma, Helm supplement - http://exciton.cs.rice.edu
/javaresources/DesignPatterns/

Essential JavaScript Design Patterns. © Addy Osmani 2012.

184 de 184 22/03/12 11:43

Essential java script design patterns

Recommended

More Related Content

Similar to Essential java script design patterns (20)

Recently uploaded (20)

Essential java script design patterns