Modern JavaScript Applications: Design Patterns

  • Published on

  • View

  • Download

Embed Size (px)


It's presented how classical OOP approaches and design patterns can be used for modern JavaScript applications.


<ul><li> MODERN JAVASCRIPT APPLICATIONS Volodymyr VoityshynRivne 2013 </li> <li> How to get well structured JavaScript code? How to get well structured JavaScript code? </li> <li> Client JavaScript Evolution 1. Client JavaScript resolved auxiliary tasks 2. Single Page Web Applications 3. Real time applications 4 </li> <li> Contents I. Some Useful Constructions II. What is wrong? III. JavaScript &amp; OOP IV. Module Pattern V. Object Oriented Design Patterns VI. MV* Patterns via BackboneJS VII. Dependencies Management 5 </li> <li> I. Some Useful Constructions </li> <li> Closures 7 </li> <li> IIFE 8 </li> <li> Named Parameters Must be documented 9 Its useful for 4 and more parameters </li> <li> II. What is wrong? </li> <li> Global Functions Avoid global functions Use instead: Classes Modules 11 </li> <li> Mixing JavaScript with HTML Place HTML and JavaScript in separated files Assign event handlers with JavaScript 12 </li> <li> Mixing JS &amp; Server Code is Bad ASP.NET MVC Razor 13 </li> <li> Mixing JS &amp; Server Code is Acceptable ASP.NET MVC Razor 14 </li> <li> III. JavaScript &amp; OOP </li> <li> Fact #1 Everything is an object 16 </li> <li> even primitives and functions 17 </li> <li> Creating an Object 18 </li> <li> Fact # 2 Object members can be added/deleted dynamically 19 </li> <li> Defining Members 20 </li> <li> Creating an Object with JSON Notation 21 </li> <li> Deleting Members 22 </li> <li> Fact #3 All object members are public 23 </li> <li> Fact #4 Objects are hash tables 24 </li> <li> Access to a Property with [] 25 </li> <li> Fact #5 Inheritance is based on prototypes 26 </li> <li> Inheritance Object vehicle + name + run() bicycle + wheels Sample_2_01 27 </li> <li> Fact #6 Functions can be considered as classes 28 </li> <li> Pseudo Class Object Vehicle + name + run() 29 </li> <li> The prototype Property Object Vehicle + name + run() 30 </li> <li> Pseudo Class Inheritance Object Vehicle + name + run() Bicycle + wheels Sample_2_02 31 </li> <li> Inheritance: Practice Hints Avoid a too long prototype chain Avoid extending prototypes of built-in objects Use framework functions for extending objects: $.extend() _.extend() _.mixin() 32 </li> <li> Virtual Functions 33 </li> <li> Static Members 34 </li> <li> IV. Module Pattern </li> <li> Module Pattern Intent Provides both private and public encapsulation for classes </li> <li> Module Example Closure is used for private state Public object is returned Created by IIFE Sample_3_01_Module_Counter 37 </li> <li> Import Dependencies 38 </li> <li> Extending Sample_3_02_Module_Strings 39 </li> <li> Extending jQuery Module 40 </li> <li> Extending Underscore Module 41 </li> <li> Page Code Behind as Module Page (HTML + CSS) Code Behind (JavaScript Module) Handle Events Read Data Put Data 42 Sample_3_04_PageCodeBehind_Module </li> <li> Advantages vs. Disadvantages Advantages Simple in development Possibility of using a page base class Disadvantages Becomes too large in case of a complex page Hard in automated testing Cant be used with SPA 43 </li> <li> Class as Module 44 </li> <li> V. Object Oriented Design Patterns </li> <li> V.1. Creational Patterns help make a system independent of how its objects are created, composed, and represented (GoF) </li> <li> Factory Pattern Intent Provides an interface for creating families of related or dependent objects without specifying their concrete classes. (GoF) </li> <li> Classical Abstract Factory AbstractComponentFactory - components + create(string) ChComponentFactory IEComponentFactory Calendar + render() IECalendar + render() ChCalendar + render() Grid + render() IEGrid + render() ChGrid + render() Sample_4_01_AbstractFactory_CrossBrowser_Component </li> <li> Service Locator &amp; IoC Provides abstract interface for instantiating objects Resolves dependencies among objects Manages objects life cycle </li> <li> Prototype Pattern Intent Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. (GoF) Prototype New Object clone() </li> <li> Prototype by Native JavaScript Object p id, name p1 p2 </li> <li> Prototype as a Shallow Copy Object p3 id, name p4 id, name p5 id, name </li> <li> Prototype as a Deep Copy Object p6 id, name p7 id, name </li> <li> Classical Prototype </li> <li> Cloning DOM Elements </li> <li> V.2. Structural Patterns are concerned with how classes and objects are composed to form larger structures (GoF) </li> <li> Adapter Pattern Intent Convert the interface of a class into another interface clients expect (GoF) Client Expected Interface Old Interface </li> <li> Adapting to Underscore Interface </li> <li> Decorator Pattern Intent Attach additional responsibilities to an object dynamically (GoF) Decorator 2 Decorator 1 an ObjectClient </li> <li> Classical Decorator </li> <li> Decorator and IIFE </li> <li> Decorator with Closure </li> <li> Faade Pattern Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. (GoF) A Complex System Faade Client </li> <li> Faade in jQuery XMLHttpRequest $.ajax() Client document.createElement() $() Client </li> <li> Faade: Important Consideration Performance Comfortable Interface </li> <li> V.3. Behavioral Patterns are concerned with algorithms and the assignment of responsibilities among objects (GoF) </li> <li> Observer Pattern Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. (GoF) Subject Observer 1 Observer 2 Observer 3 Notify about changes Notify about changes </li> <li> Publish/Subscribe </li> <li> Publish/Subscribe &amp; Backbone Event </li> <li> Mediator Pattern Intent Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. (GoF) </li> <li> Mediator as Event Buss Event Buss Module 1 Module 2 Publishes an event Listens an event Transfers an event from the publisher to the listeners </li> <li> Mediator as Web Modules Manager Web Module 1 Web Module 2 Web Modules Manager Nicholas Zakas: Scalable JavaScript Application Architecture Manages a web module life cycle Manages collaboration among modules Web Module Context Everything a web module knows about the application Manage users interaction Dont know about each other Web Module an independent part of GUI </li> <li> Strategy Pattern Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. (GoF) </li> <li> Sorting Algorithms as Strategy </li> <li> VI. MV* Patterns via BackboneJS </li> <li> Model View Controller View Model Controller Main goal - separate view and data </li> <li> Top JavaScript MVC Frameworks Knockout.js Ember.js Angular.js Backbone.js </li> <li> Backbone Object Types 78 Events Model Collection View Router </li> <li> Backbone.js Typical Stack Backbone.js Underscore.js jQuery Require.js </li> <li> Backbone Advantages 80 Simple in usage Defines major types of an application objects Gets much freedom for application structure Easily extensible Gets on well with other frameworks </li> <li> VII. Dependencies Management </li> <li> What is a bad design? Inflexibility Fragility Solidity </li> <li> Coupling A measure of how much a module relies on other modules </li> <li> Cohesion A measure of how closely related the members of a module are to the other members of the same module HighLow </li> <li> What is a good design? Flexible Robust Reusable </li> <li> Whats a main problem? </li> <li> What is a key to success? Manage dependencies! </li> <li> Dependency Inversion Principle A. High level modules should not depend upon low level modules. Both should depend upon abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions. (Robert C. Martin) The Dependency Inversion Principle (by Robert C. Martin) </li> <li> Dependency Inversion Formula X Y X Y IY </li> <li> Design Quality Criteria How easily could your code be covered by unit tests? Could web modules be used independently? </li> <li> Class Dependencies Passive Injection Constructor Method Field Active Injection Service Locator </li> <li> Module Dependencies Asynchronous Module Definition (AMD) define(id?, dependencies?, factory) </li> <li> RequireJS Module Sample 93 </li> <li> Web Modules Dependencies (1) </li> <li> Web Modules Dependencies (2) 95 Models &amp; Collections Root View View 1 View 2 View 1 View 1 View 1 View 1 </li> <li> For further reading 1. JavaScript Good Parts 2. JavaScript Garden 3. Leaning JavaScript Design Patterns (by Addy Osmani) 4. JavaScript Module Pattern: In-Depth (by Ben Cherry) 5. Scalable JavaScript Application Architecture (by Nicholas Zakas) 6. Journey Through The JavaScript MVC Jungle (by Addy Osmani) 7. Developing Backbone.js Applications (by Addy Osmani) 8. superhero.js </li> </ul>