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 ?