JavaScript Design Patterns

Agenda

● What ?

● Types of Design Patterns

● Some comman Anti-Patterns

● Benefits and Disadvantages

● Various Design Patterns

● Design pattern are recurring solutions to software design problems you find again and again in real-world application development

● Standardized solutions to common problems in software design

What ?

Describes a bad solution to a particular problem which resulted in a bad situation occurring

Examples of anti-patterns in JavaScript are the following:

Polluting the global 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.

Modifying the Object class prototype (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.

Anti-Patterns

Benefits & Drawbacks

Benefits:

Design patterns enable large-scale reuse of software architectures

Patterns explicitly capture expert knowledge and design tradeoffs, and make this expertise more widely available

Patterns help improve developer communication

Drawbacks:

Patterns do not lead to direct code reuse

Patterns are deceptively simple

Teams may suffer from pattern overload

Patterns are validated by experience and discussion rather than by automated testing

Types of Pattern

Creational Patterns

concern the process of object creation.

Structural Patterns

concern with integration and composition of classes and objects.

Behavioral Patterns

concern with class or object communication.

CREATIONAL PATTERNS

Factory Method

Abstract Factory

Builder

Prototype

Singleton

STRUCTURAL PATTERNS

Adapter

Bridge

Composite

Decorator

Façade

Flyweight

Proxy

BEHAVIORAL PATTERNS

Chain of Responsibility

Command

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template Method

Visitor

Modern Day Patterns

The Module Pattern

The Revealing Module Pattern

The Singleton Pattern

The Observer Pattern

The Mediator Pattern

The Prototype Pattern

The Facade Pattern

The Factory Pattern

Module Design Pattern

Focuses on public and private access to methods & variables.

Demo

Advantages

Cleaner approach for developers

Supports private data

Less clutter in the global namespace

Localization of functions and variables through closures

Disadvantages

Private methods are unaccessible, some people say that this leads to the inability of unit testing

Private methods and functions lose extendability since they are unaccessible (see my comment in the previous bullet point).

Revealing Module Design Pattern

Same as Module Pattern, the only difference is that it was engineered as a way to ensure that all methods and variables are kept private until they are explicitly exposed; usually through an object literal returned by the closure from which it’s defined.

Demo

Advantages

Cleaner approach for developers

Supports private data

Less clutter in the global namespace

Localization of functions and variables through closures

The syntax of our scripts are even more consistent

Explicitly defined public methods and variables which lead to increased readability

Disadvantages

Same as Module Pattern

Singleton Design Pattern

Restricts instantiation of an object to a single reference

Demo

Advantages

Reduced memory footprint

Single point of access

Delayed initialization that prevents instantiation until required

Disadvantages

Once instantiated, they’re hardly ever “reset”.

Harder to unit test and sometimes introduces hidden dependencies.

Prototype Design Pattern

Prototype Design Pattern

The prototype pattern focuses on creating an object that can be used as a blueprint for other objects through prototypal inheritance.

Demo

Advantages

New objects created from the “skeleton” of an existing object inherit references to existing functions on the prototype chain, thus boosting performance and keeping memory footprints to a minimum.

Great for an application where the focus is on object creation

Disadvantages

Overkill for a project that uses very few objects and/or does not have an underlying emphasis on the extension of prototype chains

Factory Design Pattern

Provides an interface for developers to create new objects through the use of the factory rather than invoking the new operator on an object.

Demo

Advantages 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 or need to create components that require similar instantiation or methods

Great for decoupling components.

Disadvantages

Add an unnecessarily additional aspect of complexity to code.

Unit testing can be difficult as a direct result of the object creation process being hidden by the factory methods.

Facade Design Pattern

Conceal the underlying complexity of the code by using an anonymous function as an extra layer.

Extremely interesting and very useful for adding an extra layer of security to your already minified code.

Extremely useful when coupled with the revealing module pattern.

Demo

Advantages

Enhances security for your web application

Works well in combination with other patterns

Easy to implement

Makes it easy to patch internals

Provides a simpler public interface

Proven useful for other major libraries such as jQuery

Disadvantages

One possible note worth mentioning is that a developer must decide whether the implicit cost of implementation is really worth the abstraction (though this is generally a small footprint).

Observer Design Pattern

This pattern implements a single object (the subject) that maintains a reference to a collection of objects (known as “observers”) and broadcasts notifications when a change to state occurs.

Demo

Advantages Requires deeper-level thinking of the relationship between the various

components of an application

Helps us pinpoint dependencies

Excellent at decoupling objects which often promotes smaller, reusable components

Dynamic relationships may exist between publishers and subscribers when using this pattern. This provides a great deal of flexibility which may not be as easy to implement when disparate parts of your application are tightly coupled.

Disadvantages Checking the integrity of your application can become difficult.

Switching a subscriber from one publisher to another can be costly.

For reference

http://carldanley.com/javascript-design-patterns/

http://addyosmani.com/resources/essentialjsdesignpatterns/book

Questions ?